Серверные продукты компании Informix

Н.Вьюкова

СУБД INFORMIX, первая версия которой вышла в 1980 г., традиционно использовалась для создания информационных систем малого или среднего масштаба, работающих в режиме оперативной обработки транзакций. Однако, начиная с версии 6.0, сервер Informix, получивший название Informix-Online Dynamic Server (Informix ODS), прибрел такие черты, которые позволили с успехом применять эту СУБД для реализации крупных проектов.
Многопотоковая архитектура сервера послужила базой для реализации технологии параллельной обработки запросов, которая включена в версию 7. Эта технология обеспечивает эффективное выполнение сложных запросов, характерных для систем поддержки принятия решений (Decision Support Systems - DSS).
Архитектурные и технологические решения, положенные в основу Informix-ODS, нашли дальнейшее развитие в последнем серверном продукте компании - Informix-Online EXtended Parallel Server (Informix-ОXPS), который предназначен для кластерных и массово-параллельных платформ и предоставляет повышенный уровень производительности и отказоустойчивости.
В докладе дается обзор архитектурных принципов и механизмов, которые определили новое качество последних моделей серверов Informix. Основные направления развития этих продуктов связаны с важнейшими требованиями, предъявляемыми к СУБД, которая претендует на роль информационной основы современного предприятия [1]:

высокая производительность
масштабируемость
смешанная загрузка сервера разными типами задач
непрерывная доступность данных

1. Сервер Informix-Online Dynamic Server

1.1. Динамическая масштабируемая архитектура

Архитектура сервера Informix-ODS получила название "динамическая масштабируемая архитектура" (DSA). Суть ее заключается в том, что одновременно выполняется относительно небольшое число серверных процессов (виртуальных процессоров, ВП), которые разделяют между собой работу по обслуживанию множества клиентов. По сравнению с более ранними моделями сервера INFORMIX, где для каждого клиента создавался индивидуальный серверный процесс, новая модель обладает рядом преимуществ:

снижение нагрузки на операционную систему (число серверных процессов невелико);
сокращение совокупной потребности клиентов в оперативной памяти;
снижение конкуренции при одновременном использовании системных ресурсов;
более рациональное по сравнению с ОС назначение приоритетов и планирование;

для многопроцессорных платформ:

равномерная загрузка наличных процессоров;
ускорение обработки сложных запросов за счет параллельного выполнения на нескольких процессорах.

Архитектуру Informix-ODS называют также многопотоковой. Для каждого клиента создается один или несколько потоков, т.е. подзадач, выполняемых в рамках одного из ВП. Потоки создаются также для выполнения внутренних задач сервера - ввода-вывода, журнализации, администрирования и др.
ВП - это процесс сервера баз данных, управляющий выполнением потоков. ВП можно сравнить с операционной системой - поток по отношению к нему выступает как процесс, подобно тому как сам ВП является процессом с точки зрения операционной системы.
ВП выбирают готовые к выполнению потоки из общей очереди, поэтому ни один из них не простаивает, если есть какая-либо работа по обработке запросов или управлению. Таким образом, обеспечивается сбалансированная загрузка доступных процессоров. Существенная экономия процессорного времени достигается за счет того, что переключение ВП с потока на поток выполняется значительно быстрее, чем переключение ОС с процесса на процесс.

1.2. Разделяемая память

Разделяемая память - это механизм операционной системы, на котором основано разделение данных между виртуальными процессорами и потоками сервера. Разделение данных позволяет:

Снизить общее потребление памяти, поскольку участвующим в разделении процессам, т. е. ВП, нет нужды поддерживать свои копии информации, находящейся в разделяемой памяти.
Сократить число обменов с дисками, потому что буферы ввода-вывода сбрасываются на диск не для каждого процесса в отдельности, а образуют один общий для всего сервера баз данных пул. ВП зачастую избегает выполнения операций ввода с диска, поскольку нужная таблица уже прочитана другим ВП.
Организовать быстрое взаимодействие между процессами. Через разделяемую память, в частности, обмениваются данными потоки, участвующие в параллельной обработке сложного запроса. Разделяемая память используется также для организации взаимодействия между локальным клиентом и сервером.

Управление разделяемой памятью реализовано таким образом, что ее фрагментация минимизируется, поэтому производительность сервера при ее использовании не деградирует с течением времени.
В разделяемой памяти находится информация обо всех выполняемых потоках, поэтому потоки относительно быстро переключаются между ВП.
Совокупное использование памяти оптимизируется за счет поддержки кэшей хранимых процедур и словарей данных, разделяемых между всеми ВП. При загрузке в разделяемую память словарь данных записывается в структуры, обеспечивающие быстрый доступ к информации, а хранимые процедуры преобразуются в выполняемый формат, что существенно ускоряет выполнение приложений, обращающихся ко многим таблицам с большим числом столбцов и/или ко многим хранимым процедурам.

1.3. Оптимизация дисковых операций

Операции ввода-вывода, как правило, образуют наиболее медленную компоненту обработки баз данных. Поэтому от их реализации существенно зависит общая продуктивность
сервера. Для В сервере Informix-ODS применяются следующие механизмы, которые способствуют оптимизации ввода-вывода и повышению надежности:

Собственное управление дисковой памятью;
Асинхронный ввод-вывод;
Опережающее чтение.

2. Сервер Informix-Online EXtended Parallel Server

Системы с массовым параллелизмом (MPP) и слабосвязанные (кластерные) системы, для которых предназначена модель сервера Informix-OXPS, обладают двумя важнейшими преимуществами - высоким потенциалом отказоустойчивости и широкими возможностями наращивания производительности.
MPP и слабосвязанные системы, называемые часто архитектурами без разделяемых ресурсов, представляют собой быстрые сети, связывающие однопроцессорные или симметричные многопроцессорные системы - узлы. Если база данных поделена между множеством узлов, то отказ одного из них приведет лишь к недоступности относящихся к нему данных. Остальные данные будут по-прежнему доступны пользователям. Если же в конфигурации предусмотрено аварийное переключение узлов, то доступ к данным отказавшего узла будет автоматически восстановлен.
Для приложений DSS, имеющих сложный аналитический характер и предполагающих обработку очень больших массивов данных, критичной может оказаться способность платформы к наращиванию мощности параллельных вычислений. Число процессоров, которые реально способны поддерживать сегодняшние системы SMP, ограничено пропускной способностью системной шины; их практическая масштабируемость обеспечивается лишь с ростом количества процессоров до 32.
Преимущества аппаратных платформ без разделяемых ресурсов - это лишь предпосылки к созданию высокопроизводительной и устойчивой к отказам среды баз данных. В последующих разделах мы покажем, как эти предпосылки реализуются в архитектурных и технологических решениях сервера Informix-OXPS.
Informix-OXPS доступен в настоящее время для платформ IBM SP2, ICL Goldrush, AT&T 5100; планируются реализации для платформ Pyramid/SNI Reliant RM1000, а также кластерных платформ Sun Microsystems Inc., Hewlett-Packard Co., Sequent Computer Systems Inc., Silicon Graphics Inc., Intel. Предполагается, что в перспективе будет обеспечена поддержка всех платформ этих типов, работающих под управлением ОС UNIX.

2.1. Фрагментация управления. Неразделение данных

Подобно аппаратным платформам, для которых он предназначен, Informix OXPS построен на принципах относительной независимости узлов и неразделения ресурсов. Независимость узлов выражается в том, что каждый из них выполняет свой экземпляр программного обеспечения СУБД, которое включает сервисы протоколирования, восстановления, управления блокировками и управления буферами. Узел, на котором выполняются эти сервисы, называется ко-сервером.
На каждом ко-сервере выполняются также компоненты, отвечающие за разбиение запроса на подзадачи и их распределение между ко-серверами:

Менеджер запросов (МЗ) отвечает за реализацию запросов с разбиением их на подзадачи, распределяемые между узлами с соблюдением баланса загрузки.
Оптимизатор запросов определяет наилучший план выполнения запроса, основываясь на оценках стоимости необходимых ресурсов.
Менеджер метаданных (ММД). Метаданные - это информация о распределении данных по узлам. Метаданные каждой БД, как правило, сосредоточены на одном узле. ММД ко-серверов, взаимодействуя между собой, обеспечивают каждому узлу доступность метаданных всех БД данного сервера.
Планировщик распределяет выполнение подзадач, из которых состоит выбранный план реализации запроса, между ко-серверами слабосвязанной системы. Он следит, в частности, за тем, чтобы на каждом ко-сервере были локально доступны ресурсы, необходимые для выполнения его подзадачи.

Для каждого запроса МЗ одного из узлов (того, на который поступил запрос) выступает в роли координатора. При обработке запроса компоненты взаимодействуют друг с другом: МЗ обращается к оптимизатору для выработки оптимального плана, оптимизатор обращается к ММД за информацией о местонахождении данных, готовый план передается планировщику и т. д.
Каждый узел, имея собственные сервисы протоколирования, восстановления, буферизации, управления контрольными точками и управления блокировками, полностью распоряжается данными, которыми он владеет. Если другим узлам требуются его данные, то они присылают соответствующие запросы на их получение.
В целях оптимизации на всех узлах может быть кэширован системный каталог, содержащий информацию о распределении данных по узлам. Из тех же соображений небольшие часто используемые таблицы также, вероятно, будут тиражированы на все узлы.
Архитектура Informix-OXPS, основанная на принципах децентрализованного, фрагментированного управления и раздельного владения данными, лишена ряда недостатков, присущих противоположному подходу, когда базы данных разделяются всеми узлами. В таком случае необходим выделенный центральный узел, который координирует совместный доступ "рабочих" узлов к содержимому баз данных.

2.2. Принцип передачи функций

Каждый узел, владея некоторым фрагментом данных, при помощи менеджера метаданных может получить информацию о местонахождении остальных данных. Если узлу нужны внешние данные, то он посылает ко-серверу, который ими владеет, запрос на обработку. Ко-сервер, получивший запрос, выбирает требуемые данные, выполняет заказанный вид обработки и возвращает результат заказчику. Процесс отсылки запросов другим узлам называется передачей функций.
Некоторые конкурирующие СУБД используют для обменов менее эффективную модель передачи данных, называемой также передачей ввода-вывода. Схема передачи данных предполагает, что каждый узел сам прочитывает необходимые ему данные, а не запрашивает их сканирование и обработку у других узлов. Это порождает избыточный сетевой трафик, поскольку узлу, возможно, нужна лишь часть прочитанных данных.

3. Технологии параллельной обработки

3.1. Масштабируемость и фрагментация

Масштабируемость СУБД характеризуется двумя факторами, которые можно назвать линейным наращиванием и линейным ускорением. Линейное наращивание означает, что при двукратном увеличении аппаратных ресурсов СУБД будет за то же время производить вдвое больший объем обработки данных. Линейное ускорение означает, что при двукратном увеличении аппаратных ресурсов СУБД станет выполнять приложения вдвое быстрее. В идеале хотелось бы рассчитывать на линейную наращиваемость и ускоряемость при неограниченном росте числа ресурсов.
Для того чтобы исключить по возможности узкие места программного характера и перекосы в распределении данных, в серверах Informix применяются механизмы фрагментации данных и фрагментации выполнения. В Informix-OXPS этой же цели служит принцип фрагментации управления, а в Informix-ODS - многопотоковая архитектура.

3.2. Фрагментация данных

Серверы Informix поддерживают горизонтальную фрагментацию таблиц. Это такой способ хранения таблицы, когда совокупность ее строк разбивается на несколько групп согласно некоторому правилу, и эти группы хранятся на разных дисковых разделах. В Informix-OXPS фрагменты таблицы могут распределяться между дисками разных узлов.

Благодаря фрагментации:

Сокращается время обработки одного запроса, поскольку для сканирования таблицы создается несколько параллельных потоков. Если стратегия фрагментации выбрана удачно, то ускорение при выборке из таблицы практически линейно зависит от числа фрагментов.
Снижается уровень конкуренции при одновременном обращении нескольких запросов к одной таблице, поскольку для каждого из них читается только тот дисковый фрагмент, к которому относится данный запрос.
Повышается готовность (доступность) приложений. Даже если некоторые фрагменты таблицы недоступны из-за того, что соответствующие диски вышли из строя, запросы к ней во многих случаях могут выполняться.
Улучшаются характеристики административных операций, таких как архивирование-восстановление, загрузка-выгрузка данных, поскольку они применимы к отдельным фрагментам таблиц.

3.3. Фрагментация выполнения

Термином "фрагментация выполнения" обозначается разбиение запроса на несколько подзапросов и их параллельное выполнение (т. е. вертикальный параллелизм); подзапросы затем могут быть разбиты на подзадачи, выполняемые параллельно (горизонтальный параллелизм, рис. 1).

t
	write
	sort
	merge
	scan
		a	b	c

Рис.1. Сокращение времени обработки за счет применения вертикального и горизонтального параллелизма.

Методы фрагментации выполнения применяется в обеих моделях серверов, с той разницей, что Informix-ODS для выполнения подзапросов и подзадач создает потоки, выполняемые параллельно на нескольких процессорах, а в Informix-OXPS выполнение подзапросов и подзадач распределяется между ко-серверами. Фрагментация выполнения дает многократный выигрыш в производительности на следующих типах задач:

обработка характерных для приложений DSS сложных запросов, которые включают сканирование, сортировку, соединения огромных объемов данных, распределенных по множеству дисков и/или ко-серверов, группирование, вычисление агрегатных функций;
массовые вставки;
построение индексов;
резервирование журналов транзакций, сохранение и восстановление данных;
загрузка, выгрузка данных, реорганизация баз данных;

Informix - единственная на сегодня СУБД, которая обладает средствами распараллеливания для столь обширного набора операций.

3.3.1. Вертикальный параллелизм. Итераторы Элементарные операции, из которых состоит реализация любого запроса, называются итераторами. Итератор - это программный объект, который воспринимает потоки строк от одного или двух источников, выполняет над ними некоторый вид обработки и выдает результирующий поток строк. Источниками данных могут служить дисковые файлы, сетевые соединения, результирующие потоки других итераторов. Основное свойство итераторов - единообразие их внешнего интерфейса, благодаря которому они могут произвольным образом объединяться.
Рассмотрим пример выполнения запроса:

SELECT state, SUM(order_item)

FROM customer, order

WHERE order.customer_id = customer.id

GROUP BY state

ORDER BY SUM(order_item)
Дерево его реализации (рис. 2) включает следующие типы итераторов:

SCAN - Сканирует таблицы и индексы.

HASH JOIN - Реализует алгоритм соединения методом хеширования.

GROUP - Группирует данные (GROUP BY) и вычисляет агрегатные функции.

SORT - Сортирует данные.
Дерево итераторов на рис. 2 реализует одновременное выполнение на разных процессорах или ко- серверах множества циклов обработки данных за счет конвейеризации промежуточных результатов. Так, результаты сканирования таблиц могут передаваться другому ко-серверу (в OXPS) или другому потоку (в ODS), который сможет начать соединение по мере поступления строк исходных таблиц. Результат соединения передается еще одному ко-серверу или потоку, который начнет выполнять суммирование, и т. д.

3.3.2. Горизонтальный параллелизм. Рефрагментация промежуточных результатов Для того чтобы ускорить выполнение запроса, для каждой элементарной операции создается несколько итераторов, которые распределяются между ко-серверами (OXPS) или выполняются как отдельные потоки (ODS). Координацией совместной деятельности множества однотипных итераторов занимается итератор типа EXCHANGE. EXCAHGE рефрагментирует результаты, полученные от нижележащих итераторов и передает их итераторам верхнего уровня (рис. 3).

3.3.3. Баланс между приложениями OLTP и DSS Задачи, выполняемые на сервере СУБД, можно разделить на три категории: OLTP, DSS и пакетной обработки.
Пример OLTP-запроса: Есть ли свободный номер в какой-либо берлинской гостинице на 8-е декабря?
Пример DSS-запроса: Каковы будут затраты на реализацию стратегии X охраны здоровья сотрудников по сравнению со стратегией Y с учетом демографического профиля компании?

Рис 2. Дерево реализации запроса состоит из итераторов. Каждый итератор производит заданный вид обработки по мере поступления входных данных, не дожидаясь завершения итераторов нижнего уровня.

Примеры заданий пакетной обработки - массовая загрузка данных, выдача сложных отчетов, действия по реорганизации базы данных.
Архитектурные и технологические решения, о которых говорилось выше, направлены на то, чтобы обеспечить эффективную обработку всех типов заданий. Однако не менее важная проблема - обеспечить рациональное одновременное выполнение смеси таких задач на сервере. Если применение методов фрагментации выполнения ничем не ограничено, то сильно распараллеленное выполнение нескольких сложных запросов приведет к недопустимому замедлению OLTP- приложений, выполняющихся на том же сервере.
Для решения этой проблемы предусмотрены механизмы регулирования, которые позволяют динамически управлять степенью распараллеливания запросов и долей системных ресурсов, выделяемых для параллельной обработки сложных запросов. В часы наиболее активной работы приложений OLTP запросы DSS могут выполняться с невысокой степенью распараллеливания. В остальное время, или на серверах, где приложения OLTP отсутствуют, устанавливается максимальная степень использования параллельной обработки.

4. Сервер Informix - среда высокой доступности данных

Серверные продукты Informix содержат целый спектр средств для поддержания доступности данных. Сочетание этих средств позволяет обеспечить разные уровни надежности и отказоустойчивости в зависимости от потребностей приложений и от наличных аппаратных ресурсов.

Рис.3. Один из вариантов применения горизонтального параллелизма для дерева итераторов рис.2

4.1. Аварийное переключение ко-серверов Informix- OXPS

Каждый ко-сервер владеет некоторым набором дисков, на которых располагаются фрагменты базы данных. Диски, как правило, являются двухпортовыми, и каждый из них физически соединен еще с некоторым ко-сервером Informix-OXPS. Если в результате аппаратного или программного сбоя узел выходит из строя, его диски автоматически передаются во владение альтернативным ко- серверам, и доступность данных сохраняется. Диски, журнал транзакций, рабочую загрузку отказавшего узла берут на себя остальные ко-серверы.
При отказе узла одна или несколько транзакций могли остаться незавершенными. Поэтому ко- сервер, принявший журнал вышедшего из строя узла, запускает процедуру быстрого восстановления, цель которой - привести данные в состояние физической и логической целостности.

4.2. Зеркалирование дисковых областей

Обе модели серверов Informix располагают встроенными средствами зеркалирования дисковых областей, что позволяет преодолевать последствия дисковых сбоев и обеспечивать непрерывную доступность данных. Поддерживаются также аппаратные средства зеркалирования, если они имеются. Преимущество собственных программных средств Informix в том, что они позволяют избирательно задавать зеркалирование множества фрагментов, наиболее критичных для работоспособности прикладной среды.

4.3. Тиражирование данных

Механизм тиражирования Informix-ODS позволяет поддерживать копию первичного сервера на вторичном сервере, который в обычном режиме доступен только на чтение и может, например, использоваться для выполнения приложений DSS. При отказе первичного сервера вторичный переключается в режим чтения-записи, и все клиенты переключаются на него.
Informix-OXPS обеспечивает тиражирование на уровне узлов: копия узла, содержащего базу (или ее фрагмента), поддерживается на другом узле. При отказе основного узла клиенты переключаются на дублирующий, продолжая работать с копией данных.

4.4. Игнорирование недоступных данных

Во многих ситуациях при выходе из строя отдельных узлов или дисков вполне допустимой может быть неполная обработка данных, что предпочтительнее, чем полный отказ в обслуживании. Опция игнорирования позволяет обходить при обработке запросов фрагменты базы данных, если они в данный момент недоступны.

4.5. Администрирование баз данных в оперативном режиме

Существенный фактор обеспечения непрерывной доступности данных - возможность выполнять основные административные действия без останова сервера. Серверы Informix позволяют в оперативном многопользовательском режиме выполнять такие процедуры, как изменение параметров конфигурирования, рефрагментация таблиц, добавление и уничтожение столбцов, создание и уничтожение индексов, сохранение и восстановление данных, замена диска, изменение конфигурации узла OXPS.

5. Интегральные средства управления

Программное обеспечение Informix-OXPS тесно интегрировано с развитой средой системного управления Tivoli Management Environment (TME), разработанной компанией Tivoli Systems Inc. (Начиная с версии 8 аналогичные средства системного управления будут реализованы и для Informix ODS.) Среда управления скрывает от администраторов внутреннюю сложность аппаратных конфигураций кластерных архитектур и систем MPP, предоставляя единую точку обзора объектов баз данных, независимо от их физического местоположения.
Управление базами данных существенно упрощается благодаря наглядному графическому пользовательскому интерфейсу систем администрирования. Администратор работает с графическим представлением объектов баз данных и легко может получить информацию о статусе каждого из них. За счет интеграции со средой сообщений и планировщиком TME, предоставляется единая точка планирования и обработки событий в базах данных, а также рассылки сообщений, относящихся к состоянию баз данных.
В рамках TME поддерживается комплект развитых приложений, охватывающих все аспекты деятельности, связанной с администрированием баз данных:

Управление, конфигурирование, слежение за текущим состоянием;
Резервирование журналов транзакций, архивирование, восстановление;
Мониторинг характеристик производительности;
Анализ, экспертная помощь в физическом конфигурировании данных;
Параллельная загрузка баз данных;
Управление тиражированием для распределенных баз данных;
Управление реляционными объектами.

6. Заключение

В статье представлен обзор архитектурных решений и основных возможностей двух моделей серверов СУБД Informix. Сервер Informix-ODS - рыночный продукт, широко применяемый для реализации проектов самого разного характера. Сервер Informix-OXPS доступен пока для ограниченного спектра платформ и не получил еще широкого распространения. Первоначальные версии этого продукта ориентированы, прежде всего, на создание крупных хранилищ данных со средствами обработки образов документов и мультимедийными возможностями.
Разумеется, в небольшом докладе невозможно дать полный и глубокий анализ двух столь сложных программных продуктов, каковыми являются серверы СУБД Informix-ODS и Informix-XPS. Заинтересованный читатель найдет развернутую информацию об архитектуре и возможностях серверных продуктов Informix в работах [3,4].

Литература

Г. Барон. Параллельные архитектуры серверов баз данных. Jet Info, Вып. 1, 1995.

Н. Вьюкова. Архитектура сервера INFORMIX-OnLine Dynamic Server 7.1 и коммуникационные средства. Jet Info, Вып. 2, 1995.

Н. Вьюкова. Сервер для кластерных и массово-параллельных архитектур. Открытые системы, N 4, 1995.

[Назад] [Содержание] [Вперед]