- Расширяемость
- Производительность
- Распараллеливание алгоритмов
- Многопроцессорная обработка с помощью нитей
- Оптимизация
- Управление ресурсами
- Параллельная обработка запросов
- Сопровождение в оперативном режиме
Современные тенденции развития средств обработки коммерческих данных и технологии предъявляют к индустрии баз данных определенные требования в области архитектуры. Вычислительные технологии, а вместе с ними коммерческие применения традиционно искусственно разделяли оперативную обработку транзакций (OLTP), пакетную обработку и интерактивные системы поддержки принятия решений. Отделы информационных систем, занимающиеся обслуживанием клиентов и отвечающие потребностям управления бизнесом, занимались разбиванием поступающих к ним коммерческих запросов до такого уровня, когда те могут быть обработаны в одной из этих сред. Современная коммерческая деятельность все в большей степени ориентируется на информационный поток и требует поэтому соответствующего сервиса. Возникает необходимость объединения указанных классов обработки данных. Ставший популярным интегрированный класс обработки данных называется комплексной обработкой в оперативном режиме (OLCP - On-Line Complex Processing). Платформы, основанные на OLCP, предоставляют возможности отвечать на запросы клиентов и управлять коммерческой деятельностью как в однозадачном, так и в многозадачном режимах.
Одновременно с признанием важности OLCP технология быстро продвигалась вперед. С одной стороны, новые аппаратные технологии позволили снизить цены на компьютеры, а также повысили их мощность. Возросла скорость передачи данных по сети, продолжает снижаться стоимость памяти. При увеличении объемов дисков их скорости тоже не отстали. Одним из самых важных изменений стало движение в сторону использования нескольких процессоров для увеличения вычислительной мощности.
Несмотря на то что платформы сейчас являются в основном однопроцессорными, возрастающее значение приобретают следующие три архитектуры:
- Симметричная многопроцессорная (SMP) - наиболее общая форма сильносвязанных многопроцессорных систем; это означает, что системы имеют совместно используемую оперативную память и дисковое пространство.
- Слабосвязанные многопроцессорные системы - системы, которые могут совместно использовать дисковую память, но имеют различную организацию оперативной памяти, например, в виде кластеров - системы с сотнями и даже тысячами процессорных элементов.
Хотя все перечисленные системы получили некоторое распространение и можно ожидать, что их значение возрастет, однако системы SMP в ближайшем будущем станут основными. Главным доводом, говорящим в пользу этого, является низкая стоимость аппаратного расширения.
Потенциальные возможности SMP начинают находить применение. Во-первых, общим местом стало уменьшение габаритов платформы. Во-вторых, коммуникационные стандарты сделали доступными распределенные вычисления. Вычисления в архитектуре клиент-сервер непосредственно используют возможности связанных систем и разделяют рабочую нагрузку. В-третьих, независимое масштабирование аппаратуры (т.е. без увеличения накладных расходов или необходимости переписывания приложений) является ключевым элементом поддержки как процесса-клиента, так и процесса-сервера. Все эти элементы хорошо поддерживаются системами SMP.
Чтобы полностью использовать преимущества этих изменений в архитектуре, должно разрабатываться специальное программное обеспечение (особенно это относится к СУБД и ОС), которое позволит ощутить выигрыш от реальной мощности SMP. Они не должны ограничиваться однопроцессорной моделью, используемой сегодня, или слабосвязанными, несвязанными или системами с массовым параллелизмом завтра. При эффективном использовании системы SMP способны обеспечить расширяемую, основанную на OLCP, платформу за относительно низкую цену. Основным критически важным фактором в платформе OLCP является архитектура сервера баз данных. В данной статье описываются архитектурные характеристики, которым должен удовлетворять сервер баз данных с точки зрения современных течений и возможностей.
Основные требования
К архитектурам современных серверов баз данных выдвигаются четыре основных требования: расширяемость, производительность, OLCP, доступность.
Расширяемость
Расширяемость - это свойство системы, которое допускает предсказуемую поддержку дополнительных пользователей, более высокую производительность, пропускную способность и т. д. путем добавления вычислительных ресурсов и без изменения приложений и административного сопровождения. Существует два способа расширения сервера баз данных: горизонтальный и вертикальный. Горизонтальное может быть получено, когда несколько серверов действуют независимо и делят рабочее пространство. Этот метод более применим для слабосвязанных систем и распределенных баз данных, однако он требует дополнительной административной поддержки. Вертикальное расширение, затрагивающее отдельный сервер, может быть достигнуто путем добавления к платформе дополнительных ресурсов, как, например, более быстрых процессорных элементов или дополнительных процессоров, с целью уменьшения времени отклика или увеличения пропускной способности. Поддержка сервера баз данных для вертикального расширения не должен требовать включения дополнительных программных модулей, поскольку это увеличивает административные издержки и понижает предсказуемость. Независимо от того, какое расшинение используется, вертикальное или горизонтальное, его эффективность зависит от того, как хорошо использует программное обеспечение сервера доступные ресурсы. В данной статье мы сосредоточимся на вертикальном расширении, поскольку данный метод сейчас развивается наиболее быстро.
Важность расширяемости объясняется двумя основными причинами. Во-первых, поскольку требования бизнеса меняются очень быстро, далее невозможно использовать негибкое времяемкое долгосрочное планирование, как это раньше делалось администраторами MIS. Вместо этого используется пошаговый подход. Во-вторых, быстро меняется технология, что приводит к появлению новых возможностей и более низкой стоимости аппаратуры. Без пошагового подхода трудно получить выигрыш от новых технологий без ущемления старой. В терминах современного бизнеса это означает, что более старый бизнес не может конкурировать с более молодым из-за устаревших инвестиций. Эти факты требуют, чтобы и аппаратура, и программное обеспечение, особенно реляционные СУБД, были расширяемы.
Многопроцессорность
Системы SMP часто используются для получения вертикального расширения, поскольку они допускают добавление процессорных элементов без изменения всей платформы. Системы MPP также могут быть использованы для вертикального расширения, но сегодня их применение ограничивается только специализированными приложениями. Две основных проблемы для SMP-архитектуры сервера баз данных - масштабируемость и прозрачность.
Масштабируемость означает, что архитектура сервера баз данных не специализирована некоторым заданным числом процессоров; с одинаковым успехом она должна позволять поддерживать один процессор или полдесятка процессоров, не требуя при этом повторной установки, выключения при изменении конфигурационных параметров или дополнительных программных опций. Такая архитектура будет одинаково полезна и эффективна для случая одного процессора, нескольких процессоров (SMP) или даже многих процессоров (MPP). Пользователю нет необходимости специально заботиться о программном обеспечении, ориентированном на конкретную платформу.
Прозрачность требует, чтобы архитектура баз данных позволяла скрывать изменения в платформе архитектуры от приложений. В частности, однопроцессорная или SMP-системы для взаимодействия могут использовать общую память, тогда как слабосвязанные системы - пересылку сообщений. Приложения не должны меняться с изменением платформы или механизма взаимодействия; преобразования данных и пользовательский интерфейс баз данных должны оставаться без изменений.
Эффективная поддержка многопроцессорности требует, чтобы сервер был способен распределять задания по доступным ресурсам. Это может быть достигнуто путем последовательного распределения запросов или делением запросов на подзадачи, которые могут быть выполнены параллельно. При правильной реализации второй подход наиболее эффективен, и выигрыш не зависит от типа приложения. Степень детализации, с которой осуществляется балансировка обменов и распределение заданий, оказывает большое влияние на эффективность. Если степень детализации слишком высока (например, SQL-утверждение), ресурсы процессора и памяти не будут эффективно использованы (например, ресурсы процессора не будут использоваться во время ожидания выполнения обмена с диском). При меньшей детализации использование общих ресурсов происходит даже внутри одного запроса и, что более эффективно, для нескольких одновременных запросов.
Расширяемость архитектуры
Независимо от степени переносимости и поддержки стандартов и параллелизма, архитектура сервера баз данных, которая имеет встроенные ограничения, будет нерасширяема. Ограничения на размеры таблиц, размеры базы данных (как в байтах, так и в числе таблиц), размеры регистрационного файла, число пользователей и т. д. так же ограничены, как и СУБД, не поддерживающая спектр платформ. Факторы, ограничивающие сложность запросов (в особенности те, которые определяют глубину рекурсии, например, размер стека), должны управляться динамически и не требовать остановки системы. Замена аппаратуры сервера более мощной конфигурацией не будет иметь никакого эффекта, если ограничения являются внутренними для СУБД.
Обычные узкие места архитектуры принимают форму невозможности динамической настройки сервера баз данных. Возможность настройки объема памяти, числа процессоров, числа одновременных процессов выполнения (нитей - "thread", процессов, виртуальных процессов) и числа разбиений таблиц, а также их распределение по диску без необходимости останавливать и перезапускать сервер позволяет отвечать изменяющимся запросам приложений. В идеальном случае каждая из перечисленных характеристик должна динамически изменяться в заданных пользователем пределах. Поддержка подзапросов и каскадных включений - типичные примеры рекурсии.
Производительность
В современных системах используются два основных метода повышения производительности - распараллеливание алгоритмов и многопроцессорная обработка при помощи нитей.
Распараллеливание алгоритмов
Одним из способов повышения производительности серверов баз данных является распараллеливание алгоритмов. Существует три типа распараллеливания, применимых к архитектуре сервера баз данных: параллельные операции ввода-вывода с диском, параллельные утилиты и параллельная обработка запросов. Параллельные операции ввода-вывода с диском позволяют серверу эффективно использовать многомерные таблицы и разбиение таблиц. Поддержка физического разбиения таблиц особенно важна для параллельного ввода-вывода с диском, при правильной реализации существенно возрастает эффективность и управляемость ресурсами. Параллельные операции-утилиты (сортировка, построение индексов, загрузка, резервирование, восстановление) используют как параллельную обработку, так и параллельные обмены с диском, однако обычно распараллеливание допускает лишь небольшое число компонент.
В отличие от параллельных обменов и параллельных утилит, параллельная обработка запросов имеет гораздо более сложный вид. Обработка запроса обычно требует обращения к нескольким неделимым операциям. Разложение и последовательность этих операций зависит от конкретного запроса, атакже план а выполнения,выбранного оптимизатором запроса. Обычно операции баз данных представляются в виде строгой последовательности: выход одной операции служит входом следующей. По существу, распараллеливание представляет собой подход типа "разделяй и властвуй" путем распределения одной работы между несколькими работниками. При этом работа разбивается на несколько мелких подзаданий, подзадания выделяются работникам, и тем самым происходит ускорение выполнения всей работы. Для поддержки параллельной обработки запроса применительно к серверу баз данных должны быть выбраны неделимые операции, которые могут быть скопированы и далее производить обработку фрагментов данных одновременно, а результаты их могут быть представлены так, как будто единая цепочка вычислений выполнила операцию. Достижение этой цели требует, чтобы запросы разбивались и обрабатывались независимо от способов коммуникации, возникающих вследствие аппаратной конфигурации. Создание множества копий данных операций баз данных, которые могут выполняться параллельно, называется горизонтальным параллелизмом.
Если каждая из операций баз данных разработана таким образом, что она управляется запросом (т.е. подход потока данных), сервер может использовать параллелизм, одновременно выполняя разные операции баз данных. Например, операция, выбирающая записи по значению поля, может выполняться одновременно с операцией доступа к записям с диска и не должна ждать, пока все записи будут считаны. Аналогично, выбранные записи могут быть загружены для сортировки для начального разбиения в соответствии с ключом сортировки, пока выполняются операции выбора и доступа. Вдобавок к независимости реализации от степени параллелизма проблемно-ориентированный подход допускает прозрачное включение новых существенно параллельных алгоритмов. Это позволяет использовать современные достижения в области алгоритмов для увеличения производительности.
Этот подход, напоминающий конвейер команд в современных процессорах, называется вертикальным параллелизмом. Сочетание вертикального и горизонтального параллелизма увеличивает общую пропускную способность и уменьшает время отклика по сравнению с обычным последовательным подходом. Степень улучшения называется ускорением.
Многопроцессорная обработка с помощью нитей
Метод обработки запросов пользователя, с которым связаны наименьшие накладные издержки, называется многопроцессорной обработкой с помощью нитей (отличается от моделируемой обработки). Нить как вариант процесса представляет собой управление контекстом, работающее под управлением одного процесса, он может быть либо порожден внутри процесса (например, сервер баз- данных), либо средствами ОС. Переключатель контекста процесса уровня ОС - это более дорогое действие, чем переключатель уровня самой нити, так же, как и операции создания и уничтожения процессов по сравнению с аналогичными операциями для нитей. В принципе, нити могут выполнять одновременные задания с помощью саморазмножения, создавая-нити, похожие на подпроцессы. Поскольку ОС не требуется создавать, распределять или прерывать множественные процессы, накладные расходы многопроцессорных баз данных, использующие нити, будут ниже, чем для других архитектур.
Архитектура, соответствующая настоящей многопроцессной обработке, основанной на нитях,позволяет получить более высокую степень разделения ресурсов, и похоже на то, что позволяет сделать производительность более устойчивой в зависимости от числа пользователей, а не от общей многопроцессной архитектуры. В дополнение следует сказать, что это обеспечивает также более высокую степень независимости модулей, поскольку выполнение логических операций может зависеть от событий, а не от потока управления. Это означает, что можно ожидать от программ сервера большей устойчивости при появлении новых функциональных возможностей.
При полном управлении ресурсами, а такое требование выдвигается реляционными СУБД, включая буферное пространство, дисковое пространство,блокировки, архитектура сервера баз данных, использующего нити, в значительной степени определяется существенно специализированной ОС, которая управляет выполнением нитей. Планировщик может либо обладать дисциплиной приоритетного обслуживания, либо нет. Планировщик, не обладающий такой дисциплиной, выполняет нити, пока те не сообщат ему о своем желании освободить процессор. Планировщики часто используют циклические алгоритмы, которые позволяют выполняться каждой нити, пока она не будет заблокирована или пока не истечет отпущенный ей квант времени. Такие планировщики эффективны для специализированных серверов баз данных; поскольку в таком случае число различных типов нитей невелико, они допускают непосредственное управление и их поведение предсказуемо. Для планировщиков, обладающих дисциплиной приоритетного обслуживания, выполнение нитей может прерываться планировщиком, например, вследствие необходимости выполнить нить с более высоким приоритетом. Такие планировщики эффективны в случаях, когда сервер баз данных вынужден делить ресурсы с другими приложениями, не являющимися приложениями баз данных.
Комплексная обработка в оперативном режиме Развитие систем в сторону OLCP характеризуется смешанным окружением, в котором OLTP, DSS и пакетная обработка используют одни и те же вычислительные ресурсы и обрабатывают одни и те же данные. Управление ресурсами, настройка и управление смешанной конфигурацией представляет из себя значительно более сложную задачу, чем в случае ее специализации. Разные типы поддерживаемых приложений часто требуют конфигураций систем, которые конфликтуют друг с другом. При последовательном смешанном выполнении новые приложения сами становятся смешанными. Со временем запросы и транзакции в такой конфигурации меняют свой характер и сами становятся более сложными. Разработка приложений идет от потребностей коммерческих приложений и в меньшей степени отображает процесс обработки данных. Поставщики СУБД часто разрабатывают различные версии своих продуктов для разных классов приложений. Например, сервер баз данных, ориентированный на работу в режиме OLTP, может зависеть от нескольких условий:
Поставщики СУБД, специализирующиеся на дисциплине OLTP, часто используют физические методы повышения производительности или выдвигают требование к приложениям, запрещающее взаимовлияние транзакций. Оптимизатор очередей СУБД не должен быть очень мощным, доступ к данным и методы обработки данных не требуют эффективности доступа и преобразования больших объемов данных. В смешанной конфигурации такие системы серьезно теряют в производительности и часто требуют недоступных уровней баз данных и сопровождения приложений.
Основными функциями архитектуры сервера баз данных, поддерживающими режим OLCP, являются оптимизация, эффектное управление ресурсами и параллельная обработка запросов.
Оптимизация
Возможности оптимизатора запроса сервера базы данных в большей степени определяет способность реляционной СУБД эффективно выполнять множественную обработку данных. Особенно важна способность оптимизатора запросов использовать подходящие индексы, ограничивающие выделенные строки, и обрабатывать запросы, ссылающиеся на различные таблицы. Оптимизатор не должен быть чувствителен к синтаксису SQL. Он должен быть чувствителен к статистикам данных и распределениям значений данных; таким образом можно оценить ожидаемую стоимость обработки запросов и выбрать схему, отвечающую наименьшим издержкам.
При обработке запросов могут чередоваться различные виды обработки для улучшения параллельности и используемости ресурсов. Для того чтобы реализовать это в надлежащем виде в реляционной СУБД, планировщик и оптимизатор должны тесно взаимодействовать, и должны учитываться также уровни изоляции всех одновременно выполняющихся транзакций.
Управление ресурсами
Эффективное управление ресурсами состоит из двух частей: прозрачной поддержки соответствующих ресурсов и эффективного использования специальных ресурсов. Критически важной является прозрачная поддержка ресурсов. Например, при разработке приложения в архитектуре клиент-сервер разработчик не может (и не должен) делать предположения о том, как клиент и сервер будут обмениваться сообщениями. На разработку не должно влиять то, какие средства используются - сетевые или общей памяти, при разработке также нельзя ограничивать их использование. Если реляционное приложение остается на той же физической платформе, что и база данных, то они могут эффективно синхронизовать информацию о состоянии через общую память. Это особенно важно при управлении блокировками и при установке буфера результата для интерфейса, управляемого курсором.
Одним из наиболее важных ресурсов является память. Управление выделением памяти в сервере баз данных так же важно, как и управление процессами на многопроцессной архитектуре с использованием нитей. Приложения реляционных СУБД используют память для поддержки состояния соединений, а также для кэширования запросов и результатов. В некоторых серверах память выделяется и управляется отдельно для каждого пользователя. Это означает, что данные или индексные страницы в памяти одного пользователя недоступны для другого, пока они повторно не считаны с диска. В других серверах используется освобождающаяся память для контекста процесса, что отличается от дисциплины с использованием нитей, когда для управления контекстом используется минимальный объем памяти. Без эффективного управления общей памятью архитектура сервера баз данных не способна удовлетворить всем требованиям, выдвигаемым OLTP, DSS и пакетной обработкой, оставляя сложные запросы и транзакции.
Если задание блокируется (например, ожидает некоторого ресурса типа ввода-вывода), важно, чтобы оно не продолжало держать ресурсы. Вместо этого средство выполнения (нить или процесс) должно сдвинуться для выполнения незаблокированного выполняемого задания. Важно знать часть задания, которая должна закончиться прежде, чем желательно освободить ресурсы; если это будет утверждением языка ЯН., ресурсы будут потеряны при блокировке задания. Например, в окружении OLCP утверждение SQL в пакетном режиме может послужить препятствием для удовлетворения требований по времени отклика для критического приложения OLTP.
Параллельная обработка запросов
Параллельная обработка запросов позволяет решить проблему низкой производительности для сложных запросов и объемных баз данных. Получая доступ и обрабатывая данные параллельно,параллельная обработка запросов может привести к существенному увеличению производительности для DSS и пакетной обработки. Такое увеличение производительности позволяет включать сложные запросы в транзакции читать/писать без ущерба для целостности данных и изоляции транзакций. При подходящей величине времени отклика очереди DSS, которые были бы невозможны на традиционных системах, становятся возможными и не конкурируют разрушительным образом с приложениями OLTP.
Доступность. Основными характеристиками доступности являются сопровождение в оперативном режиме и устойчивость.
Сопровождение в оперативном режиме
В идеальном случае утилиты сопровождения должны поддерживать непрерывные операции, с помощью которых система должна редуцировать или даже исключать плановые и неплановые неполадки. Часто в реляционных СУБД приходиться выходить в режим off-line, чтобы выполнить некоторую утилиту. Утилиты для загрузки, резервирования, восстановления,проверки целостности, реорганизации индексов и т.д. должны допускать выполнение в оперативном режиме. Если происходит сбой во время выполнения этих операций, утилита не должна быть запущена с начала операции. Например, могут выполняться периодические проверки или даже полное протоколирование, позволяющее запускать утилиты с места сбоя. Другие возможности, такие как автоматическое архивирование и архивирование в оперативном режиме полных протоколов, автоматический перезапуск (без дополнительных операторов), управляемые времена перезапуска системы имеют также большое значение; это минимальный набор тех операций, которые могут потребовать, чтобы реляционная СУБД вошла в режим off-line.
Задачи сопровождения, такие как мониторинг и управление ресурсами, часто оказывают взаимное влияние с доступностью. В идеальном случае такие операции, как резервирование, загрузка, создание индексов, переорганизация индексов, не должны требовать, чтобы какой-нибудь элемент данных (таблица, часть таблицы или база данных) был недоступен либо для чтения, либо для записи. Необходимость перевода элемента данных в режим on-line не должна влиять на доступ к другим элементам данных. Аналогично, физическое положение базы данных, реорганизация, управление памятью, архивирование протоколов и перезапуск системы должны иметь минимальное воздействие на приложение.
Сервер баз данных должен иметь гибкие возможности мониторинга, позволяющие пользователю строить собственные приложения. Такие функциональные возможности универсальных вычислительных систем, как несопровождаемые и планируемые операции, являются очень важными. Возможность добавления дополнительных накопителей на ленте и поддержка параллельных утилит (резервирование, восстановление, загрузка и т. д. ) существенны для высокой доступности и эффективности OLCP.
Устойчивость
Под устойчивостью мы понимаем то, что реляционные СУБД уменьшают важность конкретных сбоев и прозрачно восстанавливаются после них. Реляционные СУБД должны обеспечивать доступ к данным как по чтению, так и по записи независимо от обстоятельств, включая аппаратуру системы, а также выход из строя отдельных компонент. Системы, обладающие такими свойствами, будут называться отказоустойчивыми. Отказоустойчивые системы часто основываются на других формах избыточности. Два основных типа - аппаратурная избыточность и избыточность по данным.
Аппаратная избыточность систем может использовать полностью избыточные платформы, отдельные процессоры, сдвоенные диски и т. д. Обычным явлением является зеркалирование аппаратуры, при котором один диск используется как копия друтого и защищает его от сбоев. Хотя аппаратная избыточность и имеет важные значения для отказоустойчивости, она не интегрируется с требованиями сервера баз данных. Она нечувствительна к границам транзакций, неделимых чтение/записи, и вообще СУБД не может использовать выгоды избыточности такого рода для увеличения производительности.
Избыточность по данным возникает в двух формах: программного зеркалирования и копирования. Программное зеркалирование, называемое также дуплексированием и мультиплексированием, может использоваться как для устойчивости относительно аппаратных сбоев, так и для оптимизации произво- дительности. Оно представляет из себя процесс, с помощью которого СУБД копирует единицу данных (например, область таблицы, область базы данных, порцию данных или логическое устройство) на другое физическое устройство. В частности, копирование определено как зеркало, и любая запись прозрачно записывается на зеркало. Операции чтения могут быть распределены между первоначальным устройством и его зеркалом, что приводит к увеличению производительности за счет побочного эффекта зеркалирования. Конечно, зеркалирование может принести мало пользы, если копии делаются на том же самом физическом устройстве.
В случае выхода устройства из строя, например, вследствие аппаратного сбоя, испорченная копия должна автоматически выводиться в режим логического off-line, и все чтения и записи направляются на неиспорченную копию. Пользователь не должен чувствовать никаких прерываний в случае наступления сбоя. После того как испорченное устройство заменено или отремонтировано, оно может быть синхронизировано с неповрежденной линией с помощью процесса, известного как перезеркалирование в оперативном режиме.
Копирование похоже на зеркалирование с той лишь разницей, что копия может быть локализована, не должна быть синхронно обновлена и позволяет копировать целую базу данных. При использовании для копирования целой базы данных целью обычно является создание "горячего резерва". Однако некоторые реализации используют преимущество создания резервной копии доступной лишь для доступа по чтению. Это может обеспечить существенный выигрыш для смешанных конфигураций, допускающих DSS, создание отчетов и другие пакетные приложения, использующие только чтение с резервных копий, в то время как приложения OLTP обновляют исходную систему.
Развитие архитектур баз данных
Итак, в качестве основных требований применительно к развитию архитектур серверов баз данных следует выделить:
Обзор трех продуктов**)
INFORMIX - OnLine Dynamic Server
INFORMIX - OnLine Dynamic Server (доступен, начиная с Версии 6) построен вокруг INFORMIX OnLine Dynamic Scalable Architecture (DSA - динамически расширяемая архитектура). INFORMIX - OnLine Dynamic Server состоит из реляционной СУБД со связанными и полностью интегрированными средствами:
- Настоящая многопотоковость, средства распределенных баз данных, симметричная многопроцессорность, параллельный ввод/вывод с диском, параллельные утилиты, поддержка горячего резерва, поддержка связанных многопротокольных сетей (Версия 6).
- Параллельная обработка запросов, разбиение таблиц, резервирование и восстановление уровня разбиения таблиц, дополнительные средства поддержки больших баз данных (Версия 7).
- Слабосвязанная многопроцессорность и массивнопараллельная обработка (Версия 8).***)
Oracle 7
Oracle 7 состоит из реляционной СУБД и трех опций, представляемых за отдельную плату:
Sybase System 10
Sybase System 10 состоит из реляционной СУБД SQL Server и ряда других серверов:
- Control Servers - семейство продуктов, обеспечивающих оперативное управление в распределенной конфигурации. В настоящий момент состоит из SA Companion (сопровождение и управление) SQL Monitor (мониторинг и настройка), Configuration (планирование и разработка), Audit Server (справки по доступу и операциям) и Backup Server (высокоскоростное параллельное резервирование, загрузка и восстановление). Из перечисленных выше лишь Backup Server связан с SQL Server и требует дополнительной оплаты.
- Replication Server - опция дублирования данных в распределенной конфигурации.
- OmniSQL Gateway - разнородный шлюз чтения-записи для SQL Server, DB2 и Oracle, обеспечивающий распределенную обработку запросов.
- Navigation Server - объявленная опция SQL Server 10, предназначенная для слабосвязанных систем, с массовым параллелизмом.
INFORMIX - OnLine Dynamic Server
INFORMIX - Online Dynamic Server использует многопотокувую (true multi-threaded) архитектуру. Многие одновременные нити распределяются, исходя из доступности ресурсов. Хотя указанные процессы могут "прерываться" аналогичным с более высоким приоритетом (в том смысле, что следующий квант времени будет выделен новому процессу, а не тому, который был распределен первым), планировщик не обладает дисциплиной приоритетного обслуживания. Нити распределяются независимо от механизма планировщика ОС конкретной платформы. Как отмечалось при обсуждении требований к архитектуре сервера баз данных, управление ресурсами с помощью нитей более эффективно, чем с помощью многопроцессорной архитектуры.
INFORMIX - Online DSA обеспечивает поддержку SMP-систем с помощью нитей. В последующих версиях архитектура будет расширена таким образом, чтобы поддерживать слабосвязанные системы, а также MPP-системы. Он состоит из множества виртуальных процессоров, каждый из которых выполняет с помощью переключения контекста несколько нитей. Виртуальный процессор назначается на реальный процессорный элемент, когда это становится возможным, и представляет из себя процесс ОС. Виртуальные процессоры делятся на два класса. Для одного класса число виртуальных процессоров может изменяться пользователем, а для другого - динамически самой системой. В DSA виртуальные процессоры кажутся клиенту, как если бы они были единственным сервером.
Три типа очередей заданий существует в системе DSA очереди готовых заданий (нитей, которые готовы к выполнению и ждут соответствующего сигнала) различаются приоритетами, очереди ожидания (ожидающие такого события, как освобождение ресурса) и "спящие" очереди (неактивные процессы). Планирование нитей не обладает дисциплиной приоритетного обслуживания. Виртуальные процессы присваиваются заданиям из очереди готовых по принципу FIFO ("первым вошел - первым вышел"), таким образом распределяя готовые к выполнению задания. При блокировке процесса (из-за занятости канала обмена), например, он помещается в очередь ожидания. Процессы, ждущие клиента, также помещаются в очередь ожидания. После того как процесс становится готовым к выполнению (например, из-за снятия блокировки), он помешается в очередь готовых заданий, из которой он может быть приписан к виртуальному процессору.
Параметр конфигурации позволяет пользователю задать максимальное число виртуальных процессоров, и этот параметр оказывает влияние динамически. Управление сетью и другие существенные средства интегрированы в DSA. Таким образом, система не чувствительна к сбоям отдельных процессорных элементов.
Параллельные обмены с диском, параллельные утилиты и параллельные запросы - составная часть DSA. Каждая неделимая операция базы данных (называемая итератором), участвующая в обработке запросов, представляется в виде одной или нескольких одновременных нитей. В дополнение к этому, каждая операция базы данных реализована с использованием модели потока данных: это означает, что она начинает выполняться, как только становятся доступны все необходимые входные данные, и предоставляет результаты вычисления для других операций, как только они получены. Такая архитектура делает возможным параллельное присвоение процессов таким заданиям, как доступ, сортировка, слияние, фильтрация данных (накладывание ограничений) и т.д., примерно так же, как сотрудники иногда делят общую задачу. Это и называется вертикальным параллелизмом. Но различные задания могут выполняться и параллельно (горизонтальный параллелизм), что напоминает организацию труда на конвейерной линии. Так же, как и при планировании промышленных поставок используется принцип "точно в срок", такой же принцип используется и при обработке данных.
При параллельной реализации запросов особую важность имеет концепция оператора обмена. Этот оператор защищает операторы преобразования данных от всякого рода параллелизма, что обеспечивает прозрачность и СУБД, и приложений от конкретных проблем архитектурных платформ, как, например, не важно, где установлена система - на однопроцессорной системе, SMP-системе, слабосвязанной системе или MPP-системе. Оператор обмена представляет группу итерантов в виде отдельной, не распределенной операции. Тем самым пользователям предоставляется единое средство, которое можно использовать на однопроцессорной архитектуре, SMP, слабосвязанной, МРР без необходимости переделывать приложения.
Операции параллельной обработки данных выигрывают от физического разбиения данных. Данные могут быть разделены в дисковом пространстве на основе четырех методов: разделение по ключу (key partitioning) может использоваться для задания разбиений на основе диапазонов значений индексных ключей; хэширование возможно с помощью алгоритмов хэширования; разделение по выражению может использоваться для разделения на основе выражения SQL, индивидуальные таблицы могут размещаться на отдельных дисководах.
INFORMIX-OnLine Dynamic Server поддерживает программное зеркалирование файлов баз данных, таких как файлы баз данных, индексные файлы, файлы протоколов. Эта система способна использовать зеркальную копию для увеличения производительности на операциях чтения/записи, а также может прозрачно продолжать выполнение операции, если один диск из зеркальной пары дает сбой. Система позволяет добавить новый диск в операцию зеркалирования без прерывания операции чтения/записи.
INFORMIX-OnLine Dynamic Server обеспечивает возможность горячего резервирования. Это средство достижения отказоустойчивости позволяет скопировать протокол транзакций исходной системы в удаленную память. Идентичная копия исходной базы данных, предназначенная только для чтения, обновляется из переданных элементов протокола транзакций. Обновление может происходить либо синхронно, либо асинхронно.
Вторичная база данных доступна в режиме on-line только для чтения. Таким образом, она поддерживает только процесс принятия решений, основанный исключительно на операциях чтения, создания отчетов, приложений, ориентированных на анализ,не влияя на приложения, использующие доступ к исходной базе данных, как по чтению, так и по записи. В случае сбоя при работе с исходной базой данных, переключение на вторичную для работы в стандартном режиме сервера может быть автоматическим или ручным. Пользователи смогут снова выполнять операции чтения/записи после окончания переключения. Это может произойти тремя способами: автоматически (на основе переменной окружения, содержашей информацию об альтернативном способе соединения), программно (на основе соответствующего программного кода) или вручную.
INFORMIX-OnLine Dynamic Server обеспечивает несколько средств гибкого мониторинга как конфигурационной информации, так и деятельности. Средства ONARCHIVE и ONTAPE предназначены для операций резервирования и восстановления. Поддерживаются сопровождение в режиме on-line и динамическая настройка. Резервирование (инкрементное и полное) может быть выполнено в оперативном режиме на уровне базы данных и фрагментов базы данных. Некритичные фрагменты базы данных могут быть восстановлены в то время, когда остальная часть базы находится в оперативном режиме. Резервирование и восстановление таблиц может быть выполнено, если один или несколько фрагментов заняты одной таблицей. Способ разбиения таблиц может быть определен и изменен в оперативном режиме. Хотя большинство конфигурационных параметров может быть изменено в режиме off-line, те, которые имеют наибольшее значение, с точки зрения SMP и параллелизма (максимальное число используемых нитей, число виртуальных процессов для чтения/записи и для процессорных элементов, максимальный размер общей виртуальной памяти), могут изменяться в оперативном режиме. Кроме того, размер стека может устанавливаться системой динамически и автоматически для обеспечения лучшей поддержки рекурсии.
Oracle 7
Хотя про одну из конфигураций Oracle 7 и говорится, что она является многопотоковым сервером ("multithreaded server"), в системе фактически используется разделяемый мультипроцессный подход для реализации моделируемой многопроцессности с помощью нитей. Подход Oracle 7 использует ровно один процесс для каждого одновременно обрабатываемого запроса пользователя, при этом пользователям разрешается разделять множество процессов. Входные процессы обрабатываются специальными процессами, называемыми диспетчерами. Диспетчер приписывает запрос процессу сервера из общего пула. Максимальное число серверов может быть изменено командой ALTER SYSTEM, однако действие будет иметь эффект только после остановки и перезапуска Oracle 7.
В отличие от нитей, процессы сервера распределяются на уровне SQL-запросов и не управляют их собственным контекстом, подобно тому как процессы распределяются в многозадачной операционной системе. Сервер Oracle 7 выполняет переключение заданий для множества процессов. Процесс переключения основан на приеме нового запроса (утверждения SQL) в очередь FIFO, а не на перераспределении ресурсов (до тех пор, пока не будет решено, что процессы сервера являются единственным ресурсом, подлежащим распределению). В результате может случиться, что процесс сервера, а не нить, обладающая низкими накладными расходами, может быть заблокирован ожиданием чтения/записи, памяти или других системных ресурсов. В действительности же процессы сервера вообще не распределяются, если только операционная система не выполняет этой функции (как это может быть в окружениях SMP и МРР).
Существует проблема, связанная с таким типом архитектуры, которую Oracle называет "искусственный дедлок". Эта ситуация возникает в случае, когда сервер получает исключительную блокировку, которая нужна другим серверам, однако этот сервер освобождается и используется другим пользователем. Если другие серверы недоступны для обработки утверждений транзакции, обрабатывающей эксклюзивную блокировку, Oracle 7 пытается запустить новый сервер. Если максимальное число серверов (статический конфигурационный параметр) уже было запущено, DBA должна отключить одного из пользователей в ручном режиме.
Такая архитектура уменьшает число процессов, которыми может управлять операционная система. Она также уменьшает вероятность того, что какой-нибудь процесс будет находиться в пассивном состоянии (в сравнении с архитектурами, в которых для каждого пользователя создается процесс сервера). Поскольку стоимость управления множественными процессами является нагрузкой для операционной системы, такая архитектура будет менее эффективной, чем использующая настоящую многопотоковость с использованием нитей.
Parallel Server Option в Oracle 7 является дополнительным средством, разработанным специально для поддержки слабосвязанных многопроцессорныхсистем, его модификации используются для поддержки систем SMP и МРР. Это позволяет отделить выполнение отдельных "примеров" Oracle на каждом процессоре, разделяя общий доступ к файлам баз данных. Основным требованием при этом является разделение всеми процессорами общих дисков. Данная архитектура не предполагает наличия общей памяти. Вместо этого используется схема распределенного кэша, согласно которой каждый процессор имеет собственный кэш.
Основная разница между Oracle 7 и Parallel Server Option состоит в добавлении параллельного управления кэшем. Каждый пример имеет свой собственный буферный кэш, однако взаимодействует с другими примерами для получения копий данных и поддержания их в подвижном состоянии. Данные в кэш-памяти копируются, модифицируются и групируются постранично (блоки данных), а не на уровне таблиц или строк. Блок данных может содержать несколько строк. В произвольный момент времени лишь одна копия блока данных может быть изменена.
Если примеры соревнуются из-за страниц, то это может привести к тому, что будет тратиться слишком много времени на пересылки страниц между диском и кэш-памятью и недостаточно для обработки данных. Это значит, что Oracle Parallel Server может не подойти к некоторым приложениям. Он работает наиболее эффективно, когда транзакции, обрабатываемые отдельными процессорами, не конфликтуют по данным или индексам и когда не требуется высокая степень изоляции транзакций. В SMP-окружении архитектура Oracle 7 может позволять переключаться с неисправного процессора на другой для принятия очередного SQL-утверждения.
Oracle Corporation объявила о поддержке параллельных утилит и параллельной обработки запросов в Версии 7.1, хотя поставка соответствующих средств займет несколько месяцев и будет иметь вид поддержки версии. Полная версия будет использовать модель exchange/iterator, а операции баз данных будут реализованы в виде процессов, а не нитей. Средства параллельной обработки, вероятно, будут оформлены в виде дополнительного средства, а не части стандартного продукта.
Oracle 7 поддерживает ограниченное программное зеркалирование. В частности, управляющий файл базы данных и протокол могут быть скопированы, однако эти копии не используются для оптимизации чтения и записи и не допускают мультиплексирования файлов данных и индексов. Oracle 7 не поддерживает удаления зеркал в оперативном режиме и презеркалирования. Аппаратное зеркалирование в случае поддержки его операционной системой, совместимо с Oracle 7.
Хотя в Oracle 7 нет специальных средств отказоустойчивости, Parallel Server Option позволяет нескольким серверам разделять доступ к базе данных. Если у одного из серверов происходит сбой, то другие возвращают себе доступ. Такое решение требует доступа к общему диску и вследствие этого не защищено от возможных местных сбоев.
Средство Oracle 7 SQL*DBA обеспечивает возможности мониторинга в оперативном режиме, резервирования и восстановления команд, остановки сервера. Oracle 7 поддерживает резервирование и восстановление таблиц (логическая единица хранения) в режиме off-line, в то время как остальная часть базы данных находится в оперативном режиме. Если пространство таблиц не содержит частей более, чем одной таблицы, это будет означать, что таблицы могут резервироваться и восстанавливаться независимо. Большинство конфигурационных параметров устанавливается в файле и может быть изменено в режиме ой-line. В числе этих параметров находится и максимальное число процессов, которое поддерживает разделяемую многопроцессорную конфигурацию.
Sybase System 10
Компоненты Sybase System 10 используют однопроцессорную архитектуру с настоящими многопроцессорными возможностями с использованием нитей. Нити распределяются на основе достижимости ресурсов. Процессы могут прерываться процессами с более высоким приоритетом (в том смысле, что новому процессу выделяется очередной квант времени), если они не выполняют критическую часть программы. В SQL Server процессы планируются с помощью операционной системы базы данных, а не операционной системы конкретной платформы. Он не обладает режимом приоритетного обслуживания, однако можно сказать, что это не относится к реляционным СУБД, поскольку нити возвращают управление сразу после критической секции непосредственно перед следующей. Стандартный продукт поддерживает параллельные обмены с дисками и параллельные утилиты (загрузку, резервирование, восстановление) через Backup Server, но не поддерживает разбиение таблиц.
Стандартный компонент System 10 SQL Server, разработанный для поддержки SMP-систем - Virtual System Architecture (VSA). VSA состоит из множества серверов, каждый из которых представляет из себя кооперативный процесс. Сервер состоит из множества нитей и представляет "процессорную мощность величиной в процессорный элемент", хотя серверы не привязаны к конкретным процессорным элементам (они присваиваются динамически по мере доступности процессорных элементов). VSA дает возможность множеству серверов появляться перед клиентом в виде одного сервера.
В системе VSA существует две очереди - активная и пассивная. Серверы пытаются получить операции из активной очереди. Когда операция блокирована, она помещается в пассивную очередь. Если операция становится выполняемой (из-за снятия блокировки, например), она помещается в активную очередь, из которой может быть обслужена следующим доступным сервером.
В архитектуре существуют некоторые критические точки, которые делают ее чувствительной к отказам. Например, управление сетью осуществляется только одним процессорным элементом. Если он выходит из строя, то и вся система тоже. Отказы в некоторых других местах могут вывести из строя сервер. Конфигурационный параметр позволяет пользователю задать максимальное число серверов, работающих в оперативном режиме, однако само это действие нельзя выполнить в оперативном режиме.
Navigation Server - дополнительный компонент System 10, обеспечивающий параллельную обработку запросов, а также сортировку и индексирование. В первой версии он поддерживает слабосвязанные многопроцессорные системы. Утверждается, что этот подход позволит поддержать платформы SMP и МРР. Параллельная обработка и разделение данных используются для уменьшения времени отклика и поддержки больших баз данных без ущерба для производительности. Пользователи считают данные принадлежащими одной базе данных, а Navigation Server имеет вид SQL Server. В будущем будет существовать возможность одновременной поддержки Open Server 10, Open Client 10, SQL Server 4.9 или SQL Server 10. Первоначально будет существовать возможность поддержки платформ лишь NCR UNIX.
Nevigation Server представляет из себя разделяемую многопотоковую архитектуру, состоящую из двух основных компонент: DBA Server и Data Server, каждая из которых может быть дублирована. Data Server обычно состоит из Control Server, Split Server и SQL Server. в число дополнительных компонент входит Schema Server, Administrative Services и Configurator. После приема запроса Control Server он передается в DBA Server для распараллеливания, компиляции и оптимизации. Если запрос представляет из себя хранящуюся процедуру, он напрямую передается на ЯН. Server. В противном случае он загружается в память для выполнения.
Операции параллельной обработки данных зависят от разбиения данных. Данные могут быть распределены между Data Servers на основе трех подходов. Во-первых, ранжирование (range partitioning) может быть использовано для разбиения данных в зависимости от значений произвольного индексного ключа. Во-вторых, хеширование (hash partitioning) может быть применено с помощью алгоритмов хеширования. В-третьих, индивидуальные таблицы могут быть размещены в конкретных Data Servers. Такой подход называется размещением с помощью схем (schema partitioning). Каждый из этих методов может использоваться в Navigation Sever одновременно. В первой версии данные не могут разбиваться вертикально.
SQL Server поддерживает программное зеркалирование на уровне логических устройств, а не на уровне физических устройств или базы данных. Если зеркальная копия выходит из строя, то автоматически востребывается оставшаяся копия. Логические устройства могут быть определены как зеркальные копии в оперативном режиме. Как зеркалирование, так и перезеркалирование прозрачны для чтения и записи.
Sybase System 10 имеет два средства отказоустойчивости. Первое, Replication Server, обеспечивает "горячий" резерв. Этот продукт передает команды, отвечающие элементам транзакций, в одну или несколько отдаленных позиций, где они применяются к удаленной копии базы данных. Обновление происходит асинхронно.
Пользователи определяют, какая часть таблиц может быть скопирована. Хотя пользователи должны определять, что каждая таблица базы данных должна быть скопирована в удаленное запоминающее устройство, существует возможность копирования всей базы данных. В качестве альтернативного первичному может разрабатываться специальное вторичное. В случае сбоя первичного, берется вторичное. Транзакции, не выполненные с активными первичными файлами, автоматически изымаются. Приложения должны восстанавливать эти транзакции путем переназначения на альтернативное устройство после повторного соединения.
Companion Server (известный для некоторых платформ как Fault Tolerant Option) предназначен для защиты от неисправностей процессоров в слабосвязанном окружении, в случае, когда процессоры разделяют общее дисковое пространство. Процесс SQL Server разработан как Companion Server, а другой процесс SQL Server - как активный сервер. Companion Server остается в пассивном состоянии, пока заданный SQL Server процесс не закончится неудачей, после чего автоматически запускается и берет обработку на себя. Механизм, используемый для диагностики данного события, известен под названием "deadman latch" и представляет из себя взаимоисключающую блокировку ресурса, выполняемую устройством, которого ожидает Companion Server. Если SQL Server по какой-либо причине выходит из строя, он эффективно освобождает схему-защелку, позволяющую Companion Server получить доступ к ресурсу. Активные приложения получают сообщение об ошибке, состоящей в потере соединения. Все транзакции, "пострадавшие" от остановки SQL Server, автоматически изымаются и должны быть восстановлены приложением. После этого Companion Server становится доступен для выполнения пользовательских приложений.
Мониторинг в оперативном режиме конфигурации и функционирования Sybase System 10 поддерживается опцией SQL Monitor и большим числом поставляемых вместе с системой встроенных процедур, обеспечивающих доступ к системному каталогу. Предоставляются различные интерактивные средства выполнения операций резервирования, восстановления и остановки. Резервирование может быть выполнено в оперативном режиме и быть либо инкрементным, либо полным. Однако операции восстановления могут быть выполнены только в on-line. За редким исключением изменение конфигурационных параметров является статическим и проявляется только после перезапуска системы. В этом смысле особую важность имеет число серверов и емкость памяти. К тому же, размер стека фиксирован в программном коде сервера и не может быть изменен ни динамически, ни вручную.
*) Появление новых версий ожидается в течение года (прим. ред.).
**) Более подробно ознакомиться с различными аспектами параллельных архитектур СУБД, а также с их реализацией в продуктах, анонсированных в течение последнего года можно в журнале "Системы Управления Базами Данных" # 2 1995.
***) Copyright 1994 Alternative Technologies. Материал предоставлен Ассоциацией пользователей UNIX.
