Главная Учебники - Разные Лекции (разные) - часть 18
поиск по сайту правообладателям
|
САНКТ-ПЕТЕРБУРГСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ Математико-механический факультет Кафедра системного программирования Наговицына Полина Александровна Создание сервиса синхронизации разнородных баз данных Допущена к защите зав. кафедрой: д.ф.м.н., профессор Терехов А.Н. Научный руководитель: доцент Графеева Н.Г. Рецензент: Санкт-Петербург 2008 Содержание 2.1 Характеристики баз данных. 4
2.2 Готовое программное обеспечение. 6
2.3 Способы синхронизации баз данных. 7
3. Описание приложения «SyncManager». 12
4. Практическая реализация приложения «SyncManager». 14
Со времени изобретения письменности перед человечеством стояла задача хранения данных. Поддержка записей имеет долгую историю и очень актуальна сегодня. C развитием IT-инфраструктуры увеличиваются объемы информации, которые необходимо хранить в базах данных. Масштабы их возрастают настолько, что зачастую требуется распределение нагрузки на несколько серверов. Использование Интернет сильно повысило значение и важность технологии БД. Как только ранние статические веб-страницы уступили дорогу динамическим, а большие организации начали использовать Интернет для публикации своих данных, все большее и большее информационное пространство стало зависеть от баз данных. Стало необходимым расширение возможностей одновременного доступа к данным нескольких пользователей. Основной проблемой распределенных систем является проблема поддержания синхронного состояния источников данных на разных узлах. Эту проблему призваны решать системы репликации. Репликация — это механизм синхронизации содержимого нескольких копий объекта, процесс, под которым понимается копирование данных из одного источника на множество других и наоборот. При репликации изменения, сделанные в любой из копий объекта, могут быть распространены во все копии. То, как система репликации производит выборку данных, подлежащих синхронизации, напрямую влияет на производительность системы. Репликация необходима, когда технические требования проекта информационной системы предполагают многократный поиск, вставку, обновление и удаление данных из разнородных источников. Например, при ведении бухгалтерского учета при помощи 1С, когда одна и та же таблица может содержаться в нескольких базах данных. Проблема синхронизации данных по нескольким источникам информации представляет собой довольно нетривиальную задачу с весьма неоднозначным решением. Как это ни странно, учитывая, что подобные проблемы возникают довольно часто, но универсального решения такой задачи на текущий момент практически нет. Почти все готовые репликаторы данных работают с существенными ограничениями по структуре и способам накопления и изменения данных в таблицах базы данных. Большинство производителей БД имеют собственные инструменты синхронизации. В основном это синхронизация по требованию (то есть не постоянный контроль различий между копиями данных) структур (но не содержимого) двух баз данных. Также существуют приложения, работающие с разнородными источниками, при этом производители БД конкретизированы, и возможности расширения списка синхронизируемых баз нет. Поэтому, когда возникла задача перманентной синхронизации нескольких элементов баз данных, одной из которых является Progress database, мы столкнулись с отсутствием в информационной сфере приемлемого решения. Необходимо написать приложение, обеспечивающее синхронизацию связанных между собой разнородных баз данных: Progress и другой произвольной базы. Так как процесс репликации разнородных данных очень индивидуален, и для каждой пары БД существует множество особенностей и зависимостей, проводить исследование необходимо на примере двух конкретных систем. Таким образом, необходимо: · изучить особенности синхронизируемых баз данных · изучив то, что уже существует в данной области, понять достоинства и недостатки · проанализировать все возможности и способы репликации, чтобы выбрать наиболее подходящий вариант · сформировать модель всего приложения, исходя из полученных данных и конкретизировать детали Рассматриваемы в данной работе базы данных имеют следующие характеристики: СУБД Progress
· БД большого объема (до 80 000 Тб) · Многопользовательский режим работы с данными · Возможность on-line администрирования для критических БД · Поддержка промышленных стандартов: o операционные системы o сетевые протоколы o пользовательские интерфейсы o SQL ANSI92, ODBC, JDBC · Переносимость приложений между платформами · Поддержка физической и логической целостности на уровне БД · Поддержка распределенных БД · Гибкие возможности по организации распределенной обработки данных: o клиент/сервер o N-уровневая архитектура o Web-архитектура СУБД
MySQL
MySQL — свободная система управления базами данных. MySQL является собственностью компании MySQL AB, осуществляющей разработку и поддержку приложения. Распространяется под GNU General Public License и под собственной коммерческой лицензией, на выбор. Помимо этого компания MySQL AB разрабатывает функциональность по заказу лицензионных пользователей, именно благодаря такому заказу почти в самых ранних версиях появился механизм репликации. MySQL является решением для малых и средних приложений. Обычно MySQL используется в качестве сервера, к которому обращаются локальные или удалённые клиенты, однако в дистрибутив входит библиотека внутреннего сервера, позволяющая включать MySQL в автономные программы. Гибкость СУБД MySQL обеспечивается поддержкой большого количества типов таблиц: пользователи могут выбрать как таблицы типа MyISAM, поддерживающие полнотекстовый поиск, так и таблицы InnoDB, поддерживающие транзакции на уровне отдельных записей. Более того, СУБД MySQL поставляется со специальным типом таблиц EXAMPLE, демонстрирующим принципы создания новых типов таблиц. Благодаря открытой архитектуре, в СУБД MySQL постоянно появляются новые типы таблиц. Несмотря на то, что версия 4.0
является устаревшей, она всё ещё имеет значительное распространение. Основные возможности этой версии: · Практически полная реализация ANSI SQL-99, плюс расширения · Межплатформенная совместимость · Независимые механизмы хранения (MyISAM для быстрого чтения, InnoDB для транзакций и ссылочной целостности) · Транзакции · Поддержка SSL · Кеширование запросов · Репликация: один головной сервер на одного подчинённого, много подчинённых на одного головного · Полнотекстовая индексация и поиск с использованием механизма MyISAM · Внедрённая библиотека базы данных · Поддержка Юникода (UTF-8) · Таблицы InnoDB обеспечивают соответствие требованиям ACID · Встроенный сервер, позволяющий включать MySQL в автономные приложения. В MySQL 5.0
значительно расширена функциональность, которая ставит MySQL в один ряд с коммерческими СУБД. Если раньше СУБД MySQL обвиняли в недостаточной поддержке стандарта SQL, то с появлением пятой версии этой популярной базы данных, появилась практически полная поддержка стандарта SQL. MySQL 5.0 содержит следующие нововведения: · хранимые процедуры и функции · обработчики ошибок · курсоры · триггеры · представления · информационная схема (так называемый системный словарь, содержащий метаданные)
Версия MySQL 5.1
продолжает путь к стандарту SQL2003. MySQL 5.1 содержит следующие нововведения: · планировщик заданий · сегментирование · изменено поведение ряда операторов, для обеспечения большей совместимости со стандартом SQL2003 · значительные изменения в работе MySQL Cluster, такие как, например, возможность хранения табличных данных на диске · row-based репликация · реализация парсера полнотекстового поиска в виде plug-in
Версия MySQL 6.0
пока находится в стадии альфа-тестирования. Первоначально было принято решение о создании версии 5.2, однако вскоре эта версия была переименована в 6.0. Одно из главнейших нововведений версии 6.0 — новый механизм хранения данных Falcon, разработанный компанией MySQL AB, в качестве потенциальной замены для InnoDB компании InnoBase, приобретённой компанией Oracle.
2.2 Готовое программное обеспечение
Многие производители баз данных имеют широкий ассортимент средств поддержки своих продуктов. Ниже приведен обзор инструментов для синхронизации баз данных Progress, MySQL, MSSQL. Progress® DataXtend™ RE (Replication Edition)
предоставляет инструменты синхронизации и репликации, которые делают приложения более мобильными и доступными для разработчиков как в режиме on-line, так и off-line. Progress® DataXtend® Semantic Integrator (SI) позволяет поставщикам коммуникационных услуг более эффективно синхронизировать свои разнородные распределенные данные благодаря новой функциональной возможности обнаружения изменений в данных (Сhange Data Capture, CDC), позволяющей определить момент, когда в базе данных произошло изменение данных. В настоящее время, Progress DataXtend Semantic Integrator 8.3 поддерживает в качестве источников данных базы данных Oracle. Следующие версии будут поддерживать базы данных других производителей. DBTyP.NET 2008
позволяет анализировать, сравнивать и синхронизировать и схему, и содержимое баз данных. Упрощает управление изменениями баз данных. Кросс-платформенные технологии, которые используются в DBTyP.NET, обеспечивают возможность работы с базами данных от разных производителей: SQL Server, Oracle, MySQL. Следующие версии должны поддерживать PostgreSQL, Informix, DB2 и другие. Приложение имеет 2 модуля: Database Schema Comparison и Database Data Comparison. DBSync
– набор продуктов для синхронизации конкретных пар разнородных баз данных. DBSync for Access & MySQL предоставляет возможность синхронизировать и конвертировать MS Access и MySQL базы данных путем несложного определения настроек в построенном по принципу Wizard приложении. Программа не только предоставляет возможность конвертировать данные, синхронизируя их, но и позволяет выбрать определенные таблицы для конвертации, задавать параметры работы приложения посредством командной строки и выбирать между возможностью копировать идентичные записи из исходной базы данных в назначенную, или же одинаковые записи не копировать. Пользователи также имеют возможность выбирать тип таблиц: MyISAM, HEAP, BDB или ISAM. Планировщик задач позволяет программировать компьютер для запуска определенных приложений в заданные сроки, что значительно облегчает распределение нагрузки и отслеживание выполнения запланированных задач. Другие имеющиеся приложения: DBSync for FoxPro & MSSQL DBSync for MS Access & MSSQL Итак, видно, что имеется большое количество хороших и удобных продуктов синхронизации баз данных. Но основным недостатком их является невозможность осуществлять перманентный контроль различий содержимого разнородных баз. Кроме того, в основном это средства либо для контроля данных между базами одного производителя, либо синхронизация схем разнородных баз. Очень мало продуктов предлагают возможность синхронизации данных от разнородных источников, это приложения для фиксированных пар баз данных, среди которых отсутствует реализация для Progress Database.
2.3 Способы синхронизации баз данных
Синхронизация данных
— это ликвидация различий между двумя копиями данных. Предполагается, что ранее эти копии были одинаковы, а затем одна из них, либо обе были независимо изменены. Репликация (англ. replication)
— механизм синхронизации содержимого нескольких копий объекта (например, содержимого базы данных). Репликация — это процесс, под которым понимается копирование данных из одного источника на множество других и наоборот. При репликации изменения, сделанные в любой из копий объекта, могут быть распространены во все копии. В зависимости от требований архитектуры информационной системы предприятия можно использовать различные схемы дублирования и размещения данных Репликацию можно классифицировать по нескольким характеристикам. 1. По направлению репликации.
Если данные изменяются только в одной из БД, а в другой данные только хранятся и не подвергаются изменениям, то такую репликацию будем называть однонаправленной
или односторонней
. Если же данные могут изменяться и вводиться на всех БД, то такой вид репликации будем называть мультинаправленной
или многосторонней
. 2. По времени проведения репликации относительно транзакций.
Синхронная репликация
В случае синхронной репликации, если данная реплика обновляется, все другие реплики того же фрагмента данных также должны быть обновлены в одной и той же транзакции. Логически это означает, что существует лишь одна версия данных. В большинстве продуктов синхронная репликация реализуется с помощью триггерных процедур (возможно, скрытых и управляемых системой). Но синхронная репликация имеет тот недостаток, что она создаёт дополнительную нагрузку при выполнении всех транзакций, в которых обновляются какие-либо реплики (кроме того, могут возникать проблемы, связанные с доступностью данных).
Aсинхронная репликация
В случае асинхронной репликации обновление одной реплики распространяется на другие спустя некоторое время, а не в той же транзакции. Таким образом, при асинхронной репликации вводится задержка, или время ожидания, в течение которого отдельные реплики могут быть фактически неидентичными (то есть определение репликации оказывается не совсем подходящим, поскольку мы не имеем дело с точными и своевременно созданными копиями). В большинстве продуктов асинхронная репликация реализуется посредством чтения журнала транзакций или постоянной очереди тех обновлений, которые подлежат распространению. Преимущество асинхронной репликации состоит в том, что дополнительные издержки репликации не связаны с транзакциями обновлений, которые могут иметь важное значение для функционирования всего предприятия и предъявлять высокие требования к производительности. К недостаткам этой схемы относится то, что данные могут оказаться несовместимыми (то есть несовместимыми с точки зрения пользователя). Иными словами, избыточность может проявляться на логическом уровне. Рассмотрим кратко проблему согласованности (или, скорее, несогласованности). Дело в том, что реплики могут становиться несовместимыми в результате ситуаций, которых трудно (или даже невозможно) избежать и последствия которых трудно исправить. В частности, конфликты могут возникать по поводу того, в каком порядке должны применяться обновления. Например, предположим, что в результате выполнения транзакции А происходит вставка строки в реплику X, после чего транзакция B удаляет эту строку, а также допустим, что Y — реплика X. Если обновления распространяются на Y, но вводятся в реплику Y в обратном порядке (например, из-за разных задержек при передаче), то транзакция B не находит в Y строку, подлежащую удалению, и не выполняет своё действие, после чего транзакция А вставляет эту строку! Суммарный эффект состоит в том, что реплика Y содержит указанную строку, а реплика X — нет. В целом задачи устранения конфликтных ситуаций и обеспечения согласованности реплик являются весьма сложными. Следует отметить, что, по крайней мере, в сообществе пользователей коммерческих баз данных термин репликация стал означать преимущественно (или даже исключительно) асинхронную репликацию. 3. По способу передачи информации во время процесса репликации.
Если соединение серверов, хранящих распределенные БД, происходит при помощи программы клиента, которая с одной стороны подсоединяется к своему серверу, а с другого конца имеет прямую связь с БД другого сервера и может подключиться напрямую к данным другого сервера, для прямого изменения и анализа реплицируемых данных с обеих концов, имея при этом гарантированный устойчивый канал связи (ADSL, выделенный канал, двупроводная линия Dial-Up и пр.), то такой вид синхронизации назовем прямым
. Если же канал неустойчивый и не гарантирует устойчивую связь без падений во время процесса синхронизации и данные приходится передавать цельными пачками, при этом принимающая сторона во время закачки и анализа данных не имеет немедленной возможности опросить источник при возникновении на ее взгляд сомнительных моментов, а решение "Что делать?" принимать в любом случае нужно, то такой вид синхронизации будем называть недетерминированной
или вероятностной
. 4. По способу анализа реплицируемой информации.
Репликация моментальных снимков (snapshot replication)
- это периодическая репликация целостного набора данных, зафиксированного по состоянию на определенный момент времени, с локального сервера на удаленные. Лучше использовать этот тип репликации в БД, где количество реплицируемых данных невелико, а источник данных статичен. Репликация моментальных снимков наиболее подходит для работы с не слишком интенсивно изменяемыми данными, для небольших объемов реплицируемой информации, которые могут обновляться полностью без существенного увеличения нагрузки на сеть, а также для данных, которые не нужно постоянно поддерживать в актуальном состоянии (допустим, архивные данные об объемах продаж предприятия). Репликация транзакций (transactional replication)
- это репликация начального моментального снимка данных на удаленные серверы, а также репликация отдельных транзакций, работающих на локальном сервере и выполняющих последовательные изменения данных в начальном моментальном снимке. Репликация сведением (merge replication) – это репликация начального моментального снимка данных на удаленные серверы, а также репликация изменений, происходящих на каком-либо удаленном сервере, обратно на локальный сервер с целью синхронизации, разрешения конфликтов и повторной репликации на удаленные серверы. Вы можете использовать репликацию сведением в случае, когда многочисленным изменениям подвергаются одни и те же данные, либо когда удаленные независимые компьютеры работают автономно, например, как в случае автономного пользователя. 5. По времени проведения сеанса репликации.
Если данные должны быть синхронизированы немедленно после изменений, то такую репликацию будем называть репликация реального времени
. Если же процесс репликации запускается по какому-либо событию во времени или по отмашке администратора БД, то такой вид репликации назовем отложенная репликация
. Репликация предоставляет следующие возможности: · автоматизированное и надежное перемещение изменений данных из одной системы в другую (позволяет автоматически вносить изменения при появлении их в источнике); · создание идентичных копий в двух системах (например, поддержка второй копии данных для их восстановления); · копирование подмножества данных из одной системы во многие (например, с целью синхронизации информации в разных системах). Такой вид репликации называется распределением данных; · копирование выбранных данных из многих источников в один (например, чтобы объединить информацию в информационное хранилище). Такой вид репликации называется консолидацией данных. C учетом введенных определений необходимо установить, какой тип репликации наиболее соответствует поставленной задаче. 1. В таких системах, как «1С бухгалтерия», изменения могут происходить на разных копиях БД. Поэтому репликация требуется мульти-направленная. 2. Так как целью работы является контроль данных в системах-справочниках (в которых к данным постоянно происходят обращения), то необходимо проводить репликацию в реальном времени, не исключая, однако, возможности отложенной репликации. 3. Чтобы не перегружать сервера, выбираем асинхронную репликацию. 4. Предположительно, объем обрабатываемых данных может быть велик, и эти данные нужно обновлять постоянно. При таких условиях удобно использовать репликацию транзакций. Сформируем модель приложения: Так как базы будут разнородные, но с идентичными схемами, контролировать придется только изменения данных. Причем синхронизировать будем отдельные таблицы. Следовательно, приложение должно иметь инструмент-сервис, регулярно выполняющий синхронизацию, и инструмент для отложенной синхронизации, который должен включать возможности выставления настроек подключения (host, port, username, password, database, table) для каждой базы данных. В каждой синхронизируемой базе должен быть лог транзакций (таблица, в которой при помощи триггерных процедур фиксируются все изменения).
3. Описание приложения «
SyncManager» Алгоритм работы приложения: 1. Administrative tool
Запускается вначале. Пользователь выставляет все необходимые настройки соединения с базами, данные которых необходимо синхронизировать: · Host · Port · Username · Password · Database · Table Настройки записываются в файл. На их основе автоматически формируются строки соединения, скрипты для создания триггеров. При помощи триггеров информация будет заноситься в логи транзакций таким образом, что в логе будет храниться уже сформированная команда для выполнения в той БД, в которой изменения еще не было. Так как базы разнородные, характеристики у них тоже разные. Соединение же устанавливается для всех по одной схеме, идентично создаются и триггеры, но с теми отличиями, которые определяются при выборе базы данных, участвующей в синхронизации. Отсюда происходит непосредственно запуск и остановка сервиса. Если по какой-то причине необходимо изменить настройки сервиса, то его можно остановить, изменить конфигурацию и запустить вновь. Также приложение позволяет осуществить синхронизация «по требовонию». 2. Synchronizing Service
Сервис регулярно (через довольно малые промежутки времени) обращается к логам транзакций синхронизируемых баз. Если в них зарегистрированы новые изменения, то сервис запускает выполнение команды из лога. При этом происходит проверка, не выполнялась ли уже данная команда, и, только исключив возможность дублирования данных, команда выполняется. Команды хранятся в логах в неком общем виде, и в зависимости от синхронизируемых баз данных, преобразуются в соответствии с диалектом SQL, приемлемым для конкретной БД. Трудности, с которыми пришлось столкнуться в ходе работы: 1) Отслеживание добавления/изменения/удаления данных в каждой копии данных. Если добавление/удаление можно достаточно надежно синхронизировать, то при модификации имеющихся данных возникает проблема "первородности" изменений, т.е. принятие решения о том, которое из изменений какого поля является наиболее объективным. Есть такой вариант обработки конфликтов: в логе транзакций фиксировать время изменения данных и считать более поздние изменения приоритетными. При попытке удаления несуществующей записи будет выдаваться сообщение о ее отсутствии, транзакция – откатываться. 2) Объективная модификация каких-либо счетчиков, например, счетчиков отгружаемой продукции. Поясняю - если в обеих копиях данных был организован декремент счетчика продукции на 1, при неизменности других полей записи, то в синхронизированной записи должен быть произведен окончательный декремент уже на 2. 3) Проблема возрастания сложности синхронизации между тремя и более копиями данных. 4) Необходимо исключать дублирование данных по логам. 5) Разные базы данных поддерживают разные диалекты языка SQL, что требует индивидуального подхода при формировании скриптов триггеров и запросов к синхронизируемым базам данных. Также это препятствует расширению системы на дополнительные виды баз данных, но, в силу относительной универсальности приложения, не исключает такой возможности.
4. Практическая реализация приложения «
SyncManager»
4.1
Administrative
Tool
Приложение выполнено на основе технологии Windows Forms (Microsoft Visual Studio .Net 2005) Приложение выполняет следующие действия: · Считывает настройки соединения, названия синхронизируемых таблиц · Заносит конфигурационные данные в файл в формате XML · Определяет структуру таблиц · Определяет первичный ключ · Создает таблицу, в которой будут фиксироваться все изменения · Создает триггеры на действия над данными · Запускает/останавливает сервис синхронизации · Запускает единовременную синхронизацию Настройка конфигурации Для установления соединения к разным базам требуется разная информация. При первом запуске форма имеет общий вид. В зависимости от типа БД, пользователь получает возможность указать необходимые характеристики соединения. · По нажатию кнопки «ОК» происходят следующие действия (для каждой базы данных): o Сериализация внесенных в форму данных o Считывание данных (тип базы данных, имя таблицы и характеристики соединения) из файла настроек o Формирование строк соединения o Генерация триггеров к данной таблице o Создание таблиц изменений (логов транзакций) · По нажатию кнопки «Start service» происходит запускается сервиса синхронизации Рассмотрим подробнее процесс создания триггеров. Три́ггер (англ. trigger) — это хранимая процедура особого типа, исполнение которой обусловлено наступлением определенного события. В данном случае при помощи специальных методов триггеры создаются на события внесения изменений в таблицы. Они имеют общий вид: BEGIN INSERT INTO _changes (cmd) VALUES (CONCAT('INSERT INTO table (id, field1, field2, field3) VALUES (', QUOTE(new.id), ', ', QUOTE(new.field1), ', ', QUOTE(new.field2), ', ', QUOTE(new.field3),')')); END _changes – лог транзакций базы. Имеет следующую структуру: Change_id command 1 ‘INSERT INTO table VALUES (val1, val2, val3)’ 2 ‘DELETE FROM table WHERE id = val1’ 3 ‘UPDATE table SET field1 = val1 WHERE id = val2’ В поле command записывается та команда, которая выполнилась в одной базе и должна выполниться в другой для синхронизации данных. Сервис будет регулярно обращаться к этой таблице и при наличии новых записей, выполнять команду из поля command. · По нажатию кнопки «Stop service» происходят следующие действия (для каждой базы данных). o Закрывается соединение с базой данных o Останавливается сервис синхронизации Приложение выполнено на основе технологии Windows Service (Microsoft Visual Studio .Net 2005) Это основной элемент приложения. · Получает все настройки файла · Регулярно обращается к базам данных, анализирует логи транзакций · Выполняет команды новых изменений в тех таблицах, где изменений еще не было
| |||||||||||||