2.4.4. Схемы размещения и доступа к данным в распределенных бд
Размещение данных в распределенных БД характеризуется следующими понятиями:
Фрагментация – возможность разделения любой записи на некоторое количество частей, называемых фрагментами, которые затем могут быть распределены по различным узлам. Два основных типа фрагментации: горизонтальная и вертикальная. В первом случае фрагменты представляют собой подмножество строк, во втором – столбцов (атрибутов).
Размещение. Каждый фрагмент сохраняется на узле, выбранном с учетом оптимальной схемы доступа.
Репликация – возможность поддержки актуальной копии некоторого фрагмента на нескольких различных узлах.
Определение и размещение фрагментов должно проводиться с учетом особенностей использования БД (в частности, на основе анализа транзакций).
Стратегии размещения данных в системе:
Централизованное размещение. Стратегия предусматривает создание на одном из узлов единственной БД, доступ к которой будут иметь все пользователи сети. Фактически это вырожденный случай, т.е. случай распределенной обработки, а не распределенных данных, и называть БД распределенной в данном случае можно только в самом широком смысле.
Фрагментированное размещение. БД разбивается на непересекающиеся фрагменты, каждый из которых размещается на одном узле системы. Соответственно, требуется решать проблему выполнения распределенных запросов – как на выборку, так и на изменение.
Размещение с полной репликацией. Стратегия предусматривает размещение полной копии всей БД на каждом из узлов системы. Для сокращения затрат на передачу информации в некоторых случаях используется технология снимков. Снимок представляет собой копию БД в определенный момент времени. Эти копии обновляются через некоторый установленный интервал времени, например, раз в час или раз в сутки.
Размещение с избирательной репликацией. Стратегия представляет собой комбинацию методов фрагментации, репликации и централизации. Одни массивы данных разделяются на фрагменты, что позволяет добиться для них высокой локализации ссылок, тогда как другие, используемые на многих узлах, но не подверженные частым обновлениям, подвергаются репликации.
2.4.4.1. Управление параллельной обработкой в распределенных БД
В распределенных БД используется технология двухфазной фиксации или двухфазной блокировки транзакций (2PC – 2-Phase Commit, 2PL – 2-Phase Lock). Она заключается в том, что сначала от всех узлов, где изменяются данные, запрашивается подтверждение блокировки, а затем эта блокировка подтверждается.
Двухфазные протоколы не могут устранить возможность взаимной блокировки, поскольку при их использовании могут возникать ситуации, когда некоторый узел остается заблокированным.
Неблокирующий протокол трехфазной фиксации транзакций не имеет периода ожидания в состоянии неопределенности, в которое уходят участники с момента подтверждения своего согласия на фиксацию транзакции и до момента получения от координатора извещения о глобальной фиксации или глобальном откате. В трехфазном протоколе между этапами голосования и принятия глобального решения вводится третий этап, называемый предфиксацией. После получения результатов голосования всех участников координатор рассылает глобальное сообщение PRECOMMIT. Таким образом, участник, получивший глобальное извещение о предфиксации, знает, что все остальные участники проголосовали за фиксацию результатов транзакции, и что со временем сам этот участник также выполнит фиксацию транзакции, если не произойдет отказ. Далее каждый участник подтверждает получение сообщения о предфиксации, после чего координатор, получив все подтверждения, рассылает команду глобальной фиксации транзакции.
2.4.4.2. Технологии и средства удаленного доступа
При необходимости организации удаленного доступа используют так называемое ПО промежуточного уровня (middleware), которое можно разделить на две категории:
ПО доступа к БД (например, ODBC-интерфейсы и SQL-шлюзы);
ПО межмодульного взаимодействия (системы вызова удаленных процедур – RPC – Remote Procedure Call, мониторы обработки транзакций – TPM – Transaction Processing Monitor).
2.4.4.3. ODBC
Чтобы практически реализовать унифицированный доступ к разным СУБД посредством разных сетевых протоколов, в ОDВС каждой паре СУБД/протокол соответствует свой DLL-драйвер.
ODBC-архитектура включает в себя:
Приложение. Обрабатывает данные, вызывает ODBC-функции для выполнения SQL-инструкций, получает результаты.
Менеджер драйверов. Загружает драйверы по запросу приложений.
Драйверы. Обрабатывают вызовы ODBC-функций, передают SQL-инструкции конкретным СУБД и возвращают результаты приложениям. При необходимости модифицируют SQL-инструкции и результаты, если того требует специфика СУБД.
Источники данных. Включают в себя СУБД, операционную и сетевую платформы.
|
Рисунок 4. Архитектура ODBC |
ODBC опирается на спецификацию SQL CLI (Call Level Interface), входящую в стандарт SQL. Интерфейс ODBC API реализован как набор DLL-библиотек под Windows. Библиотека ODBC.dll содержит функции вызовов специализированных драйверов для различных БД.
2.4.4.4. RPC
Основные идеи, реализованные в RPC:
взаимодействие во многих случаях имеет асимметричный (клиент-серверный) характер, что на логическом уровне описывается как вызов процедуры;
преобразование форматов при передаче данных между машинами различной архитектуры.
Интерфейс взаимодействия между клиентской и серверной частями описывается на языке IDL (Interface Definition Language). Компилятор транслирует описание интерфейса в заглушку (суррогат) клиента (client stub). Формируемый при этом заголовок интерфейса включается в приложение клиента. Заглушка клиента, к которой обращается приложение клиента, оформляет вызов удаленной процедуры. Функции библиотеки RPC формирует из параметров вызова пакет, который доставляется через протоколы RPC функции приема аналогичной библиотеки на стороне сервера. Библиотека RPC на серверной стороне распаковывает параметры и передает их заглушке сервера (server stub). Заглушка сервера формирует локальный вызов сервера (см. рис. 5). Заглушка сервера и заголовок интерфейса, используемый серверным приложением, компилируются для платформы сервера.
|
Рисунок 5. Архитектура RPC |
2.4.4.5. Мониторы обработки транзакций
Первоначально основной задачей ТРМ в среде клиент-сервер было сокращение числа соединений клиентских систем с базами данных. При непосредственном обращении клиента к серверу базы данных для каждого клиента устанавливается соединение с СУБД, которое порождает запуск отдельного процесса в рамках операционной системы. TPM брали на себя роль концентратора соединений клиентов с СУБД, становясь посредником между ними. Основное назначение TPM – автоматизированная поддержка приложений, представленных в виде последовательности транзакций.
Одна из основных функций ТРМ – обеспечение быстрой обработки запросов, поступающих к серверу приложений от множества клиентов (от сотен до тысяч). ТРМ выполняет ее, мультиплексируя запросы на обслуживание, направляя их серверам приложения, число которых контролируется им самим.
Важнейшее свойство ТРМ — поддержка многомашинных конфигураций с возможностью миграции серверов приложений и их групп на резервный компьютер в случае сбоев в работе основного. Это свойство может быть использовано для построения высоконадежных систем.
На современном рынке мониторов транзакций основными являются такие системы, как ACMS (DEC), CICS (IBM), TOP END (NCR), PATHWAY (Tandem), ENCINA (Transarc), TUXEDO System (Novell).
Модель обработки транзакций. Транзакция в TPM – это не последовательность операций обработки данных в БД, а последовательность действий достаточно различной природы – передача сообщений, опрос датчиков, формирование отчетов, запись данных в файлы и т.д. Это позволяет реализовать в ТРМ прикладные транзакции, бизнес-транзакции, которые в СУБД не предусмотрены.
ТРМ опирается на модель обработки распределенных транзакций X/Open DTP (Distributed Transaction Processing), которая описывает взаимодействие трех субъектов обработки транзакций – прикладной программы, менеджера транзакций (Transaction Manager – TM) и менеджера ресурсов (Resource Manager – RM). Модель представлена на рис. 6.
Рис. 6. Модель обработки распределенных транзакций X/Open DTP
Приложение взаимодействует с RM либо с помощью набора специальных функций, либо посредством операторов языка SQL, инициируя необходимые операции с данными. Последние оформляются как транзакции, обработку которых берет на себя TM. Если с помощью монитора транзакций необходимо решать задачи обработки распределенных транзакций, то роль менеджера ресурсов должна играть СУБД, поддерживающая двухфазовый протокол фиксации транзакций и удовлетворяющая стандарту X/Open XA (например, Oracle 7.x, OpenINGRES, Informix-Online 7.x).
Роль ТМ в модели X/Open DTP — это роль диспетчера, главного координатора транзакций. Он обладает полным набором функций управления как локальными, так и глобальными распределенными транзакциями. В результате транзакция может обновлять данные на нескольких узлах, с различными функционирующими RM. Обработка распределенных транзакций обеспечивается за счет использования протокола двухфазовой фиксации транзакций.
Для координации взаимодействий клиента и сервера TM в модели X/Open DTP используется высокоуровневый интерфейс ATMI, представляющий собой набор вызовов функций на языке третьего поколения (например, на языке Си). С его помощью разработчик реализует один из нескольких режимов взаимодействия клиента и сервера в рамках расширенной модели «клиент—сервер». Ни сервер приложения, ни клиент приложения не содержат явных вызовов менеджера транзакций — они включены в библиотечные функции ATMI и «невидимы» извне. Таким образом, детали взаимодействия прикладной программы и монитора транзакций скрыты от разработчика.