практическая реализация построения распределенной

ПРАКТИЧЕСКАЯ РЕАЛИЗАЦИЯ ПОСТРОЕНИЯ РАСПРЕДЕЛЕННОЙ НЕОДНОРОДНОЙ
БАЗЫ ДАННЫХ
Н.А.Лашкин, В.Г.Орчиков
Государственный НИИ информационных технологий и телекоммуникаций, Москва
Тел.: (095) 237-57-73, e-mail: valera@informika.ru
В данной работе рассматриваются возможности построения распределённой SQL базы данных на основе СУБД
различных производителей.
Основные требования, предъявляемые к распределённым базам данных можно сформулировать следующим
образом:
Прозрачность. При использовании для построения распределённой базы данных СУБД разных производителей,
необходимо, чтобы различия в этих СУБД не были видны ни пользователю, ни самим базам данных.
Целостность данных. Для обеспечения целостности данных в распределенной среде требуется поддержка
распределенной транзакции или распределенного запроса.
Распределенная обработка. Распределенные СУБД должны поддерживать не только удаленный запрос,
удаленную транзакцию и распределенную транзакцию, но также и распределенный запрос.
Асинхронное дублирование. Обеспечивает возможность передачи изменённых данных без издержек двухфазной
фиксации.
Фрагментация. Предоставляет возможность разбивать таблицу на подмножества строк или столбцов и физически
размещать их на различных серверах.
Дублирование. Обеспечивает возможность поддерживать набор различных физических копий таблицы,
синхронность которых автоматически обеспечивается СУБД независимо от их физического расположения. Не следует
путать его с асинхронным дублированием.
Оптимизация и выполнение распределенного запроса. При поддержке СУБД операций чтения, записи и
чтения/записи данных, расположенных в разных местах, оптимизация становится намного более сложной, чем при
выполнении таких операций в одном месте.
Средства администрирования и защиты. В общем случае средства резервного копирования, восстановления и
защиты необходимы для обеспечения глобальной согласованности базы данных, а также для облегчения системного
администрирования.
Возможности взаимодействия. Программное обеспечение СУБД должно выполнять свои функции всегда
одинаково в независимости от того, какие аппаратные средства, операционные системы и сети используются для
создания распределённой среды.
Для выполнения всех этих минимально необходимых требований построения распределённой базы данных,
фирмы-производители используют ряд возможностей, основная из которых, заключается в использовании
единообразного доступа к различным СУБД-продуктам. Возможность взаимодействия обеспечивается наборов таких
общих стандартов, как: ANSI SQL, Relational Database Architecture компании X/Open, Distributed Computing Environment,
разработанного Open Software Foundation, а также собственных стандартов фирм-производителей, например Glue
компании Oracle, Distributed Relational Database Architecture корпорации IBM. Но, как правило, СУБД не поддерживают
специфические расширения синтаксиса или набора форматов конкретных продуктов, ограничиваясь набором,
минимально необходимым для обеспечения взаимодействия.
Для достижения тех же целей используется шлюзовая технология таких компаний, как ASK Group, Oracle и Sybase,
которая обеспечивает взаимодействие за счет трансляции синтаксиса, форматов и протоколов между различными
СУБД. Однако даже продукты, использующие шлюзовую технологию, не обеспечивают полноты взаимодействия. Они
не поддерживают все конструкции SQL и типы данных, и более того, не всегда справляются с различиями в средствах
обнаружения и исправления ошибок.
Когда же возникает потребность в создании распределённой базы данных? На современных крупномасштабных
предприятиях данные могут храниться на нескольких серверах, и в этом случае поддержание актуальности данных на
всех этих серверах и их синхронизация становится задачей более сложной, чем простое копирование данных. Поэтому
примерно в 1996-1997 годах большинством основных компаний, производящих СУБД (таких как Oracle, Microsoft,
Informix), было представлено несколько решений относительно распределённых баз данных. Многие компании, не
связанные напрямую с рынком СУБД, также предложили альтернативные методы репликации.
Однако стандартные средства не всегда позволяют достичь желаемого результата конкретному разработчику.
Более того, в ряде случаев применение стандартных средств невыгодно. Например, в тех случаях, когда
распределённая база данных является достаточно простой, затраты на покупку дорогостоящего ПО, скорее всего, не
окупятся. Существуют также ситуации, когда на одном из предполагаемых серверов будущей распределённой
структуры база данных уже сформирована и занесена вся информация, а на других серверах только начинается
строительство БД, причём с несколько отличным набором таблиц и связей, а иногда и на другой платформе. В этом
случае использование стандартных средств может очень загромоздить систему, понизить её функциональность и
отказоустойчивость и усложнить администрирование. И, наконец, наиболее сложный случай, когда база данных
являются неоднородной. Например, для Oracle 8 и MS SQL 7, для организации репликации можно воспользоваться
штатными средствами СУБД (например, возможностью Microsoft SQL Server передавать данные ODBC агентам), но и в
этом случае могут возникнуть сложности, описанные выше. Если же возникает необходимость связать такие базы
данных, как, например, PostgreSQL и Progress, обойтись стандартным методом, становится и вовсе невозможным.
Следует также отметить, что Microsoft не поставляет ODBC драйверы под UNIX-платформы для работы с Microsoft
SQL Server. Для решения этой проблемы существуют несколько способов. Можно использовать продукты сторонних
фирм, такие как ODBC-ODBC Bridge фирмы Easysoft, который представляет собой набор библиотек и оригинальных
1
программ, позволяющих организовать доступ к ODBC драйверу на платформе Windows. Также можно использовать
доступ по протоколу TDS непосредственно к Microsoft SQL Server, минуя ODBC драйвер. В среде UNIX используется
набор библиотек FreeTDS, позволяющий осуществлять доступ к данным из CGI программ. Этот способ, на сегодняшний
день, наиболее удобен для практического использования, учитывая доступность библиотек FreeTDS.
Проанализировав существующую ситуацию и поняв, что на первом этапе построения распределённой базы данных
разработчик должен чётко уложить в существующие ограничения, накладываемые СУБД, свой проект, в нашей
организации была предпринята попытка написания программного обеспечения, позволившего бы передавать данные
между серверами независимо от того, какая именно СУБД установлена (или будет установлена на будущих узлах),
какой сценарий репликации необходимо использовать, и на какой платформе работают СУБД.
При построении репликации базовыми вариантами SQL-серверов были приняты Microsoft SQL Server 7, Oracle 8i и
Postgre SQL 6,5. При разработке средств репликации наряду с решением задачи собственно репликации необходимо
было обеспечить, по возможности, независимость от платформы, на которой работает конкретная БД и также от типа
БД. Для обеспечения переносимости был выбран язык программирования С с соответствующими библиотеками,
обеспечивающими связь с ODBC драйверами.
В процессе разработки ПО было использовано два подхода к процессу репликации. На первом этапе был
разработан метод, обеспечивающий оперативное изменение базы данных, подлежащей репликации. При занесении
информации в БД издателя, соответствующий SQL запрос дублировался в специальном файле, который пересылался
автоматически по ftp или e-mail на соответствующий сервер, где, опять же автоматически, данные из этого файла
заносились в реплицируемые таблицы базы данных. Тестирование системы показало её работоспособность, но данная
схема недостаточно защищена от потери информации: потеря даже одного SQL запроса приводит к потере или
недостоверности значительного массива информации в БД-приемнике. Но, если обеспечить проверку непрерывности
потока SQL запросов и сохранять какое-то количество SQL запросов на передающей стороне в буфере для повторной
посылки потерянного, то такая схема вполне конкурентоспособна. Еще одним недостатком данной схемы является
необходимость использования для занесения информации в БД только специально написанных скриптов, работающих
как с БД, так и с информационным каналом (файл, ftp, e-mail). Любые другие способы занесения информации в БД,
включая и стандартные (на пример Query Analyzer в MS SQL Server) приводят к потере информации.
На следующем этапе сценарий репликации был коренным образом изменён. Был осуществлен переход к так
называемой репликации снимком (snapshot). Теперь в определенные моменты времени производится считывание
данных из всей базы данных публикующего сервера или отдельных его таблиц. Полученная информация сохраняется в
буфере (специально созданном на жестком диске временном файле), а затем сравнивается с аналогичной в БДподписчике, и при необходимости недостающая информация добавляется в БД-подписчик, т.е. производится
дополнение БД-подписчика до состояния БД-издателя на момент репликации. Процесс репликации в этом случае
менее подвержен сбоям, так как даже если по каким-то причинам произошёл сбой в работе системы и сеанс
репликации не был завершен, то происходит откат, и после восстановления работоспособности системы, репликация
автоматически продолжается или производится повторно без негативных последствий для всей системы в целом.
В данный момент система находится на этапе доработки и параллельно ведётся её тестирование. По уже
имеющимся результатам тестирования предполагается увеличить количество типов данных, с которыми может
работать программа, обеспечить большую гибкость настройки с целью учета особенностей конкретных СУБД, а также,
рассмотреть вопросы обеспечения защиты передаваемой информации от несанкционированного доступа при передаче
данных по открытому каналу связи.
2