- Управление, конфигурирование, статус
- Резервирование журналов, архивирование, восстановление
- Мониторинг характеристик производительности
- Анализ, экспертная помощь в физическом конфигурировании данных
- Параллельная загрузка баз данных
- Управление тиражированием для распределенных баз данных
- Управление реляционными объектами
Изначально платформой для реализации очень больших баз данных (Very Large Databases - VLDB) служили симметричные многопроцессорные системы (Symmetric MultiProcessor - SMP), способные эффективно обрабатывать большие объемы информации и обладающие хорошим соотношением цена/производительность. Сейчас многие компании и потребители, среди которых сегодня немало уже и пользователей из коммерческих приложений, обращают свои взоры к системам с массовым параллелизмом (MPP) и слабосвязанным (кластерным) системам, что объясняется двумя их основными преимуществами - высоким потенциалом отказоустойчивости и более широкими воможностями наращивания производительности. Для больших коммерческих систем совершенно недопустимо, чтобы в результате аппаратного или программного сбоя данные оказались недоступными для пользователей. Те же проблемы возникают, если необходимо установить новую версию операционной системы или сервера СУБД. Статья посвящена архитектуре и основным возожностям сервера Informix-OnLine Extended Parallel Server (OnLine XPS) [1], предназначенного для слабосвязанных систем и систем MPP.
MPP- и слабосвязанные системы, называемые часто архитектурами без разделяемых ресурсов, представляют собой быстрые сети, связывающие однопроцессорные или симметричные многопроцессорные системы - узлы. Если база данных сосредоточена не на единственном узле, а поделена между множеством узлов, то отказ одного из них приведет лишь к недоступности относящихся к нему данных. Остальные данные будут попрежнему доступны пользователям. Если же в конфигурации предусмотрено аварийное переключение узлов, то доступ к данным отказавшего узла будет автоматически возобновлен через дублирующие узлы.
Для приложений поддержки принятия решений (Decision Support Systems - DSS), имеющих сложный аналитический характер и предполагающих обработку очень больших массивов данных, критичной может оказаться способность платформы к наращиванию мощности параллельных вычислений. Число процессоров, которые реально способны поддерживать сегодняшние системы SMP, ограничено пропускной способностью системной шины; их практическая масштабируемость обеспечивается лишь с ростом количества процессоров до 32. Слабосвязанные и MPP-системы, узлы которых соединены высокоскоростными линиями "точка-точка", обладают неограниченной аппаратной масштабируемостью. Узлы не привязаны к общей системной шине или операционной системе, поэтому возможна поддержка произвольного числа процессорных узлов и обеспечение необходимого для приложений DSS роста производительности.
Преимущества аппаратных платформ без разделяемых ресурсов - это лишь предпосылки к созданию высокопроизводительной и устойчивой к отказам среды баз данных, их потенциал невозможно реализовать без новых архитектур серверов СУБД. Однако, многие существующие сегодня СУБД не способны в полной мере использовать преимущества аппаратных платформ этого типа.
Сервер Informix Online Extended Parallel Server (OnLine XPS) как раз и предназначается работы в слабосвязанных системах и системах MPP. OnLine XPS продолжает линию серверных продуктов Informix нового поколения, начало которой было положено в 1993 г., когда вышла модель сервера InformixOnLine Dynamic Server (OnLine DS) 6.0, предназначенная для однопроцессорных и многопроцессорных SMP-систем [2]. Основное ее отличие от более ранних серверных продуктов Informix - многопотоковая масштабируемая архитектура, которая на платформах SMP обеспечивает эффективную обработку как множества одновременно поступающих запросов в приложениях OLTP, так и сложных аналитических запросов, предполагающих просмотр больших массивов данных. Многие технологические решения, принятые в OnLine DS, - фрагментация данных, вертикальный и горизонтальный параллелизм обработки запросов, средства повышения отказоустойчивости, оперативное администрирование - получили развитие в реализации OnLine XPS, где они были дополнены и видоизменены в соответствии со спецификой аппаратных платформ без разделения ресурсов.
Основы проекта Informix-OnLine XPS
В качестве основополагающих для проекта Informix-OnLine XPS были приняты следующие критерии:
- Утилизация всех доступных аппаратных ресурсов, инкрементальная производительность. Достижению этой цели служат принципы фрагментации данных и фрагментации обработки, которые позволяют разбить запрос на подзадачи, выполняемые параллельно на множестве наличных узлов. Существенно с этой точки зрения также отсутствие потенциально узких мест в архитектуре сервера, которая не предполагает наличия одного центрального узла, координирующего деятельность рабочих узлов.
- Высокая доступность и отказоустойчивость. Реализованные в OnLine XPS механизмы аварийного переключения узлов, зеркалирования дисков, тиражирования и др. в совокупности способны обеспечить требуемый уровень доступности данных с учетом потребностей приложений и возможностей аппаратуры. Плановые простои сервера практически полностью исключаются, благодаря возможности выполнять административные действия в оперативном режиме.
- Централизованное управление. Администраторы и пользователи имеют единую точку обзора и управления кластерными, MPP и сетевыми конфигурациями серверов баз данных, содержащими взаимосвязанные информационные ресурсы. Инструменты администрирования позволяют централизованно осуществлять наблюдение за состоянием и производительностью серверов и отдельных узлов, управлять реляционными объектами, контролировать операции сохранения и восстановления данных.
- Совместимость разных моделей серверов. Приложения, разработанные для однопроцессорных или SMP-платформ и выполняющиеся на сервере OnLine DS, без всяких изменений будут работать и на кластерных или MPP-платформах с сервером OnLine XPS. При переносе на другой тип платформы с той же операционной системой не требуется даже перекомпиляции приложений. Переносимость приложений основана на том, что все решения, связанные с распараллеливанием запросов, принимаются и реализуются ядром сервера - прикладной код не содержит указаний о параллельной обработке. Другой фактор, обеспечивающий переносимость - это совместимость прикладного кода, которая исторически всегда поддерживалась для различных моделей серверов Informix.
- Поддержка недорогих открытых аппаратных платформ. Многие поставщики открытых платформ сегодня предлагают кластерные или MPP архитектуры, обладающие вполне конкурентоспособным соотношением цена/производительность. В настоящее время OnLine XPS доступен для платформ IBM SP2, ICL Goldrush, АТ&Т 5100; планируются реализации для платформ Pyramid/SNI Reliant RM1000, а также кластерных платформ HP, Intel, Sequent, Silicon Graphics и Sun. Предполагается, что в перспективе будет обеспечена поддержка всех платформ этих типов, работающих под управлением ОС UNIX. OnLine XPS поддерживает стандарты SQL (ANSI-89, уровни 1, 2, ANSI-93, входной уровень, FIPS-127-1). Таким образом, Informix стремится предоставить своим клиентам свободу выбора аппаратных платформ и возможность миграции в будущем на новые, прогрессивные платформы.
Обзор архитектуры OnLine XPS
Подобно аппаратным платформам, для которых он предназначен, OnLine XPS построен на принципах неразделения ресурсов, что способствует снижению нагрузки на операционную систему и сокращению сетевого трафика. Независимость узлов выражается в том, что каждый из них выполняет свой экземпляр программного обеспечения СУБД, которое включает сервисы протоколирования, восстановления, управления блокировками и управления буферами. Узел, на котором выполняются эти сервисы, называется косервером.
Каждый ко-сервер "владеет" некоторым набором дисков и размещенными на этих дисках фрагментами баз данных. Как правило, ко-сервер имеет физический доступ к дискам других ко-серверов для целей аварийного переключения, но в нормальном режиме он работает только со своими дисками.
В целях оптимизации на всех узлах может быть кэширован системный каталог, содержащий информацию о распределении данных по узлам. Из тех же соображений небольшие часто используемые таблицы также, вероятно, будут тиражированы на все узлы.
Несмотря на то, что каждый узел выполняет свой экземпляр СУБД, совокупность ко-серверов с точки зрения пользователей и администраторов в целом будет выглядеть как единый сервер OnLine XPS. Каждый косервер для выполнения поступающих к нему запросов взаимодействует с другими ко-серверами OnLine XPS. Например, если требуется произвести соединение данных из нескольких таблиц, то выполнение операций сканирования, соединения и сортировки будет распределено между несколькими ко-серверами.
Программное обеспечение ко-серверов содержит компоненты, отвечающие за разбиение запроса на подзадачи и их распределение между косерверами.
- Менеджер запросов (МЗ) - это компонент, ответственный за принятие решений о том, как разбить поступивший запрос на подзадачи и распределить их между узлами с соблюдением баланса загрузки. МЗ пользуется услугами других компонентов: оптимизатор запросов находит наилучший способ выполнения запроса, менеджер метаданных сообщает информацию о местонахождении данных, планировщик распределяет подзадачи между узлами.
МЗ ко-сервера, к которому подключается пользователь, называется первичным МЗ для данного пользовательского сеанса. Если выполнение запроса распределяется между несколькими узлами, то первичный МЗ передает контекстную информацию МЗ других ко-серверов, с тем чтобы они могли установить у себя соответствующий контекст пользовательского сеанса.
- Оптимизаторзапросов отвечает за нахождение наилучшего способа выполнения заданного запроса. Выбор основывается на оценках стоимости необходимых ресурсов. Это значит, что оптимизатор генерирует множество возможных планов реализации запроса, вычисляет стоимость каждого из них и выбирает план с минимальной стоимостью. Генерируемые планы реализации запроса различаются, например, порядком чтения таблиц, способом чтения (по индексу или последовательно), алгоритмами соединения таблиц. Степень распараллеливания запроса определяется на основе метаданных.
- Менеджер метаданных (ММД). Метаданные представляют собой информацию о распределении данных по узлам. Метаданные каждой базы, как правило, сосредоточены на одном узле, а для обеспечения отказоустойчивости может поддерживаться их зеркальная копия. ММД ко-серверов взаимодействуют между собой, в совокупности обеспечивая каждому узлу доступность метаданных всех баз, хранящихся на конкретном сервере OnLine XPS. Изменения метаданных система выполняет прозрачным образом, хотя фактически они производятся ММД того ко-сервера, на котором эти метаданные располагаются.
- Планировщик. Задача планировщика - распределять выполнение подзадач, из которых состоит выбранный план реализации запроса, между ко-серверами слабосвязанной системы. Планировщик следит, в частности, за тем, чтобы на каждом ко-сервере были локально доступны ресурсы, необходимые для выполнения его подзадачи. С учетом имеющегося плана, а также приоритета, установленного для данного запроса, планировщик определяет, будет ли запрос выполняться последовательно или параллельно.
Масштабируемость и инкрементальная производительность
Для того чтобы в полной мере использовать потенциал аппаратного параллелизма, СУБД должна обладать механизмами распараллеливания SQL-запросов и утилит. Именно технологии параллельной обработки, в первую очередь, создают предпосылки для масштабируемости систем и для сокращения времени отклика как в приложениях OLTP, так и в системах DSS [4].
Сервер OnLine XPS способен распараллеливать и распределять между узлами слабосвязанных и MPP-систем следующие утилиты и подзадачи SQL-запросов:
OnLine XPS - единственная на сегодня СУБД, обладающая средствами распараллеливания для столь обширного набора операций. Informix также является одной из немногих СУБД, в которых реализован алгоритм соединения методом хеширования, позволяющий эффективно выполнять соединения по неиндексированным столбцам.
Алгоритм соединения методом хеширования
Для приложений DSS характерны запросы, включающие соединения множественных таблиц по произвольным столбцам, которые зачастую не имеют индексов. Соединения по неиндексированным столбцам весьма трудоемки. Для их реализации во многих СУБД применяется алгоритм соединения методом сортировки и слияния, который заключается в том,что обе таблицы сначала сортируются по столбцам соединения, а затем за отдельный проход выполняется их слияние.
Алгоритм соединений методом хеширования также лрименяется для соединений по неиндексированным столбцам и во многих случаях оказывается более эффективным, поскольку не требует сортировки. На фазе хеширования, одна из таблиц (как правило, меньшая) сканируется, и для нее по столбцу соединения строится хеш-таблица. Затем последовательно просматривается, вторая таблица и для каждой ее строки производится поиск по хеш-таблице. Для каждого обнаруженного соответствия формируется результирующая строка. Если в соединении участвуют большие таблицы, то данный алгоритм оказывается значительно эффективнее, чем алгоритм методом сортировки и слияния.
Масштабируемость и фрагментация
Масштабируемость СУБД характеризуется двумя факторами, которые можно назвать линейной наращиваемостью и линейным ускорением. Линейная наращиваемость означает, что при двукратном увеличении аппаратных ресурсов СУБД будет за то же время производить вдвое больший объем обработки данных. Линейное ускорение означает, что при двукратном увеличении аппаратных ресурсов СУБД станет выполнять приложения вдвое быстрее. В идеале хотелось бы рассчитывать на линейную наращиваемость и ускоряемость при неограниченном росте числа узлов; практически же 100% масштабируемость редко достигается из-за наличия узких мест в аппаратном и программном обеспечении, а также из-за неравномерного распределения данных.
Для того чтобы исключить по возможности узкие места программного характера и перекосы в распределении данных, в OnLine XPS применяется несколько механизмов фрагментации:
Достигаемая за счет этих трех механизмов оптимизация позволяет добиться высоких показателей масштабируемости при наращивании аппаратной базы вплоть до очень больших систем.
Фрагментация данных
Техника фрагментации данных позволяет представить большую БД в виде группы более мелких баз. Фрагменты большой таблицы хранятся на множестве дисков, принадлежащих, возможно, разным узлам. Операции сканирования, соединения, сортировки и др. над фрагментированными данными могут выполняться параллельно, с участием множества процессоров и дисков.
Ключом к достижению масштабируемости в OnLine XPS является раздельное владение данными. Это означает, что фрагмент таблицы может сканировать и записывать только владеющий им ко-сервер. Хотя физически диски этого ко-сервера доступны и с других ко-серверов, однако такой доступ используется только в ситуациях аварийного переключения. Принцип раздельного владения данными позволяет минимизировать объем дорогостоящих сетевых операций ввода-вывода и значительно сократить сетевой трафик.
OnLine XPS поддерживает несколько методов фрагментации: равномерная, интервальная, по выражению, хешированная.
Равномерная фрагментация. При равномерной фрагментации строки, вставляемые в таблицу, записываются поочередно на разные дисковые фрагменты. Гарантируется равномерное распределение данных по фрагментам. Однако, в силу случайного характера распределения данных, сервер не имеет информации о том, на каком узле находится данная строка; поэтому для выполнения любой выборки из таблицы необходимо выполнять сканирование по всем узлам. Этот тип фрагментации оказывается эффективным лишь в случаях, когда запрос действительно охватывает все строки таблицы.
Интервальная фрагментация. Этот тип фрагментации подразумевает распределение данных на основе диапазонов значений ключа. Например, таблица с данными о клиентах фирмы может быть фрагментирована по первой букве фамилий: от "А" до "Г" - узел 1, диск 1, от "Д" до "Й" - узел 1, диск 2 и т. д.
Интервальная фрагментация полезна при выборках данных по значению или диапазону ключа, поскольку в этих случаях не приходится сканировать заведомо ненужные фрагменты. Например, для выборки данных о клиенте по фамилии Демьянов, достаточно считать только второй фрагмент.
Фрагментация по выражению. Фрагментация по выражению является расширением интервальной. Основой для разбиения данных является значение некоторого выражения, зависящего от значений полей. Выражение задается примерно так же, как в разделе WHERE SQL-инструкций. Пример фрагментации по выражению - разбиение таблицы с данными о клиентах по значению столбца, в котором хранится название города или региона.
Хешированная фрагментация. При хешированной фрагментации разбиение данных производится на основе значения некоторой хешфункции от ключа фрагментации. Преимущество этого типа фрагментации в том, что при правильно подобранной хеш-функции обеспечивается равномерное распределение данных по узлам; в то же время сервер располагает информацией о местоположении строк. Так, если нужно выбрать строку с заданным значением ключа, то, вычислив хеш-функцию от него, сервер определяет, на каком узле хранится строка. Затем, используя локальный индекс таблицы на данном узле, можно быстро найти нужную строку.
Хешированная фрагментация позволяет также реализовать согласованное разбиение данных двух взаимосвязанных таблиц. Например, при помощи хеширования таблица заказов может быть фрагментирована таким образом, что информация о заказе всегда хранится на том же узле, что и данные о клиенте, который сделал заказ. Тогда операция соединения этих таблиц по коду клиента или транзакция, затрагивающая эти таблицы, будет выполняться как локальная, а не как распределенная, что обходится значительно дешевле с точки зрения затрат ресурсов.
Фрагментация управления
Каждый ко-сервер OnLine-XPS имеет свой набор базовых сервисов, которые обеспечивают протоколирование, восстановление, блокирование и управление буферами. Такое распределение сервисов по ко-серверам называется фрагментацией управления.
В ряде архитектур параллельных баз данных первого поколения таких как, например Oracle7, реализована модель полного централизованного разделения, когда содержимое базы данных разделяется всеми узлами слабосвязанной инфраструктуры. Согласование доступа к общим данным со стороны множества узлов обеспечивает некий узел, выполняющий функции центрального органа управления.
Рассмотрим, как в такой архитектуре узел 2 выполняет транзакцию, реализующую изменение записи о клиенте. Сначала, для того чтобы выяснить, не заблокирован ли требуемый элемент данных другим узлом, необходимо обратиться к центральному узлу. Если блокировки нет, узел 2 напрямую осуществляет доступ к данным. Если данные заблокированы другим узлом, то придется дождаться уведомления о снятии блокировки, затем заблокировать данные и выполнить изменение. Вся процедура при такой схеме требует множества избыточных сетевых взаимодействий. Кроме того, если интенсивность обработки высока, центральный узел может стать узким местом, сдерживающим производительность всего комплекса.
В Informix-OnLine XPS каждый узел, имея собственные сервисы протоколирования, восстановления, буферизации, управления контрольными точками и управления блокировками, независимо распоряжается данными, которыми он владеет. Эта схема не предполагает наличия центрального узла, координирующего доступ к данным; в результате исключается потенциально узкое место в архитектуре сервера, сокращается число сетевых взаимодействий.
Каждый узел, владея некоторым фрагментом данных, при помощи менеджера метаданных может получить информацию о местонахождении остальных данных. Если узлу нужны внешние данные, то он посылает ко-серверу, который ими владеет, запрос на обработку. Ко-сервер выбирает требуемые данные, выполняет заказанный вид обработки и возвращает результат. Процесс отсылки запросов другим узлам называется передачей функций. Пусть, например, на узел 1 поступает пользовательский запрос на выполнение соединения двух таблиц. Менеджер метаданных узла 1 определяет, что одна таблица находится на узле 2, а другая - на узле 3. Поскольку обе таблицы невелики, то оптимизатор выбирает уже упомянутый ранее алгоритм соединения методом сортировки и слияния. Планировщик распределяет (передает) обработку узлам 2 и 3, которые должны выполнить сканирование и сортировку соответственно первой и второй таблиц. Результаты - отсортированные таблицы - поступают на узел 1, который выполняет слияние.
Некоторые конкурирующие СУБД используют для обмена данных менее эффективную модель передачи данных, называемую также передачей ввода-вывода. Схема передачи данных предполагает, что каждый узел сам читает необходимые ему данные, а не запрашивает их сканирование и обработку у других узлов. Это порождает избыточный сетевой трафик, поскольку узлу, возможно, нужна лишь часть прочитанных данных. Кроме того, требуемые данные могут быть кэшированы в памяти других узлов; в таком случае, прежде чем узел сможет считать данные, содержимое кэшей должно быть сброшено на диски, что порождает дополнительные сетевые пересылки.
Модель передачи функций, напротив, предполагает вовлечение других узлов в выполнение операций выборки и обработки данных. При этом обеспечивается фильтрация пересылаемых данных - изъятие не участвующих в запросе строк и столбцов. Следовательно, схема передачи функций обеспечивает, как правило, пересылку по сети лишь некоторого подмножества той совокупности данных, которую пришлось бы пересылать при использовании модели передачи данных. Если же требуемые данные кэшированы в памяти некоторого узла, то информация об этом доступна менеджеру запросов, и он спланирует выполнение запроса таким образом, чтобы заказ на эти данные был направлен именно этому узлу.
Фрагментация выполнения
Термином "фрагментация выполнения" обозначается разбиение запроса на несколько подзапросов и их параллельное выполнение на нескольких узлах - вертикальный параллелизм. Подзапросы затем могут быть разбиты на подзадачи, выполняемые параллельно несколькими ко-серверами - горизонтальный параллелизм [3]. Фрагментация выполнения исключительно полезна при реализации запросов, характерных для приложений DSS, где предполагаются операции сканирования, сортировки, соединения огромных объемов данных, распределенных по множеству ко-серверов.
Рассмотрим, например, следующий запрос:
SELECT state, SUM(order_item) FROM customer, order WHERE order.customer_id = customer.id GROUP BY state ORDER BY SUM(order_item)
В данном случае сначала сканируются две таблицы - таблица customer с данными о клиентах и таблица order с данными о заказах. Операция соединения (WHERE) связывает каждый заказ с клиентом, который его сделал. Затем выполняется группирование (GROUP BY) заказов по названиям штатов, откуда поступили заказы, и для каждого штата суммируется общий объем заказов. Наконец, пары значений (штат, сумма заказов) сортируются по возрастанию сумм (ORDER BY).
Почти все перечисленные операции могут выполняться с применением горизонтального параллелизма. Так, если таблица customer разбита на фрагменты, хранящиеся на разных ко-серверах, то для ее считывания инициируются несколько параллельных сканирований. Строки из таблиц customer и order могут быть разосланы на разные ко-серверы для распараллеливания операции соединения. Строки, полученные в результате соединения и сгруппированные по полю state, затем рассылаются на несколько ко-серверов для параллельно выполнения суммирований.
Для оптимизации данного запроса применимы и методы вертикального параллелизма, т. е. конвейеризация промежуточных результатов. Например, результаты сканирования таблиц могут направляься на другой ко-сервер, который будет выполнять соединение по мере поступления строк исходных таблиц. Результат соединения, в свою очередь, передается еще некоторому ко-серверу, где запускается процедура суммирования.
Для выполнения сложных запросов OnLine-XPS применяет одновременно методы и вертикального, и горизонтального параллелизма. Реализация вертикального параллелизма основана на идее инкапсуляции промежуточных результатов в рамках программных объектов, называемых итераторами. Центральное звено в реализации горизонтального параллелизма - механизм рефрагментации промежуточных результатов.
Итераторы. Инкапсуляция промежуточных результатов
Элементарные операции, из которых состоит реализация любого запроса, называются итераторами. Итератор - это программный объект, воспринимающий потоки строк от одного или двух источников, выполняющий над ними некоторый вид обработки и выдающий результирующий поток строк. Итератору безразличны источники входных данных, которыми могут служить дисковые файлы, сетевые соединения, результирующие потоки других итераторов. Иерархическая комбинация итераторов реализует одновременное выполнение на разных ко-серверах множества циклов обработки данных.
Ключевое свойство итераторов - это единообразие их внешнего поведения. Независимо от того, какова его внутренняя "кухня" обработки данных, каждый итератор открывает свои входные потоки, последовательно прочитывает их и затем закрывает. Точно так же, его выходной поток может быть открыт, считан и закрыт любым другим итератором. Перечислим различные типы итераторов, применяемые в OnLine-XPS:
SCAN - Сканирует фрагментированные и нефрагментированные таблицы и индексы.
NESTED LOOP JOIN - Реализует стандартную логику соединений методом вложенных циклов (читает строку из одной таблицы, находит все совпадения во второй таблице, читает следующую строку из первой таблицы и т. д.).
MERGE JOIN - Выполняет фазу слияния для соединения методом сортировки и слияния.
HASH JOIN - Реализует алгоритм соединения методом хеширования.
GROUP - Группирует данные (GROUP BY) и вычисляет агрегатные функции.
SORT - Сортирует данные.
MERGE - Выполняет объединения UNION и UNION ALL (для UNION используется комбинация итераторов MERGE и SORT).
REMOTE - Реализует удаленные сканирования для операторов SELECT.
Рассмотрим дерево итераторов, которое реализует запрос из приведенного выше примера. Два различных итератора SCAN осуществляют сканирование таблиц customer и order. Их результаты поступают на вход итератора HASH JOIN, выполняющего соединение. Выходной поток соединения передается итератору GROUP, который группирует строки по значению поля state и выполняет суммирование значений order_item. Наконец, итератор SORT прочитывает сгруппированные данные и сортирует их.
Благодаря единообразию и самодостаточности, итератор легко может быть продублирован на множестве ко-серверов. В результате, как будет показано далее, итераторы представшпот оптимальную базу и для реализации горизонтального параллелизма.
Рефрагменищия промежуточных результатов
Для того чтобы ускорить выполнение запроса, OnLine-XPS создает для каждой элементарной операции несколько итераторов, распределяя их между наличными ко-серверами. Координацией совместной деятельности множества однотипных итераторов, реализующих некоторую операцию, занимается итератор выделенного типа, называемого EXCHANGE. Его функция - обеспечение горизонтального параллелизма. Оптимизатор,построив базовое дерево реализации запроса, , исследует затем возможности распараллеливания каждой операции. Там, где это может принести дополнительную оптимизацию, вставляются итераторы EXCHANGE.
Задача итератора EXCHANGE - собрать выходные данные от нижележащих итераторов и инициировать множество итераторов следующего уровня. Для этого он должен рефрагментировать поступившие ему на вход данные, чтобы передать на входы итераторам верхнего уровня подлежащие обработке фрагменты. Итератор EXCHANGE поддерживает конвейеризацию данных, т. е. он передает строки наверх по мере их поступления от итераторов нижнего уровня, не дожидаясь полного завершения операций. Например, как только от итераторов SCAN будет получено достаточное количество данных, EXCHANGE рефрагментирует их и отправляет итераторам HASH JOIN.
Сканирование таблицы customer, состоящей из двух фрагментов, осуществляется параллельно двумя итераторами SCAN. Результаты сканирования поступают на вход оператору EXCHANGE, который рефрагментирует совокупность полученных строк по ключу соединения и распределяет выполнение соединения между тремя ко-серверами, на которых запущены итераторы HASH JOIN. Каждому из них на вход подается соответствующий фрагмент исходных данных.
Аналогичным образом осуществляется параллельное сканирование трех фрагментов таблицы order. Соответствующий итератор EXCHANGE рефрагментирует результаты сканирования и распределяет их между вышележащими итера торами соединения. Итера торы EXCHANGE осуществляют согласованную рефрагментацию, так чтобы строки из таблиц customer и order с одинаковыми значениями ключей направлялись на один и тот же ко-сервер, который сможет их сопоставить.
Один из возможных видов окончательной схемы - итераторы HASH JOIN отправляют свои результаты еще одному итератору EXCHANGE, который направляет их двум итераторам GROUP, выполняющим группирование и суммирование. При этом результаты соединения предварительно рефрагментируются по ключу state. Наконец, результаты группирования собираются самым верхним итератором EXCHANGE и передаются на другой ко-сервер для сортировки. Разумеется, сортировка также могла быть распределена на несколько косерверов, но, поскольку в США имеется всего 50 штатов, то распараллеливание в данном случае было сочтено неоправданным.
Число экземпляров итераторов, создаваемых для выполнения каждой операции, зависит от количества наличных ко-серверов. Так, если доступно 10 косерверов, то итератор EXCHANGE может инициировать 10 итераторов HASH JOIN чтобы ускорить процесс соединения. Если на момент начала группирования доступно 50 ко-серверов, то могло быть создано 50 итераторов GROUP, по одному на каждый штат, что значительно ускорило бы выполнение группирования. Таким образом, используя принципы вертикального и горизонтального параллелизма и создавая для выполнения сложного запроса множество итераторов, одновременно выполняющихся на разных ко-серверах, OnLine-XPS способен максимально мобилизовать вычислительный потенциал параллельных аппаратных платформ.
OnLine-XPS - среда высокой доступности данных
Кластеры и MPP-платформы, поскольку они состоят из относительно независимых узлов, обладают высоким потенциалом отказоустойчивости. OnLine-XPS в полной мере использует этот потенциал и предоставляет ряд взаимодополняющих гибких механизмов, которые в совокупности способны обеспечить требуемый уровень отказоустойчивости и высокой готовности данных для критически важных приложений баз данных:
Степень отказоустойчивости системы зависит от фактических возможностей используемой аппаратуры. Так, реализация аварийного переключения в OnLine-XPS основана на предположении, что диски являются двухпортовыми, следовательно, аппаратура должна обладать этим свойством. Предполагается, что аппаратура позволяет распознавать типы произошедших отказов (различать отказы узлов и отказы коммуникационных линий). Аппаратная архитектура должна содержать также избыточные шины сообщений для защиты от возможных сетевых сбоев.
Аварийное переключение ко-сервера
Как уже упоминалось, каждый косервер владеет некоторым набором дисков, на которых располагаются фрагменты базы данных. Диски, к правило, являются двухпортовыми, и каждый из них физически соединен еще с некоторым ко-сервером OnLine-XPS. Если в результате аппаратного или программного сбоя узел выходит из строя, его диски автоматически передаются во владение альтернативным ко-серверам, и доступность данных сохраняется. Рассмотрим, например, следующую конфигурацию. Ко-сервер 2 владеет дисками данных 3 и 4. Диск 3 подключен к альтернативному косерверу 1, а диск 4 - к ко-серверу 3.
Когда обнаруживается отказ узла, OnLine-XPS автоматически выполняет восстановление путем аварийного переключения. Диски, журнал транзакций, рабочую загрузку отказавшего узла берут на себя остальные ко-серверы.
При отказе узла одна или несколько транзакций могли остаться незавершенными. Поэтому ко-сервер, принявший журнал вышедшего из строя узла, запускает процедуру быстрого восстановления, цель которой - привести данные в состояние физической и логической целостности. Во время этой процедуры база данных сначала восстанавливается в состояние последней контрольной точки, затем выполняется "накат" всех завершенных после этого момента транзакций и откат всех незавершенных.
Зеркалирование дисковых областей
OnLine-XPS располагает встроенными средствами зеркалирования дисковых областей (журналов транзакций, наиболее ответственных фрагментов баз данных), что позволяет преодолевать последствия дисковых сбоев и обеспечивать непрерывную доступность данных. OnLine-XPS поддерживает также аппаратные средства зеркалирования, если они имеются. Преимущество его собственных программных средств в том, что они позволяют избирательно задавать множество фрагментов, подлежащих зеркалированию.
Тиражирование данных
Клиентам, которые используют аппаратные платформы без поддержки двухпортовых дисков, предлагаются две опции, позволяющие так или иначе преодолеть последствия отказов: тиражирование данных и игнорирование недоступных данных. Механизм тиражирования обеспечивает доступность данных путем поддержания копии базы (или ее фрагмента) на другом узле. При отказе основного узла клиенты переключаются на другой, продолжая работать с копией данных.
Игнорирование недоступных данных
Во многих ситуациях при выходе из строя отдельных узлов или дисков вполне допустимой может быть неполная обработка данных,что предпочтительнее, чем полный отказ в обслуживании. Опция игнорирования позволяет обходить при обработке запросов фрагменты базы данных, если они в данный момент недоступны. Например, для запроса о распределении объемов продаж некоторого продукта по регионам может быть получен результат, в котором отсутствуют данные об объеме продаж в одном из регионов, если соответствующий диск отказал.
Администрирование баз данных в оперативном режиме
Существенный фактор обеспечения непрерывной доступности данных - возможность выполнять основные административные действия без останова сервера. OnLine-XPS позволяет в оперативном многопользовательском режиме выполнять такие процедуры, как рефрагментация таблиц, добавление и уничтожение столбцов, создание и уничтожение индексов, сохранениеи восстановление данных, замена диска, изменение конфигурации узла.
Интегральные средства управления
Программное обеспечение OnLine XPS тесно интегрировано с развитой средой системного управления Tivoli Management Environment (ТМЕ), разработанной компанией Tivili Systems Inc. Среда управления OnLine XPS скрывает от администраторов внутреннюю сложность аппаратных конфигураций кластерных архитектур и систем МРР, предоставляя единую точку обзора объектов баз данных, независимо от их физического местоположения.
Управление базами данных существенно упрощается благодаря наглядному графическому пользовательскому интерфейсу систем администрирования. Администратор работает при помощи мыши с графическим представлением объектов баз данных, легко может получить информацию о статусе каждого из них. Благодаря интеграции со средой сообщений и планировщиком ТМЕ, OnLine XPS предоставляет единую точку планирования и обработки событий в базах данных, а также рассылки сообщений, относящихся к состоянию баз данных.
В рамках ТМЕ сервер OnLine XPS поддерживает комплект развитых приложений, охватывающих все аспекты деятельности, связанной с администрированием баз данных:
Управление, конфигурирование, статус
Утилита управления, конфигурирования, слежения за состоянием (control, configuration, status - CCS) позволяет администратором осуществлять централизованное управление множеством серверов баз данных и приложений. CCS способна сканировать сетевую среду, собирая информацию о дисковых пространствах, таблицах и других объектах, относящихся к базам данных. Результат отображается в виде глобальной карты, на которой в графическом виде представлены реляционные объекты системы. Пользователи.и администраторы могут получить информацию о физическом местонахождении и сетевых координатах того или иного сервера, а также о расположении баз данных.
CCS предоставляет администраторам гибкие средства для определения набора отслеживаемых событий, задавать пороговые значения параметров. Примеры параметров, представляющих интерес с точки зрения работоспособности и производительности - процент попаданий в буфер для операций ввода-вывода, степень заполнения журнала транзакций, число транзакций в секунду, число активных блокировок по некоторой таблице. Если достигнуто пороговое значение параметра, то CCS отправит администраторам сообщение по факсу, электронной почте, пейджерной связи или по любому другому специфицированному каналу. Таким образом, постоянное присутствие оператора у пульта управления необязательно, а сообщение о возможном возникновении проблем будет передано администратору прежде, чем ситуация примет критический оборот.
Резервирование журналов, архивирование, восстановление
Утилита резервирования, архивирования и восстановления, которая обеспечивает сохранение и восстановление данных на серверах OnLine XPS, совместима с широким спектром продуктов управления памятью, предлагаемых независимыми поставщиками. Принципиальная совместимость с любыми аппаратными средствами управления памятью достигается за счет поддержки стандартного интерфейса X/Open Backup Services API (BSA).
Предусмотрены как предопределенные упрощенные схемы сохранения данных, так и средства для планирования операций сохранения.
Мониторинг характеристик производительности
Монитор производительности - графический инструмент, который полезен при настройке серверов и тестировании производительности. Монитор собирает данные о характеристиках производительности и отображает их на дисплее в виде линейных, круговых или столбчатых диаграмм. Данные могут отображаться в реальном времени или сохраняться для последующего графического воспроизведения, что весьма полезно при анализе тенденций.
Монитор производительности OnLine XPS способен собирать и отображать также статистическую информацию, относящуюся к клиентским приложениям или к функционированию сети. Собранные данные доступны другим утилитам администрирования, таким как утилита экспертной поддержки физической организации данных.
Администратор имеет возможность задать набор характеристик, отслеживаемых монитором. Например, он может выбрать для наблюдения характеристики использования CPU и дискового пространства, число работающих пользователей. Таким образом, отображается и сохраняется в достаточном объеме лишь та информация, которая представляет интерес на данном этапе.
Анализ, экспертная помощь в физическом конфигурировании данных
Оптимальность функционирования СУБД существенно зависит от двух факторов - физической организации баз данных и объемов выделенных системных ресурсов. Утилита экспертной поддержки физической организации данных призвана помочь административному персона в принятии соответствующих решений. Она воспринимает и анализирует исходную информацию из множества источников (например, информацию, собранную монитором производительности, описание логической схемы базы данных, описание аппаратных ресурсов, сведения из базы экспертных административных данных) и преобразует ее в информацию, которую администратор может использовать для принятия решений, касающихся фрагментации таблиц, схем индексации, аппаратного конфигурирования.
Параллельная загрузка баз данных
Утилиты параллельной загрузки/выгрузки баз данных позволяет выполнять эти процедуры с максимальной скоростью за счет распараллеливания операций обмена с внешними носителями и использования всех доступных системных ресурсов.
Утилиты поддерживают также параллельное преобразование данных, поступивших из других источников. Поддерживается параллельная загрузка/выгрузка фрагментированных таблиц, а также извлечение и вставки данных на уровне буферов, а не на уровне записей. Для управления утилитами предоставляется графический интерфейс. Он позволяет задать отображение полей загружаемого файла на столбцы целевой таблицы, указать нужный тип преобразования данных, просмотреть исходный файл и произвести фильтрацию его строк.
Для ускорения процесса загрузки предусмотрен режим, в котором отменяются проверки целостности по ссылкам, протоколирование и возбуждение триггеров, а также предварительно уничтожаются индексы таблиц.
Управление тиражированием для распределенных баз данных
Утилита тиражирования данных позволяет отображать на мониторе и управлять конфигурациями тиражирования данных в сети. Доступны две опции - тиражирование для обеспечения высокой готовности и непрерывное тиражирование. Утилита позволяет в графическом режиме выбрать исходный и целевой сервер тиражирования, задать режим доступа к тиражированным данным (только чтение или чтение/запись), указать частоту операций.
Утилита служит также инструментом наблюдения за состоянием сетевой среды. Конфигурация сети отображается на консоли, и компоненты, на которых возникают те или иные проблемы, выделяются цветом.
Управление реляционными объектами
Утилита управления реляционными объектами служит для упрощения процедуры создания баз данных. Она предоставляет собой графический интерфейс, который позволяет легко создать новую таблицу, указать имена, типы и свойства ее столбцов,построить индексы, задать привилегии пользователей. Утилита содержит также средства для создания представлений, хранимых процедур, триггеров.
Заключение
В статье представлен обзор архитектурных решений и основных возможностей новой модели сервера Informix-OnLine XPS. Первоначальные версии продукта ориентированы, прежде всего, на создание крупных хранилищ данных со средствами обработки образов документов, мультимедийными возможностями, сложным контекстным поиском информации и других прикладных сред, основанных на так называемых очень больших базах данных (VLDB). Существенно, что Informix предлагает своим клиентам путь плавного перехода - без существенного перепрограммирования приложений - к использованию OnLine XPS по мере того как их потребности в объемах переработки данных и уровне готовности перерастают возможности однопроцессорных систем и систем SMP.
АО "Инфосистемы Джет" niva@jet.msk.su
Литература
[1] Informix-OnLine Extended Parallel Server for loosely Coupled Cluster and Massively Parnllel Processing Architectures. lnformix Software, Inc., 1995.
[2] Н. Вьюкова. Архитектура сервера lNFORMlX-OnLine Dynamic Server 7.1 и коммуникационные средства. Jet Info, Вып. 2, 1995.
[3] Г. Г. Барон. Параллельные архитектуры серверов баз данных. Jet Info, Вып. 1.
[4] Д. Дэвитт, Д. Грей. Параллельные системы баз данных: будущее высокоэффектпивных баз данных. СУБД, вып. 2, 1995.
