Организация удаленного доступа к распределенным базам данных. Содержание Введение 3 Основные подходы к проектированию распределенных баз данных 5
 Скачать 0.97 Mb.
|
1.3 Обработка распределенных данныхОдна из главных особенностей современных информационных систем - распределенный характер. Возрастает их масштаб, они охватывают все больше число точек по всему миру. Современный уровень принятия решений, оперативное управление информационными ресурсами требует все большей их децентрализации. Информационные системы находятся в постоянном развитии - в них добавляются новые сегменты, расширяется диапазон функций уже действующих. Главная проблема таких систем - организация обработки распределенных данных. Данные находятся на компьютерах различных моделей и производителей, функционирующих под управлением различных операционных систем, а доступ к данным осуществляется разнородным программным обеспечением. Сами компьютеры территориально удалены друг от друга и находятся в различных географических точках планеты. Ответом на задачи реальной жизни стали две технологии: технология распределенных баз данных (Distributed Database) и технология тиражирования данных (Data Replication). Под распределенной базой данных подразумевают базу, включающую фрагменты из нескольких баз данных, которые располагаются на различных узлах сети компьютеров, и, возможно, управляются различными СУБД. Распределенная база данных выглядит с точки зрения пользователей и прикладных программ как обычная локальная база. В этом смысле слово "распределенная" отражает способ организации базы данных, но не внешнюю ее характеристику ("распределенность" базы не должна быть видна извне). В отличие от распределенных баз, тиражирование данных предполагает отказ от их физического распределения и опирается на идею дублирования данных в различных узлах сети компьютеров. Ранее были рассмотрены четыре модели технологии "клиент-сервер". Традиционной и наиболее популярной является модель доступа к удаленным данным (RDA-модель). В соответствии с этой моделью, имеется компьютер, на котором запускаются программы переднего плана (в которых реализованы как функции интерфейса с пользователем, так и прикладные функции) - клиент (называемый обычно локальным узлом - local node), соединенный в сети с компьютером, на котором выполняется сервер базы данных и находится сама база данных (обычно его называют удаленным узлом - remote node). Все проблемы, возникающие при взаимодействии клиента и сервера, должен решать специальный компонент СУБД, называемый коммуникационным сервером (Communication Server, DBMS Server Net). Для поддержки взаимодействия клиента и сервера он должен функционировать на удаленном узле; в то же время на локальном узле должна выполняться программа связи, взаимодействующая с коммуникационным сервером (DBMS Client Net). В основу взаимодействия прикладных программ - клиентов и сервера базы данных, положен ряд фундаментальных принципов, определяющих функциональные возможности современных СУБД в части, касающейся сетевого взаимодействия и распределенной обработки данных, среди которых:
Прозрачный (для пользователя) доступ к удаленным данным предполагает использование в прикладных программах такого интерфейса с сервером БД, который позволяет переносить данные в сети с одного узла на другой, не требуя при этом модификации текста программы. Иными словами, доступ к информационным ресурсам должен быть полностью прозрачен относительно расположения данных. Любой пользователь или любая прикладная программа оперирует с одной или несколькими базами данных. В том случае, когда прикладная программа и сервер БД выполняются на одном и том же узле, проблемы расположения не возникает. Для получения доступа к базе данных, пользователю или программе достаточно указать имя базы. Однако в том случае, когда прикладная программа запускается на локальном узле, а база данных находится на удаленном, возникает проблема идентификации удаленного узла. Для того, чтобы получить доступ к базе данных на удаленном узле, необходимо указать имя удаленного узла и имя базы данных. Если использовать жестко фиксированное имя узла в паре "имя_узла, имя_БД", то прикладная программа становится зависимой от расположения БД. Например, обращение к БД "host::stock", где первый компонент есть имя узла, будет зависимым от расположения. Одно из возможных решений этой проблемы состоит в использовании виртуальных имен узлов. Управление ими обеспечивается специальным программным компонентом СУБД - сервером имен (Name Server), который адресует запросы клиентов к серверам. При установке компонентов DBMS Client Net на локальных узлах выполняется процедура идентификации узлов, когда реальному имени удаленного узла ставится в соответствие виртуальное имя, которое затем используется при обращении к базе данных. Если база данных перенесена на другой узел, то никаких изменений в прикладную программу вносить не нужно - достаточно лишь поставить в соответствие виртуальному имени имя нового узла. Клиент и сервер взаимодействуют по сети с конкретной топологией; для поддержки взаимодействия всегда используется определенный протокол. Следовательно, оно должно быть организовано таким образом, чтобы обеспечивать независимость как от используемого сетевого аппаратного обеспечения, так и от протоколов сетевого обмена. Чтобы обеспечить прозрачный доступ пользователей и программ к удаленным данным в сети, объединяющей разнородные компьютеры, коммуникационный сервер должен поддерживать как можно более широкий диапазон сетевых протоколов (TCP/IP, DECnet, SNA, SPX/IPX, NetBIOS, AppleTalk, и др.). Как только несколько компьютеров различных моделей под управлением различных операционных систем соединяются в сеть, сразу возникает вопрос о согласовании форматов представления данных. Действительно, в сети могут быть компьютеры, отличающиеся разрядностью (16-ти, 32-х и 64-х разрядные процессоры), порядком следования байт в слове, представлением чисел с плавающей точкой и т.д. Задача коммуникационного сервера состоит в том, чтобы на уровне обмена данными обеспечить согласование форматов между удаленным и локальным узлами с тем, чтобы данные, извлеченные сервером из базы на удаленном узле и переданные по сети, были правильно истолкованы прикладной программой на локальном узле. В неоднородной компьютерной среде при взаимодействии клиента и сервера возникает также задача трансляции кодов. Сервер может работать с одной кодовой таблицей (например, EBCDIC), клиент - с другой (например, ASCII), при этом происходит рассогласование трактовки кодов символов. Поэтому, если на локальном узле используется одна кодовая таблица, а на удаленном - другая, то при передаче запросов по сети и при получении ответов на них необходимо обеспечить трансляцию кодов. Решение этой задачи также ложится на коммуникационный сервер. В реальной жизни сервер базы данных должен обслуживать одновременно множество запросов от клиентов - следовательно, в один момент времени таких пар «клиент-сервер» может быть несколько. Таким образом, все проблемы взаимодействия должны решаться коммуникационным сервером для всех этих взаимодействующих пар. Системы с архитектурой "один-к-одному" для обслуживания сервером базы данных одновременно множества клиентов вынуждены загружать отдельный коммуникационный сервер для каждой пары "клиент-сервер". В результате нагрузка на операционную систему увеличивается, резко возрастает общее число ее процессов, расходующих вычислительные ресурсы. Это - один из недостатков архитектуры "один-к-одному". Именно поэтому для современных распределенных СУБД важно иметь многопотоковый коммуникационный сервер, который берет на себя задачи сетевой поддержки множества клиентов, одновременно обращающихся к серверу. На каждом узле сети он поддерживает множество пар соединений "клиент-сервер" и позволяет существовать одновременно множеству независимых сеансов работы с базами данных. С точки зрения клиента доступ к распределенной базе данных должен выглядеть точно так же, как доступ к централизованной БД. При организации прозрачного доступа к распределенной базе данных возникают следующие задачи:
Первая решается путем использования глобального словаря данных. Он хранит информацию о распределенной базе: расположение данных, возможности других СУБД (если используется шлюз), сведения о скорости передачи по сети с различной топологией и т.д. Глобальный словарь данных - это механизм отслеживания расположения объектов в распределенной БД. Данные могут храниться на локальном узле, на удаленном узле, или на обоих узлах - их расположение должно оставаться прозрачным как для конечного пользователя, так и для программ. Не нужно явным образом указывать место расположения данных - программа должна быть полностью независима от того, на каких узлах размещаются данные, с которыми она оперирует. Что касается второй задачи, то она требует интеллектуального решения. Распределенный запрос затрагивает несколько баз данных на различных узлах, причем объемы выборки могут быть весьма различными. Возможны ситуации, когда результирующая таблица запроса представляет собой объединение (join) двух таблиц, причем одна из них находится на локальном узле, а другая - на удаленном. Данный запрос - распределенный, так как затрагивает таблицы, принадлежащие различным базам данных. Для его нормального выполнения необходимо иметь обе исходные таблицы на одном узле. Следовательно, одна из таблиц должна быть передана по сети. Очевидно, что это должна быть таблица меньшего размера. Поэтому оптимизатор распределенных запросов обязательно должен учитывать размеры таблиц. В противном случае запрос будет выполняться непредсказуемо долго. Помимо размера таблиц, оптимизатор распределенных запросов должен учитывать также множество дополнительных параметров, в том числе статистику распределения данных по узлам, объем данных, передаваемых между узлами, скорость коммуникационных линий, структуры хранения данных, соотношение производительности процессоров на разных узлах и т.д. Все эти данные как раз и содержатся в глобальном словаре данных. Решение всех трех задач, возложено на специальный компонент СУБД - сервер распределенных баз данных (Distributed Database Server). Если база данных расположена на одном узле, а сервер БД и прикладная программа выполняются там же, то не требуется ни коммуникационный сервер, ни сервер распределенной БД. Когда же прикладная программа выполняется на локальном узле, БД находится на удаленном узле и там же выполняется сервер БД, то на удаленном узле необходим коммуникационный сервер, а на локальном - сервисная коммуникационная программа. Если локальные БД расположены на нескольких узлах, то для доступа к распределенной БД необходим и сервер распределенной БД, и коммуникационный сервер. Важнейшее требование к современным СУБД - межоперабельность (или интероперабельность). Это качество можно трактовать как открытость системы, позволяющую встраивать ее как компонент в сложную разнородную распределенную среду. Межоперабельность достигается как за счет использования интерфейсов, соответствующих международным, национальным и промышленным стандартам, так и за счет специальных решений. Для СУБД это качество означает следующее:
Первое достигается использованием шлюзов, второе - использованием интерфейсов ODBC (Open Database Connectivity) и BDE (Borland Database Engine). Современные информационные системы требуют доступа к разнородным базам данных. Это означает, что в прикладной программе для реализации запросов к базам данных должны быть использованы такие средства, чтобы запросы были понятны различным СУБД, как реляционным, так и опирающимся на другие модели данных. Одним из возможных путей является обобщенный набор различных диалектов языка SQL. Существует альтернатива технологии распределенных БД - тиражирование данных. Принципиальное отличие технологии тиражирования данных от технологии распределенных баз данных (которую часто для краткости называют технологией STAR) заключается в отказе от распределенных данных. Ее суть состоит в том, что любая БД (как для СУБД, так и для работающих с ней пользователей) всегда является локальной; данные всегда размещаются локально на том узле сети, где они обрабатываются; все транзакции в системе завершаются локально. Тиражирование данных - это асинхронный перенос изменений объектов исходной базы данных (source database) в БД, принадлежащие различным узлам распределенной системы. Функции тиражирования данных выполняет специальный модуль СУБД - сервер тиражирования данных, называемый репликатором (replicator). Его задача - поддержка идентичности данных в принимающих базах данных (target database) данным в исходной БД. Сигналом для запуска репликатора служит срабатывание триггера, перехватывающего любые изменения тиражируемого объекта БД. Возможно и программное управление репликатором посредством сигнализаторов о событиях в базе данных. В качестве базиса для тиражирования выступает транзакция к БД. В то же время возможен перенос изменений группами транзакций, периодически или в некоторый момент времени, что дает возможность исследовать состояние принимающей БД на определенный момент времени. Детали тиражирования данных полностью скрыты от прикладной программы; ее функционирование никак не зависит от работы репликатора, который целиком находится в ведении администратора БД. Следовательно, для переноса программы в распределенную среду с тиражируемыми данными не требуется ее модифицировать. Особенность технологии распределенных БД - синхронное завершение транзакций одновременно на нескольких узлах распределенной системы, то есть синхронная фиксация изменений в распределенной БД. Недостаток технологии STAR - жесткие требования к производительности и надежности каналов связи. Если БД распределена по нескольким территориально удаленным узлам, объединенным медленными и ненадежными каналами связи, а число одновременно работающих пользователей составляет десятки и выше, то вероятность того, что распределенная транзакция будет зафиксирована в обозримом временном интервале, становится чрезвычайно малой. В таких условиях обработка распределенных данных практически невозможна. Реальной альтернативой технологии STAR является технология тиражирования данных, не требующая синхронной фиксации изменений. В действительности далеко не во всех задачах требуется обеспечение идентичности БД на различных узлах в любое время. Достаточно поддерживать тождественность данных лишь в определенные критичные моменты времени. Следовательно, можно накапливать изменения в данных в виде транзакций в одном узле и периодически копировать эти изменения на другие узлы. Преимущества технологии тиражирования данных:
Технология тиражирования данных имеет и недостатки, вытекающие из ее специфики. Например, невозможно полностью исключить конфликты между двумя версиями одной и той же записи. Они могут возникнуть, когда вследствие асинхронности передачи данных два пользователя на разных узлах исправят одну и ту же запись в тот момент, пока изменения в данных из первой базы данных еще не были перенесены во вторую. Следовательно, при проектировании распределенной среды с использованием технологии тиражирования данных необходимо предусмотреть конфликтные ситуации и запрограммировать репликатор на какой-либо вариант их разрешения. |