Распределенная обработка данных Модели серверов баз данных

Модель активного сервера БД

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

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

Схема модели

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

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

Взаимодействие пользовательских и клинтских процессов

многопотоковая односерверная архитектура Сервер единственный обладает монополией на управление данными и взаимодействует одновременно со многими клиентами; Логически каждый клиент связан с сервером отдельной нитью («thread»), или потоком, по которому пересылаются запросы.

Схема

Недостатки Так как сервер может выполняться только на одном процессоре, возникает естественное ограничение на применение СУБД для мультипроцессорных платформ.

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

Схема

Недостатки в систему добавляется новый слой, который размещается между клиентом и сервером, что увеличивает трату ресурсов на поддержку баланса загрузки актуальных серверов («load balancing»). становится невозможным направить запрос от конкретного клиента конкретному серверу серверы становятся равноправными нет возможности устанавливать приоритеты для обслуживания запросов.

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

Схема

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

Распараллеливание запроса

Типы параллелизма Горизонтальный параллелизм. Вертикальный параллелизм. Гибридный параллелизм.

Горизонтальный параллелизм. Этот параллелизм возникает тогда, когда хранимая в БД информация распределяется по нескольким физическим устройствам хранения нескольким дискам. При этом информация из одного отношения разбивается на части по горизонтали параллельность здесь достигается путем выполнения одинаковых операций, например фильтрации, над разными физическими хранимыми данными. Эти операции могут выполняться параллельно разными процессами, они независимы. Результат выполнения целого запроса складывается из результатов выполнения отдельных операций.

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

Выполнение запроса при вертикальном параллелизме

Пример Пример запросов реляционной алгебры: 1. R5 = R1 [ A,C] 2. R6 = R2 [A,B,D] 3. R7 = R5 [A > 128] 4. R8 = R5 [A]R6. то операции первую и третью можно объединить и выполнить параллельно с операцией два, а затем выполнить над результатами последнюю четвертую операцию.

Гибридный параллелизм.

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

- Informix On-Line фирмы Informix Software; - Ingres Intelligent Database фирмы Ingres Corp; - Oracle (version 7) фирмы Oracle Corp; - Sybase System 10 фирмы Sybase Inc.

Президент фирмы Alternative Technologies Макговерн сформулировал 13 основных функций, которые должна поддержива ть распределенная СУБД

Функции распределенной СУБД 1. РАСПРЕДЕЛЕННЫЙ СЛОВАРЬ (ДИРРЕКТОРИЯ) ДАННЫХ. В словаре содержится информация о типе данных, месте их размещения и о способе доступа к данным. 2. ПРОЗРАЧНЫЙ ПРОТОКОЛ ДВУХФАЗНОй ФИКСАЦИИ ИЗМЕНЕНИЙ. Этот протокол обеспечивает непротиворечивость данных. При выполнении транзакции, изменяющей данные в нескольких узлах, протокол двухфазной фиксации обеспечивает успешное выполнение всей транзакции только в том случае, если успешно выполнилась обработка в каждом узле. Если же в одном из узлов обработка не выполнена успешно, то анулируются результаты работы всей транзакции. 3. ГОРИЗОНТАЛЬНАЯ И ВЕРТИКАЛЬНАЯ ФРАГМЕНТАЦИЯ. Эта функция позволяет "расщеплять" таблицу БД по строкам (горизонтально) и по столбцам (вертикально) и размещать части данных таблицы в разных узлах сети.

4.НЕЗАВИСИМОСТЬ ДУБЛИРОВАНИЯ ДАННЫХ. Это свойство СУБД позволяет создавать в узлах сети дубли данных без снижения производительности приложения и без нарушения непротиворечивости данных. 5. РАСПРЕДЕЛЕННЫЕ ПРЕДСТАВЛЕНИЯ (views). Представления могут формироваться при выполнении операции соединения (join) таблиц, размещающихся в разных узлах. 6. ОПТИМИЗАЦИЯ РАСПРЕДЕЛЕННЫХ ЗАПРОСОВ. Опти мизация алгоритмов выполнения сложных операций, например соединения таблиц, выполняется с учетом размещения данных в глобальной сети. При этом учитывается пропускная способность сети, ее загрузка и объем передаваемой информации, вычислительная мощность узлов. На основе этой информации делается вывод о том, где лучше всего производить операцию соединения таблиц (как наиболее трудоемкую операцию).

7. РАСПРЕДЕЛЕННЫЕ ОГРАНИЧЕНИЯ ЦЕЛОСТНОСТИ. Эта функция обеспечивает ссылочную целостность данных. В узлах могут находиться таблицы, зависящие от некоторой таблицы- мастера. При модификации данных таблицы-мастера автоматически модифицируются зависимые таблицы. 8. ЛОКАЛЬНАЯ АВТОНОМИЯ. Администратор БД конкретного узла полностью контролирует данные локальной БД данного узла. Он может работать независимо от администраторов других узлов. 9. НЕПРЕРЫВНАЯ ОБРАБОТКА (continual operation). Обработка, выполняемая в локальном узле БД, не может быть прервана командами из другого узла. Т.е. в каждом узле обработка выполняется независимо и целиком.

11. ОБРАБОТКА РАСПРЕДЕЛЕННЫХ ТРАНЗАКЦИЙ. Обеспечение ограничений целостности поддерживается и при выполнении транзакции, изменяющей несколько узлов. 12. ГЛОБАЛЬНАЯ ОБРАБОТКА ВЗАИМОБЛОКИРОВОК И ПРОБЛЕМ, ВОЗНИКАЮЩИХ ПРИ ОДНОВРЕМЕННОМ ДОСТУПЕ К ДАННЫМ. Блокировка данных может выполняться во всех узлах БД. Необходимо выявлять и разрешать ситуации, когда два узла взаимно блокируют друг друга. 13. НЕЗАВИСИМОСТЬ ОТ ТИПА КОМПЬЮТЕРОВ, ОПЕРАЦИОННЫХ СИСТЕМ, СЕТЕВЫХ ПРОТОКОЛОВ, ТИПОВ СУБД. Эта независимость осуществляется путем использования как встроенных в СУБД средств, так и шлюзов (gateways).

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