Параллельные архитектуры серверов баз данных

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

Одним из основных факторов развития является смещение информационных услуг в сторону обслуживания все более сложных запросов в реальном времени. Потребителям все труднее мириться с ограничениями существующих технологий, требующих искусственно разделять задачи массового ввода и модификации данных (OLTP), задачи анализа (DSS) и пакетную обработку (batch processing). Попытки совместить эти задачи в рамках одной вычислительной системы пока требуют огромных усилий по сопровождению системы. Смешанная загрузка определяется как оперативная обработка сложных транзакций (OLCP) и становится неотъемлемым качеством современных информационных систем.

Быстрое продвижение наблюдается и в области аппаратных решений. Все более мощные вычислительные платформы становятся доступны по первому требованию при одновременном снижении стоимости аппаратных компонентов. Увеличилась пропускная способность сетей, продолжает снижаться стоимость оперативной памяти, постоянно растет емкость дисковых накопителей и скорость доступа к дисковым массивам. Однако наиболее важным изменением в компьютерных архитектурах можно считать использование нескольких процессоров для кардинального увеличения вычислительной мощности. Фактически определились три архитектурных направления (рис.1):

Симметричные многопроцессорные системы (SMP) - наиболее часто используемая форма сильносвязанных многопроцессорных систем, т.е. систем, разделяющих единую оперативную память и наиболее часто - дисковую подсистему;
Слабосвязанные многопроцессорные системы - совокупность самостоятельных компьютеров, объединенных в единую систему быстродействующей сетью и, возможно, имеющих общую дисковую подсистему, как, например, кластерные инсталляции;
Системы с массовым параллелизмом (MPP) - системы с сотнями и даже тысячами процессоров, детали их реализации могут значительно различаться. (Рис. 1.)

Рисунок 1.

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

Для серверов баз данных самой актуальной становится проблема соответствия современным запросам пользователей и нетривиальным параллельным архитектурам вычислительных платформ. Основной вопрос данной статьи - каким новым требованиям должны удовлетворять архитектура и функциональные возможности сервера баз данных в окружении параллельных аппаратных решений и орентированных на параллелизм операционных систем. Для упрощения рассматривается реализация параллелизма на примере SMP-платформы - наиболее вероятной на сегодня основы для построения крупного проекта. Автор намеренно не упоминает названия и точных возможностей лидирующих на рынке продуктов - тема параллелизма настолько важна в производственной программе производителей Informix, Oracle и Sybase, что очень скоро возможности ведущих РСУБД в этой области будут отличаться лишь незначительными деталями, как например, сейчас они имеют разные диалекты одного языка SQL.

Можно выделить четыре группы требований, определяющих с технической точки зрения потребительские качества современной СУБД:

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

В дальнейшем мы рассмотрим эти параметры подробнее.

Масштабируемость системы

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

Рисунок 2.

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

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

поддержка многопроцессорной обработки;
гибкость архитектуры.

Многопроцессорные системы

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

Качественная поддержка многопроцессорной обработки требует от сервера баз данных способности самостоятельно планировать выполнение множества обслуживаемых запросов, что обеспечило бы наиболее полное разделение доступных вычислительных ресурсов между задачами сервера. Запросы могут обрабатываться последовательно несколькими задачами или разделяться на подзадачи, которые в свою очередь могут быть выполнены параллельно (рис.3). Последнее более оптимально, поскольку правильная реализация этого механизма обеспечивает выгоды, независимые от типов запросов и приложений. На эффективность обработки огромное воздействие оказывает уровень гранулярности рассматриваемых задач. Если гранулярность очень велика, например, на уровне отдельных SQL-запросов, то разделение ресурсов вычислительной системы (процессоров, памяти, дисков) не будет оптимальным - задача будет простаивать, ожидая окончания необходимых для завершения SQL- запросов операций ввода/вывода, хотя бы в очереди к ней стояли другие запросы, требующие значительной вычислительной работы. При более низкой гранулярности разделение ресурсов происходит даже внутри одного SQL-запроса, что еще нагляднее проявляется при параллельной обработке нескольких запросов. Применение планировщика обеспечивает привлечение больших ресурсов системы на решение собственно задач обслуживания базы данных и сводит к минимуму простои.

Рисунок 3.

Гибкость архитектуры

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

Производительность СУБД

Среди многих факторов, влияющих на производительность СУБД, выберем два, имеющие прямое отношение к нынешним параллельным вычислительным платформам:

поддержка параллелизма
реализация многопотоковой архитектуры

Параллельные алгоритмы

Одним из способов достижения более высокой производительности является использование алгоритмов распараллеливания заданий. В СУБД существует три области применения таких алгоритмов:

параллельный ввод/вывод;
параллельные средства и утилиты администрирования;
параллельная обработка запросов к базе данных.

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

Рисунок 4.
Параллельные операции ввода/вывода

В отличие от параллельных ввода/вывода и администрирования параллелизм в обработке запросов реализуется гораздо сложнее. Теоретическим обоснованием возможности распараллеливания запросов в реляционной СУБД являются свойство реляционного замыкания - результатом каждого реляционного оператора: SELECT - выборка подмножества строк отношения (таблицы); PROJECT - выборка подмножества полей (столбцов); JOIN - соединение двух таблиц, является новое отношение, а, поскольку любой запрос можно разбить на иерархию элементарных операторов, то разумно попытаться выполнить их параллельно. По сути язык запросов SQL параллельный. Обработка запроса обычно состоит из множества атомарных операций, состав и последовательность которых, т.е. план запроса (рис.5), определяется оптимизатором после просмотра нескольких вариантов. В недалеком прошлом все эти операции выполнялись в строгой последовательности, результат каждой служил исходным набором данных для последующей. Параллелизм в обработке запросов подобен идее "разделяй и властвуй" или коллективному выполнению задания. Из-за того, что задание разделено на части между несколькими работниками, результат достигается быстрее. Для обеспечения параллелизма в сервере баз данных производитель должен выбрать такой набор атомарных операций, например scan - просмотр таблицы, sort - сортировка, join - соединение двух таблиц, который (а) мог бы тиражироваться и выполнять свою часть задачи одновременно, и (б) результаты их работы можно было бы объединить, как если бы задача была выполнена одним исполнителем.

Рисунок 5.
План выполнения SQL-запроса.

Достижение этой цели требует, чтобы декомпозиция и параллельное выполнение запроса были осуществимы независимо от средств межзадачного взаимодействия, принятых в конкретной вычислительной системе. Создание множества тиражируемых копий одной атомарной операции, одновременно выполняющих одну и ту же задачу, можно назвать горизонтальным параллелизмом. Дополнительная степень параллелизма, иначе - вертикальный параллелизм, может быть достигнута при параллельном запуске нескольких, в общем случае различных атомарных операций, которые обычно должны были бы выполняться последовательно. Здесь применима аналогия с конвейером - все операции, проходящие через конвейер, находятся на некоей стадии выполнения и, следовательно, активны в одно и то же время. В случае с базами данных исполнение каждой атомарной операции начинается сразу же с появлением данных, которые она должна обрабатывать, не дожидаясь завершения предыдущего шага и накопления полученных там данных в промежуточном буфере. Сигналом к запуску последующей операции является момент начала поступления данных для нее. Например, операция соединения таблиц может начинать работать одновремено с операциями последовательного чтения и фильтрации строк с диска, а ее результаты по мере поступления могут быть переданы на вход операции сортировки, например, для начального разделения данных по ключу в соответствии с алгоритмом упорядочивания, и при этом все три вида операций: сканирование, объединение и сортировка продолжают работать одновременно. Такой подход, во многом сходный с конвейерной обработкой в современных процессорах, носит название "потока данных" (data flow) или "управления по требованию" (demand driven). Допонительным плюсом этого подхода является то, что его можно успешно применять в аппаратной архитектуре с любой степенью параллелизма, кроме того, внедрение принципа вертикального параллелизма оставляет большое пространство для совершенствования самих алгоритмов, и дает возможность производителям СУБД воспользоваться последними достижениями теории алгоритмов без изменения серверной архитектуры.

Применение вертикального и горизонтального параллелизма (рис.6) увеличивает общую производительность и сокращает время реакции информационной системы за счет ускорения процедур обработки данных. В свою очередь рост объемов обрабатываемых данных обеспечивается вертикальным и/или горизонтальным масштабированием аппаратной платформы.

Рисунок 6.
Горизонтальный и вертикальный параллелизм в обработке SQL-запроса.

Многопотоковая архитектура СУБД

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

Рисунок 7.
Иерархия ОС, процессов и потоков.

Часто в качестве синонима потока используется термин "легковесный процесс" (light- weighted process), поскольку затраты ресурсов на запуск, останов, а также создание или уничтожение потока силами управляющего процесса гораздо ниже по сравнению с действиями ОС над обычными процессами. В приципе для обеспечения параллелизма поток может быть клонирован или поделен на подзадачи - потоки более низкого уровня, примерно так же, как и любой процесс внутри операционной системы. В результате потоки избавляют операционную систему от создания, планирования и манипуляции множеством процессов, и, следовательно, задачи самой ОС существенно меньше загружают вычислительную систему.

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

Выполняя все функции управления ресурсами, необходимые СУБД, включая динамическое размещение буферов в памяти и пространства на диске, систему блокировок и пр., многопотоковая архитектура сервера баз данных фактически является специализированной операционной системой, манипулирующей множеством потоков и планирующей их выполнение. В соответствии с подходами в реализации ОС планировщик многопотоковой СУБД может быть выполнен как вытесняющий или невытесняющий. В невытесняющей схеме поток продолжает выполняться до тех пор, пока сам не просигнализирует планировщику о завершении какого-то кванта работы, после чего планировщик назначает на выполнение другой поток. Обычно такой планировщик использует кольцевой (round-robin) алгоритм постановки потоков в очередь на запуск. Выполяемый поток определяет момент своей остановки по истечении временного интервала, выполнении критической секции кода или по необходимости выполнить блокирующий вызов, например, операцию ввода/вывода. Такой механизм удобен для сервера, занимающегося исключительно обслуживанием базы данных или в среде однотипных запросов, где набор потоков или их число относительно невелики и, следовательно, их поведение хорошо предсказуемо. В вытесняющей схеме поток может быть прерван по инициативе планировщика, например, при попадании в очередь более приоритетного потока. Этот принцип эффективен в системах с неспецифицированными запросами или при параллельной загрузке системы задачами, не связанными с базами данных, т.е. там, где стратегия планирования в зависимости от решаемых задач может изменяться в широких пределах.

Смешанная загрузка в современных СУБД

Эволюция в области информационных систем все отчетливее направлена в сторону объединения трех видов задач: оперативной обработки транзакций (OLTP), поддержки принятия решений (DSS) и пакетной обработки (batch processing), которые ранее искусственно разделялись. Одновременное исполнение задач смешанного характера, разделяющих общие вычислительные ресурсы и базы данных, называется "оперативной сложной обработкой данных" (OLCP - On Line Complex Processing). Управление ресурсами, оптимизация и администрирование гибридной системы гораздо сложнее, чем в системе, ориентированной на решение единственной задачи, поскольку различные типы приложений предъявляют противоречивые требования к конфигурации. Тем не менее преимуществом концепции смешанной загрузки является более полное соответствие задачам реальной жизни, а не удобству обработки данных. Например, экспертный анализ или загрузку/выгрузку данных пользователям хотелось бы производить в реальном времени, одновременно со вводом и модификацией данных. С применением параллельных архитектур и связанным с ними значительным ускорением обработки и масштабируемыми объемами обрабатываемой информации ожидается появление систем, поддерживающих смешанную загрузку.

Часто производители СУБД предлагают архитектурные решения сервера для определенных классов приложений. Например, сервер для обработки транзакций был бы построен в предположении, что

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

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

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

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

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

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

оптимизация запросов;
эффективное управление ресурсами ;
параллельная обработка запросов.

Оптимизатор запросов

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

Управление ресурсами

Оптимальное управлении ресурсами требует поддержки прозрачности доступа к ресурсам в целом и эффективного использования каждого ресурса в отдельности. Поддержка прозрачности доступа очень актуальна. Например, создавая приложение в архитектуре клиент/сервер, разрабочик не может и не должен строить предположений о том, как на самом деле взаимодействуют клиент и сервер. Использование в качестве среды коммуникаций сети или сегмента разделяемой памяти, никак не должно влиять на идеи разработки, точно так же приложение не может как-то ограничивать коммуникационные решения СУБД. Если приложение и сервер баз данных находятся на одном компьютере, то пересылку сообщений между ними наиболее эффективно можно организовать через разделяемую память. Это может быть особенно эффективно для буферизации результатов обширной выборки с помощью курсора. Один из наиболее важных ресурсов - оперативная память. Оптимальное управление распределением памяти настолько же критично для производительности системы, как и уменьшение загрузки ОС, требующее многопотоковой архитектуры сервера баз данных. Приложения СУБД используют разделяемую память для сохранения контекста подключения, а также кэширования запросов и результатов. В некоторых серверах баз данных память отводится отдельно для каждого пользователя, и это значит, что считанные в нее страницы данных или индексов (единицы обмена СУБД с диском) будут недоступны другим пользователям до тех пор, пока они не считают эти данные повторно. В других архитектурах в память помещаются большие объемы информации о возможном откате транзакций (undo log) каждого пользователя, что противоречило бы используемому в многопотоковой архитектуре принципу минимальности хранимого контекста подключения, необходимого для эффективного управления потоками. Как минимум, необходимы продуманные алгоримы управления памятью, например, динамические разделяемые всеми приложениями буферы и кэш-области, наращиваемое по требованию распределение стека, функциональное разделение структур в памяти по типам решаемых задач (рис.8). Без этого архитектура сервера баз данных будет неспособна одновременно удовлетворить потребностям оперативной обработки транзакций, системам принятия решений и пакетной обработки. И еще момент, который стоит отметить, - исключение простаивания ресурсов процессоров. При необходимости выполнить вызов, блокирующий процесс, (например, операцию ввода/вывода) есть смысл передать этот вызов как запрос другому процессу, а вместо ожидаемого окончания операции потока (или процесса) собственный планировщик сервера баз данных может запустить следующий поток из очереди на обработку. При этом процесс и, следовательно, обработка запросов не будут принудительно остановлены средствами ОС. В деятельности планировщика заданий внутри сервера важна также гранулярность той порции обработки, которая по каким-либо причинам, например, для лучшей изоляции транзакции, должна завершиться до передачи управления другому потоку. Обычно квант обработки имеет некий функциональный смысл - завершение SQL-запроса или атомарной операции. Если операция продолжительна, например, при соединении таблиц в сложном аналитическом запросе, это может вызвать общую задержку системы и совершенно недопустимо при совмещении задач принятия решений с чувствительными к времени реакции задачами обработки транзакций. В условиях смешанной загрузки предпочтительнее поддерживать достаточно стабильный размер кванта обработки.

Рисунок 8.
Примерная схема разделяемой памяти.

Параллельная обработка запросов

Параллельная обработка является решением при низком быстродействии, характерном для сложных запросов и больших размеров обрабатываемой информации, например, массированно обновляемых крупных таблиц. Организуя доступ и параллельную обработку небольших порций данных, параллелизм значительно улучшает производительность систем принятия решений и пакетной обработки. Эти улучшения позволяют включать сложные запросы в массовые транзакции, не жертвуя целостностью данных и изолированностью каждой транзакции, что невозможно в традиционных системах. Имея приемлемое время реакции, аналитические (DSS) запросы не конкурируют c оперативной обработкой транзакций (OLTP) и не разрушают среду OLTP.

Постоянная доступность данных

Основные моменты, обеспечивающие постоянную готовность современных СУБД можно определить, как:

оперативное администрирование;
функциональная насыщенность СУБД.

Оперативное администрирование

Утилиты администрирования в идеале призваны поддерживать бесперебойное функцинирование СУБД, что подразумевает сведение к минимуму планируемых или сбойных простоев системы. На практике систему иногда требуется остановить для выполнения какой-либо утилиты. Утилиты для пакетной загрузки/выгрузки данных, архивирования и восстановления, проверки целостности, реорганизации индекса и пр. - все должны эффективно выполняться в оперативном (on-line) режиме, без остановки СУБД, причем для ускорения предпочтительно использовать параллельные алгоритмы. При возникновении сбоя во время этих, как правило, продолжительных операций, с помощью контрольных точек (checkpoints) или даже специальных журналов должен обеспечиваться повторный запуск административных утилит непосредственно с точки останова. Для сокращения времени автономного (off-line) обслуживания необходима поддержка таких возможностей, как автоматическое, без участия оператора, оперативное архивирование заполненных журналов и базы данных одновременно на несколько архивных устрйств, автоматический перезапуск системы с контролируемым временем восстановления и т.д. Задачи администрирования, включая мониторинг и реконфигурацию ресурсов системы, часто вступают в противоречие с доступностью данных. В идеале выполнение операций по реорганизации и перемещению крупных таблиц и индексов в пределах системы не обязано ограничивать доступ к таблице, части таблицы или к базе данных. Даже в случае необходимости выключения части базы данных, например из-за физического повреждения таблиц или их частей, работоспособные части таблиц и базы данных должны оставаться доступными для приложений в течение времени восстановления (рис.9). При этом приложения должны, конечно, знать, что вместо целой таблицы для запросов доступна лишь ее часть. Вообще, любые административные действия, включая физическое планирование, размещение, перемещение и реорганизацию баз данных, управление дисковым пространством, архивирование и восстановление журналов и частей баз данных, перезапуск СУБД должны быть максимально прозрачными для приложений. Средства мониторинга инсталляции СУБД должны позволять пользователям строить свои собственные управляющие процедуры, отражающие специфику применения СУБД. При этом важны такие параметры, как возможность централизации управления, подобно средствам прежних централизованных систем (mainframes), выполнение операций в назначенное время без участия оператора (unattended or scheduled), одновременное использование всех доступных архивных устройств вычислительной платформы. Все это обеспечивает максимальную готовность и доступность информационной системы.

Рисунок 9.
Оперативное параллельное восстановление базы данных.

Функциональная насыщенность СУБД

Общим термином "функциональная насыщенность" можно определить множество механизмов, используемых серверами баз данных (а) для уменьшения последствий системных сбоев и (б) для повышения прозрачности доступа к дублированным данным при нормальном функционировании. Теоретически отказоустойчивая СУБД обязана обеспечивать доступ к данным по чтению и записи независимо от обстоятельств, будь то сбой аппаратной платформы или какого-то компонента СУБД. Кроме того, существует класс систем, в которых требования к доступности данных не так высоки, т.е. допустим временный, хотя и очень короткий (несколько минут в год), период неработоспособности. Системы, обеспечивающие непрерывный доступ к данным (fault tolerant) или почти непрерывный (high availability), обычно опираются на различные формы избыточности, как правило, это системы дублирования аппаратного обеспечения и контролируемой избыточности данных. Аппаратная избыточность может включать платформы с полным резервированием, поддерживающие (standby) процессоры, диски с двойным интерфейсом (dual-port), дисковые массивы и пр. Один из вариантов - зеркалирование дисков, в которой один диск используется в качестве копии другого и может быть использован при сбое вместо него. Хотя аппаратная избыточность и важна для повышения общей надежности системы, ее реализация, как правило, не ориентирована на обработку транзакций СУБД и на связанные с этим специфические ограничения, например, обеспечение атомарности транзакции. В результате СУБД не может воспользоваться преимуществами чисто аппаратных решений резервирования системы для повышения своей производительности. Управляемая избыточность данных обычно представлена в двух формах - программное зеркалирование (software mirroring) и тиражирование (replication) данных. Программное зеркалирование дисков, называемое также дуплексированием (duplexing) или мультиплексированием (multi-plexing), может не только защитить от аппаратных сбоев, но и улучшить производительность. Поскольку зеркалирование базы данных (или ее части - таблиц(ы), индексов, их фрагментов и пр.) производится на другом физическом устройстве, то операции чтения данных можно распределить между двумя устройствами и производить параллельно (рис.10). Конечно, зеркалирование бесполезно с любой точки зрения, если оно организовано на одном диске.

Рисунок 10.

В случае повреждения зеркалируемого диска все операции автоматически переносятся на исправный диск, сбойный диск выводится в отключенное состояние, причем приложения не замечают каких-либо изменений в конфигурации системы. После замены неисправного диска параллельно с работой пользователей запускается процесс оперативной синхронизации зеркальных дисков (on-line remirroring), на физическом уровне копирующий рабочий диск. Тиражирование в системах, требующих в первую очередь повышенной надежности, в целом подобно зеркалированию, но здесь копия данных может поддерживаться удаленно. Если происходит копирование всей базы данных, то обычно это делается с целью обеспечить горячий резерв (warm standby). Однако в некоторых реализациях есть возможность использовать копию для просмотра (не модификации) данных. Это способно обеспечить значительные преимущества для систем со смешанной загрузкой, приложения для принятия решений, генерации отчетов и не модифицирующие данные задачи пакетной обработки могут обращаться к копии базы данных, в то время как приложения оперативной обработки транзакций используют первичную базу данных (рис.11).

Рисунок 11.

Заключение

В данной статье автор постарался изложить принципы оценки новейших реализаций реляционных СУБД, использующих механизмы параллельной обработки. Одни из важнейших качеств таких СУБД - обработка все более сложных запросов в реальном времени и управление большими и сверхбольшими базами данных (VLDB), что выдвигает параллельные СУБД в отдельный класс инструментальных информационных систем, обслуживающих наиболее отвественные потребности промышленной обработки данных. Надо отметить, что разработчики последнего поколения РСУБД стали пионерами в промышленном освоении вычислительной мощности многопроцессорных архитектур. В качестве аппаратной платформы для демонстрации возможностей параллельных СУБД в статье в первую очередь рассматривается наиболее практически освоенная и широко распространенная симметричная многопроцессорная (SMP) архитектура. В будущем планируется поближе оценить слабосвязанные многопроцессорные архитектуры. В качестве основных параметров, характеризующих потребительские свойства параллельнных СУБД, были выбраны - масштабируемость, - производительность, - оперативная обработка сложных запросов и оперативное администрирование; т.е. задачи, наиболее полно реализуемые с приходом приципов параллельной обработки. Автор намеренно не пытался ограничиться текущим состоянием какого-либо конкретного продукта - уже в течение ближайшего года возможности серверов Informix, Oracle и Sybase в целом будут очень близки, что позволит характеризовать 95-й год, как начало эры параллельных архитектур.

Литература:

D.McGoveran. "An Evaluation of Database Server Architectures" У 1993, Alternative Technologies
Informix - OnLine Dynamic Server 6.0, 7.1. Training Course У 1993, 1994, Informix SoftWare Inc.
ORACLE for UNIX. Perfomance Tuning Tips. У 1993, Oracle Corp.
M.Ferguson. "Parallel Database - the Shape of Thing to Come". Database Programming & Design, October, November 1994.