Распределенные информационные системы и базы данных

Прозрачность сетиДоступ к любым базам данных может осуществляться по сети. Спектр поддерживаемых конкретной СУБД сетевых протоколов не должен быть ограничением системы с распределенными базами данных. Данное качество формулируется максимально широко - в распределенной системе возможны любые сетевые протоколы. Независимость от баз данныхЭто качество означает, что в распределенной системе могут мирно сосуществовать СУБД различных производителей, и возможны операции поиска и обновления в базах данных различных моделей и форматов.Исходя из определения Дэйта, можно рассматривать ddb как слабосвязанную сетевую структуру, узлы которой представляют собой локальные базы данных. Локальные базы данных автономны, независимы и самоопределены; доступ к ним обеспечиваются СУБД, в общем случае от различных поставщиков. Связи между узлами - это потоки тиражируемых данных. Топология ddb варьируется в широком диапазоне - возможны варианты иерархии, структур типа "звезда" и т.д. В целом топология ddb определяется географией информационной системы и направленностью потоков тиражирования данных. Посмотрим, во что выливается некоторые наиболее важные свойства ddb, если рассматривать их практически. 1.2. Целостность данных В ddb поддержка целостности и согласованности данных, ввиду свойств 1-2, представляет собой сложную проблему. Ее решение - синхронное и согласованное изменение данных в нескольких локальных базах данных, составляющих ddb - достигается применением протокола двухфазной фиксации транзакций. Если ddb однородна - то есть на всех узлах данные хранятся в формате одной базы и на всех узлах функционирует одна и та же СУБД, то используется механизм двухфазной фиксации транзакций данной СУБД. В случае же неоднородности ddb для обеспечения согласованных изменений в нескольких базах данных используют менеджеры распределенных транзакций. Это, однако, возможно, если участники обработки распределенной транзакции - СУБД, функционирующие на узлах системы, поддерживают xa-интерфейс, определенный в спецификации dtp консорциума x/open. В настоящее время xa-интерфейс имеют ca-openingres, informix, microsoft sql server, oracle, sybase. Если в ddb предусмотрено тиражирование данных, то это сразу предъявляет дополнительные жесткие требования к дисциплине поддержки целостности данных на узлах, куда направлены потоки тиражируемых данных. Проблема в том, что изменения в данных инициируются как локально - на данном узле - так и извне, посредством тиражирования. Неизбежно возникают конфликты по изменениям, которые необходимо отслеживать и разрешать. 1.3. Прозрачность расположения Это качество ddb в реальных продуктах должно поддерживаться соответствующими механизмами. Разработчики СУБД придерживаются различных подходов. Рассмотрим пример из oracle. Допустим, что ddb включает локальную базу данных, которая размещена на узле в Лондоне. Создадим вначале ссылку (database link), связав ее с символическим именем (london_unix), транслируемым в ip-адрес узла в Лондоне. create public database link london.com connect to london_unix using oracle_user_id; Теперь мы можем явно обращаться к базе данных на этом узле, запрашивая, например, в операторе select таблицу, хранящуюся в этой базе: select customer.cust_name, order.order_date from customer@london.com, order where customer.cust_number = order.cust_number; Очевидно, однако, что мы написали запрос, зависящий от расположения базы данных, поскольку явно использовали в нем ссылку. Определим customer и customer@london.com как синонимы: create synonym customer for customer@london.com; и в результате можем написать полностью независимый от расположения базы данных запрос: select customer.cust_name, order.order_date from customer, order where customer.cust_number = order.cust_number Задача решается с помощью оператора sql create synonym, который позволяет создавать новые имена для существующих таблиц. При этом оказывается возможным обращаться к другим базам данных и к другим компьютерам. Так, запись в СУБД informix create synonym customer for client@central:smith.customer означает, что любое обращение к таблице customer в открытой базе данных будет автоматически переадресовано на компьютер central в базу данных client к таблице customer. Оказывается возможным переместить таблицу из одной базы данных в другую, оставив в первой базе ссылку на ее новое местонахождение, при этом все необходимые действия для доступа к содержимому таблицы будут сделаны автоматически.Мы уже говорили выше о горизонтальной фрагментации. Рассмотрим пример иерархически организованной ddb, на каждом из узлов которой содержится некоторое подмножество записей таблицы customer: С помощью create synonym можно определить, например, таблицу структуры customer, в которой хранятся строки с записями о клиентах компании, находящихся в Японии: create synonym japan_customer for customer@hq.sales.asia.japanВо многих СУБД задача управления именами объектов ddb решается путем использования глобального словаря данных, хранящего информацию о ddb: расположение данных, возможности других СУБД (если используются шлюзы), сведения о скорости передачи по сети с различной топологией и т.д. 1.4. Обработка распределенных запросов Выше уже упоминалось это качество ddb. Обработка распределенных запросов (distributed query -dq) - задача, более сложная, нежели обработка локальных и она требует интеллектуального решения с помощью особого компонента - оптимизатора dq. Обратимся к базе данных, распределенной по двум узлам сети. Таблица detail хранится на одном узле, таблица supplier - на другом. Размер первой таблицы - 10000 строк, размер второй - 100 строк (множество деталей поставляется небольшим числом поставщиков). Допустим, что выполняется запрос: select detail_name, supplier_name, supplier_address from detail, supplier where detail.supplier_number = supplier.supplier_number; Результирующая таблица представляет собой объединение таблиц detail и supplier, выполненное по столбцу detail.supplier_number (внешний ключ) и supplier.supplier_number (первичный ключ).Данный запрос - распределенный, так как затрагивает таблицы, принадлежащие различным локальным базам данных. Для его нормального выполнения необходимо иметь обе исходные таблицы на одном узле. Следовательно, одна из таблиц должна быть передана по сети. Очевидно, что это должна быть таблица меньшего размера, то есть таблица supplier. Следовательно, оптимизатор dq запросов должен учитывать такие параметры, как, в первую очередь, размер таблиц, статистику распределения данных по узлам, объем данных, передаваемых между узлами, скорость коммуникационных линий, структуры хранения данных, соотношение производительности процессоров на разных узлах и т.д. От интеллекта оптимизатора dq впрямую зависит скорость выполнения распределенных запросов. 1.5. Межоперабельность В контексте ddb межоперабельность означает две вещи. Во-первых, - это качество, позволяющее обмениваться данными между базами данных различных поставщиков. Как, например, тиражировать данные из базы данных informix в oracle и наоборот? Известно, что штатные средства тиражирования в составе данной конкретной СУБД позволяют переносить данные в однородную базу. Так, средствами ca-ingres/replicator можно тиражировать данные только из ingres в ingres. Как быть в неоднородной ddb? Ответом стало появление продуктов, выполняющих тиражирование между разнородными базами данных.Во-вторых, это возможность некоторого унифицированного доступа к данным в ddb из приложения. Возможны как универсальные решения (стандарт odbc), так и специализированные подходы. Очевидный недостаток odbc - недоступность для приложения многих полезных механизмов каждой конкретной СУБД, поскольку они могут быть использованы в большинстве случаев только через расширения sql в диалекте языка данной СУБД, но в стандарте odbc эти расширения не поддерживаются. Специальные подходы - это, например, использование шлюзов, позволяющее приложениям оперировать над базами данных в "чужом" формате так, как будто это собственные базы данных. Вообще, цель шлюза - организация доступа к унаследованным (legacy) базам данных и служит для решения задач согласования форматов баз данных при переходе к какой-либо одной СУБД. Так, если компания долгое время работала на СУБД ims и затем решила перейти на oracle, то ей очевидно потребуется шлюз в ims. Следовательно, шлюзы можно рассматривать как средство, облегчающее миграцию, но не как универсальное средство межоперабельности в распределенной системе. Вообще, универсального рецепта решения задачи межоперабельности в этом контексте не существует - все определяется конкретной ситуацией, историей информационной системы и массой других факторов. ddb конструирует архитектор, имеющий в своем арсенале отработанные интеграционные средства, которых на рынке сейчас очень много.

Отправить комментарий

Проверка
Антиспам проверка
Image CAPTCHA
...