Современные технологии БД предъявляют определенные требования в области архитектуры. До недавнего времени выделялось три класса задач (и, соответственно, три класса систем):

• задачи оперативной обработки транзакций (OLTP - OnLine Transaction Processing);
• задачи пакетной обработки (batch processing);
• задачи принятия решений (DSS - Decision Support System).

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

Системы OLTP характеризуются:

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

Практически все запросы к базе данных в OLTP-системах состоят из команд вставки, обновления, удаления. Запросы на выборку в основном предназначены для предоставления пользователям возможности выбора из различных справочников. Большая часть запросов, таким образом, известна заранее еще на этапе проектирования системы. Таким образом, критическим для OLTP-приложений является скорость и надежность выполнения коротких операций обновления данных.

Системы поддержки принятия решений (Decision Support System - DSS), ориентированны на анализ данных, на выполнение более сложных запросов, моделирование процессов предметной области, прогнозирование, нахождение зависимостей между данными (например, можно попытаться определить, как связан объем продаж товаров с характеристиками покупателей), для проведения анализа "что если:". (аналитические системы). Под DSS понимают человеко-машинный вычислительный комплекс, ориентированный на анализ данных и обеспечивающий получение информации, необходимой для принятия решений в сфере управления.

В последнее время из DSS-систем стали выделять новый класс систем - OLAP-системы. Под OLAP-системой (On-Line Analitical Processing - OLAP) понимают DSS-систему, основанную на концепции хранилищ данных и обеспечивающих малое время выполнение аналитических запросов.

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

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

Эволюция в области информационных систем движется в направлении объединения этих трех классов задач. Одновременное выполнение всех трех классов задач носит названия "оперативной сложной обработки данных - OLCP"( это первое).

Второе. Несмотря на то, что платформы сейчас в основном однопроцессорные, все возрастающее значение приобретают три архитектурных направления:

• симметричная многопроцессорная архитектура (SMP - Symmetric MultiProcessing) - наиболее общая форма сильно связанных многопроцессорных систем; означает, что системы имеют совместно используемую ОП и дисковое пространство;
• слабосвязанные многопроцессорные системы - системы, представляющие совокупность самостоятельных компьютеров, объединенных сетью и имеющих совместно используемую дисковую память, но различную организацию ОП (например, в виде кластеров - Cluster);
• системы с массовым параллелизмом (MPP - Massivly Parallel Processing) - детали организации самые различные.

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

Основным критическим фактором в платформе OLCP является архитектура сервера БД (СБД). К архитектурам современных СУБД предъявляют 4 требования:

• масштабируемость (расширяемость) - I;
• производительность - II;
• возможность смешанной загрузки различными типами задач (OLCP) - III;
• обеспечение постоянной доступности данных - IV.

I. Масштабируемость (расширяемость)

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

Различают два способа масштабируемости СБД: горизонтальную и вертикальную.

Горизонтальное расширение может быть получено, когда несколько серверов действуют независимо и делят рабочее пространство (более подходит для кластерных систем и распределенных БД, но требует дополнительного администрирования).

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

Важность расширяемости:

• постепенное, шаг за шагом наращивание мощности (зная предсказываемый результат);
• быстрая смена технологий и новых решений, требующих инкрементного (шаг за шагом) подхода.

Основными характеристиками расширяемости являются:

• поддержка многопроцессорности (I-1);
• расширяемость архитектуры (I-2).

I-1. Многопроцессорность

С многопроцессорностью связаны две проблемы:

• растяжимость;
• прозрачность.

Растяжимость означает, что архитектура СУБД не д.б. специализирована некоторым заданным числом процессоров (с одинаковым успехом она должна поддерживать и один и 8 CPU - и без дополнительных продуктов).

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

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

I-2. Расширяемость архитектуры

Динамическая расширяемая архитектура (DSA- Dynamic Scalable Architecture) обеспечивает способность на ходу определять потребность памяти, количество параллельных потоков выполнения заданий, будь то настоящие потоки (threads), процессы ОС, виртуальные процессоры, фрагментов таблиц и индексов, а также осуществляет их распределение по физическим дискам без останова и перезапуска системы, исходя из загрузки задачами и вследствие увеличения размеров БД.

По сути это ОС управления данными, которая может динамически распределять ресурсы и, что самое главное, предполагает единую схему расширяемости от 1-CPU систем, систем SMP и Cluster-систем до систем с MPP.

II. Производительность

Два основных метода повышения производительности:

• Многопроцессорная обработка с помощью процессов типа "thread" (II-1);
• Поддержка параллелизма (II-2).

II-1. Многопроцессорная обработка с помощью процессов типа "thread"

Многопотоковой архитектурой называется способ организации одновременной обработки множества процессов внутри сервера БД при минимальных накладных расходах на переключение контекста и максимальном разделении ресурсов. Основная идея многопотоковой архитектуры (DSA-Dynamic Scalable Architecture) - обеспечить распределение вычислительных ресурсов между запросами пользователей непосредственно в сервере СУБД, не доверяя средствам ОС (с целью сократить накладные расходы)

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

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

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

II-2. Поддержка параллелизма

Три области применения параллельных алгоритмов:

• параллельный в/в (1);
• параллельные средства администрирования (2);
• параллельная обработка запросов к базе данных (3).

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

(2) - выполнение административных утилит (загрузка, выгрузка данных, архивирование и восстановление данных) параллельно в Online-режиме.

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

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

Для обеспечения параллелизма выбирается такой набор атомарных операций (scan - просмотр таблицы, join - соединение таблиц, sort - сортировка и т.д.), которые

а) могли бы тиражироваться и выполнять свою часть задачи;

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

Такое создание множества копий одной атомарной операции, выполняющих одну и ту же задачу (!!!), называется горизонтальным параллелизмом.

Дополнительную степень параллелизма (вертикальный или конвейерный параллелизм) достигается при параллельном запуске нескольких, общем случае различных атомарных операций, выполняемых обычно последовательно (аналогия с конвейером). Сигналом к запуску последующей операции является момент появления данных для нее (join м.б. начата параллельно с операцией scan с диска, а ее результаты по мере поступления могут поступать на вход операции sort).

Достоинства вертикального параллелизма:

• Можно применять в аппаратной архитектуре с любой степенью параллелизма;
• Остается большое пространство для совершенствования самих алгоритмов

III. Cмешанная загрузка СУБД (OLCP)

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

Сервер оперативной обработки транзакций строится в предположении:

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

Реализация такого сервера опирается на:

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

Для сервера системы принятия решений (DSS) выдвигаются такие требования:

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

Как результат:

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

Сервер, ориентированный на пакетную обработку, основан на предположениях:

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

В случае объединения всех задач, если не применять дополнительных мер, эффективность и производительность будет крайне низка (противоречие требований).

Основные факторы, обеспечивающие эффективную реализацию универсальной системы (OLCP):

• оптимизация запросов (III-1); (см. выше)
• параллельная обработка запросов (III-2); (см. выше)
• эффективное управление ресурсами (III-3).

III-3. Эффективное управление ресурсами

Здесь такие источники:

1. Прозрачная поддержка и использование ресурсов.

Например, при разработке приложения по архитектуре "клиент-сервер" приложение не должно знать, как клиент и сервер обмениваются сообщениями: через сеть или через ОП.

2. Эффективное использование ОП.

Использование механизма разделяемой памяти.

3. Эффективное управление процессорами с использованием процессов типа "thread".

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

Основными характеристиками доступности являются:

• оперативное администрирование в режиме OnLine (IV-1);
• функциональная насыщенность (устойчивость) СУБД (IV-2).

IV-1. Оперативное администрирование в режиме OnLine

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

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

Функциональная насыщенность - множество механизмов, используемых серверами БД для

• уменьшения последствий системных сбоев (1),
• повышения прозрачности доступа к дублированным данным в нормальных условиях (2).

Основа: теоретически СУБД обязана обеспечить доступ к данным по чтению или по записи, независимо от обстоятельств, будь то сбой аппаратной платформы или какого-то ее компонента. Для обозначения такого уровня доступности используется термин 'нечувствительность к сбоям'.

Решения: системы, обеспечивающие непрерывный доступ к данным (fault tolerant) или почти непрерывный (hight availability) обычно опираются на

• различные формы избыточности, как правило, это системы дублирования аппаратного обеспечения;
• контролируемая избыточность данных.

Решения аппаратной избыточности:

• Платформы с полным резервированием, поддерживающие (standby) процессоры, диски с двойным интерфейсом, дисковые массивы.
• Вариант зеркалирования дисков, когда один диск является полной копией другого

Управляемая избыточность данных обычно представляется в двух формах:

• программное зеркалирование (software mirroring);
• тиражирование данных (replication).