CC BY
121
МЕЖДУНАРОДНЫЙ НАУЧНЫЙ ЖУРНАЛ «СИМВОЛ НАУКИ» № 03-2/2017 ISSN 2410-700Х
Германской компании geo-Fennel, французской Agatec, японских компаний Topcon и Sokkia, американской Trimble/Spectra precision и CST Berger, швейцарской Leica Geosystems и других [1, с. 202]. Список использованной литературы:
1. Дементьев В.Е. Современная геодезическая техника и ее применение. Издательство «Академический проект». 2008. 591 с.
2. Киселев М.И., Михилев Д.Ш. Геодезия. Издательство «Издательский центр». 2004. 384 с.
3.Литвинов В.А., Лобачев В.М., Воронков Н.М. Геодезическое инструментоведение. Издательство «Недра». 1971. 328 с.
© Шамсиахметова Л.И., 2017
УДК 681.3
Шаталова Юлия Георгиевна
к.т.н., доцент СевГУ, г. Севастополь, РФ E-mail: [email protected] Жиглов Ярослав Владимирович бакалавр СевГУ, г. Севастополь, РФ
РАЗРАБОТКА СИСТЕМЫ РЕПЛИКАЦИИ ДЛЯ РАСПРЕДЕЛЕННОЙ БАЗЫ ДАННЫХ ПРЕДПРИЯТИЯ
Аннотация
В статье рассматривается проблема репликации в распределенных базах данных, проводится анализ имеющихся методов. Описывается разработка собственного метода репликации, основанного на использовании транзакций. Алгоритм реализован и применен для распределенной базы данных автосалона.
Ключевые слова Распределенная база данных, репликация, синхронизация, транзакция.
Благодаря высокому уровню развития современных информационных технологий и вычислительной техники, применение информационных систем стало повсеместным. Каждое уважающее себя предприятие имеет собственные информационные системы различного уровня: от рекламных сайтов до экспертных систем профессионального назначения. В основе большинства информационных систем лежат предметные базы данных.
Информация предприятия, как правило, носит распределенный характер: каждый филиал или отдел создает и обрабатывает свои собственные локальные данные, относящиеся только к его деятельности, но может воспользоваться и данными других филиалов или центрального офиса. Поэтому для предприятия разрабатывается распределенная база данных. В распределенной базе данных (РБД) возникает проблема доступа к данным и своевременного обновления всех данных организации. Проблема доступа к локальным данным решается с использованием технологии репликации баз данных. Данная технология позволяет распространять копии (реплики) части или всей информации, находящейся в одном узле базы данных, на другие узлы базы данных. Репликация тесно связана с проблемой синхронизации данных, т.е. обновления должны быть четко структурированы во времени для обеспечения главного требования к базам данных -актуальности. Следовательно, каждая распределенная база данных должна поддерживаться системой репликации.
В силу сказанного, проблема создания системы репликации для распределенной базы данных
_МЕЖДУНАРОДНЫЙ НАУЧНЫЙ ЖУРНАЛ «СИМВОЛ НАУКИ» № 03-2/2017 ISSN 2410-700Х_
конкретного предприятия является актуальной.
В данной статье приводится исследование методов репликации для распределенной базы данных, и описывается разработанный на основе этого исследования программный комплекс, реализующий систему репликации для базы данных автосалона.
Разработка распределенной базы данных автосалона выходит за рамки данной статьи, поэтому приведем только концептуальную схему построенной базы данных. Концептуальная схема автосалона приведена на рисунке 1.
Рассмотрим классификацию методов репликации по двум, наиболее важным для нашей разработки критериям [1].
1. По времени проведения сеанса репликации:
1.1. Синхронная - обновление данных на других узлах происходит в одной транзакции (репликация реального времени).
1.2. Асинхронная - обновленные данные распространяются на другие узлы спустя некоторое время, а не в той же транзакции (отложенная репликация). При использовании асинхронной репликации вводится временная задержка, в течение которой данные не синхронизированы.
2. По направлению проведения:
2.1. Однонаправленная - данные изменяются только в узлах-источниках, а в узлах-приемниках эти данные только хранятся и не подвергаются изменениям.
2.2. Мультинаправленная - данные могут изменяться на всех узлах системы.
Рисунок 1 - Концептуальная схема базы данных автосалона
_МЕЖДУНАРОДНЫЙ НАУЧНЫЙ ЖУРНАЛ «СИМВОЛ НАУКИ» № 03-2/2017 ISSN 2410-700Х_
Разрабатываемая система репликации данных должна удовлетворять следующему набору требований
[2]:
- система должна отслеживать любые изменения в базе данных;
- система должна быть эффективной, легко масштабируемой и иметь прогнозируемые затраты при расширении;
- система должна быть автономной;
- система должна одинаково хорошо функционировать на совершенно разных платформах.
Проанализируем известные методы репликации для выбора наиболее целесообразного метода для
реализации в рассматриваемой системе.
1). Полная передача таблиц. Таблица передается целиком уже во время сеанса репликации. Метод может применяться только для систем, в которых узлы связаны очень быстрым каналом передачи данных. Использование метода приводит к неэффективному использованию ресурсов. Время между появлением новых данных и их распространением может измеряться часами и более длительными периодами. Этот подход обеспечивает однонаправленную репликацию без своевременного удаленного обновления.
2). Использование распределенных транзакций (распределение с двухфазной фиксацией). В данном случае механизм базы данных передает информацию на серверы назначения в ходе каждой транзакции. Это значительно увеличивает время выполнения транзакций, что делает данный подход неприменимым для задач с высокими требованиями ко времени выполнения.
3). Репликация снимков. В определенные моменты времени делаются снимки базы данных, которые затем загружаются в один или более серверов-приемников. При этом получатели работают с относительно устаревшими данными, что делает данный подход неприемлемым в случаях, когда требуется информация в реальном времени. Кроме того, этот способ не обеспечивает удаленного обновления.
4). Использование триггеров без транзакций. Триггер копирует данные в один или несколько удаленных приемников, при этом механизм транзакций, гарантирующий успешную доставку, не применяется. Хотя накладные расходы при этом сокращаются, легко может возникнуть ситуация рассинхронизации базы данных, что может привести к потере информации.
5). Использование триггеров с транзакциями. Транзакции являются испытанным методом обеспечения целостности при модификации данных, их использование повышает надежность триггерной репликации. Платой за обеспечение целостности является снижение быстродействия приложений, обусловленное накладными расходами на исполнение транзакций [3].
6). Репликация на основе журнала. При журнальной репликации выполняется непосредственное чтение онлайновых журналов транзакций, что экономит ресурсы и не замедляет работу базы данных. Этот способ наиболее эффективен и экономичен.
Проведенный анализ методов репликации позволяет сделать вывод о том, что, для рассматриваемой базы данных применять только один из них неэффективно. Это связано с разносторонностью выполняемых задач, требующих разное количество ресурсов и времени. Поэтому для данной РБД требуется разработать новый алгоритм репликации: алгоритм репликации на основе использования транзакций. Использование транзакций при сеансе репликации позволяет выполнить откат базы данных при сбое, что обеспечивает целостность и нерушимость данных.
При разработке алгоритма репликации необходимо разрешить следующие проблемы: 1) обнаружение изменений; 2) распространение копий; 3) несколько источников и один приемник; 4) синхронизация уникальных идентификаторов.
Согласно иерархии базы данных в ней имеется два уровня: центральный узел РБД и удаленные узлы РБД [4]. Центральный узел решает задачи обработки новых заказов, распространения информации о поставках, хранения копии данных удаленных узлов. В задачу удаленных узлов входит прием данных о новых поставках, отправка на центральный узел новых заказов и копий обновленных данных. Согласно принципу прозрачности [4], обмен информацией между узлами должен проходить независимо от пользователя.
Удаленные узлы распределенной системы хранят информацию об автомобилях, которые находятся в
_МЕЖДУНАРОДНЫЙ НАУЧНЫЙ ЖУРНАЛ «СИМВОЛ НАУКИ» № 03-2/2017 ISSN 2410-700Х_
том или ином салоне. Автомобили могут перевозиться между салонами. Поэтому возникают высокие требования к синхронизации информации на узлах РБД. В таком случае для взаимодействия узлов целесообразно использовать синхронную репликацию или репликацию реального времени. Синхронизация данных происходит во время выполнения одной транзакции, и если во время выполнения транзакции произошел сбой, то выполняется откат базы данных.
Центральный узел работает с информацией, обновление которой происходит реже, поэтому использование репликации реального времени в этом случае нецелесообразно. Для репликации и синхронизации данных между центральным узлом и удаленными узлами используется асинхронная репликация, которая выполняется через заданные промежутки времени.
Рассмотрим особенности процесса репликации между центральным узлом и удаленными узлами. Сеанс репликации включает выполнение следующих задач: распространение информации о новых поставках на удаленные узлы; сбор информации о новых заказах от удаленных узлов; обновление копии данных с удаленных узлов.
Реализуемая в алгоритме репликация должна быть мультинаправленной, поскольку обмен информацией происходит в обе стороны. Чтобы организовать обнаружение изменений в отношениях, введем атрибут с именем status в каждое отношение, при этом status будет недоступен для пользователей базы данных, а администратору базы данных доступен только в режиме чтения. Атрибут status может принимать одно из четырех значений: 1) new - если текущая запись новая; 2) upd - если текущая запись подвергалась изменению; 3) del - если текущая должна быть удалена; 4) old - если текущая запись без изменений.
В сеансе репликации имеется два типа транзакций: 1) транзакция на выборку данных; 2) транзакция на распространение данных и изменение статуса.
Транзакция на выборку данных выполняется одинаково при передачи данных от центрального узла к удаленным, и наоборот. Транзакция на распространение данных и изменение статуса зависит от направления передачи данных. Если передача данных ведется от центрального узла к удаленным узлам, то подтверждение транзакции осуществляется, когда очередной набор данных с одинаковым статусом успешно распространен на все удаленные узлы и выполнено изменение статуса на центральном узле. При передаче данных от удаленных узлов, подтверждение транзакции осуществляется, когда копия данных с определенным статусом сохранена на центральном узле и выполнено изменение статуса на удаленном узле.
Перед выполнением транзакции на распространение данных выполняется анализ отношений, создаются копии записей с одинаковым статусом. После получения копии данных выполняется транзакция на распространение данных.
Обращение сразу нескольких удаленных узлов к центральному узлу может вызвать сбой в работе сеанса репликации (проблема нескольких источников информации). Проблема решается следующим образом: сеанс репликации запускается не на удаленных узлах, а на центральном узле. Это позволяет исключить ситуацию, когда несколько узлов запрашивают одну информацию или, когда несколько узлов записывают информацию в один участок. Обмен данными между центральным узлом и удаленными узлами происходит по очереди, соответствующей хронологическому порядку обращения узла.
При записи в одно отношение информации из нескольких отношений возникает проблема синхронизации уникальных идентификаторов. Данная проблема решается путем генерации уникальных идентификаторов. В проектируемой системе каждый идентификатор записи в отношениях имеет префикс с кодом автосалона. Использование префикса позволяет исключить совпадение идентификаторов при объединении двух и более отношений.
Приведем полностью разработанный алгоритм репликации. Он включает следующие шаги.
1. Проверка подключений к базам данных, если подключение хотя бы к одной базе не удалось, переход
к п.17.
2. Выборка данных о поставках со статусом new на центральном узле.
3. Выполнение транзакции распространения данных на удаленные узлы. Если произошел сбой, откат базы данных и переход к п.17.
4. Выборка данных о поставках со статусом upd на центральном узле.
_МЕЖДУНАРОДНЫЙ НАУЧНЫЙ ЖУРНАЛ «СИМВОЛ НАУКИ» № 03-2/2017 ISSN 2410-700Х_
5. Выполнение транзакции распространения данных на удаленные узлы. Если произошел сбой, откат базы данных и переход к п.17.
6. Выборка данных о поставках со статусом del на центральном узле.
7. Выполнение транзакции, включающей физическое удаление соответствующих поставок на удаленных узлах и на центральном узле. Если произошел сбой, откат базы данных и переход к п.17.
8. Распространение данных с очередного удаленного узла базы данных.
9. Выборка данных со статусом new из очередной необработанной таблицы.
10.Выполнение транзакции распространения данных на центральный узел. Если произошел сбой, откат базы данных и переход к п.17.
11. Выборка данных со статусом upd из очередной необработанной таблицы.
12.Выполнение транзакции распространения данных на центральный узел. Если произошел сбой, откат базы данных и переход к п.17.
13.Выборка данных со статусом del из очередной необработанной таблицы.
14.Выполнение транзакции, включающей физическое удаление соответствующих данных на удаленных узлах и на центральном узле. Если произошел сбой, откат базы данных и переход к п.17
15.Если остались необработанные таблицы, переход к п.9.
16.Если остались необработанные узлы, переход к п.8.
17. Конец.
Система репликации, основанная на предложенном алгоритме, вошла в разработанный программный комплекс «AutoShow». Комплекс состоит из 2 приложений: приложение репликации «Replication» и web-приложение для администратора базы данных «Admin». Исходным языком программирования для «AutoShow» является Java. При разработке web-приложения дополнительно использовался язык HTML и библиотека тэгов JSP JSTL.
Приложение «Replication» выполняет следующие функции: 1) проверку возможности подключения к локальным базам данных; 2) подключение к локальным базам данных; 3) репликацию данных; 4) синхронизацию данных;
5) откат базы данных в результате сбоя; 6) изменение статуса хранимых данных.
Реализованные функции приложения «Replication» обеспечивают своевременную синхронизацию данных на узлах, резервируемость данных и поддерживают целостность данных.
Web-приложение «Admin» предоставляет администратору базы данных инструменты для работы с локальной базой данных.
Выводы. Проведенный анализ известных методов репликации показал, что для реализации репликации в РБД автосалона не подходит ни один из рассмотренных, поэтому был разработан и реализован собственный алгоритм репликации. Также был разработан программный комплекс, состоящий из приложения, выполняющего репликацию и синхронизацию распределенной базы данных автосалона, и web-приложения администратора базы данных. Разработанная система удовлетворяет всем приведенным выше требованиям к системам репликации, за исключением требования платформонезависимости. В дальнейшей работе предполагается устранить этот недостаток.
Список использованной литературы:
1. Рябков Н.С. Аналитический анализ обзор методов репликации и синхронизации баз данных / Н.С. Рябков //Информационные технологии в менеджмент качество и инновационном менеджменте. - 2006. - № 6. - С. 56-63
2. Репликация баз данных // Тех. документ. Sybase, 2010. - 12 c.
3. Кузнецов С.Д. Основы баз данных: учебное пособие, 2-е издание. - М.: Интернет-Университет Информационных Технологий; БИНОМ. Лаборатория знаний, 2007. - 484 с.
4. К. Дж. Дейт Введение в системы баз данных, 8-е издание.: Пер. с англ. - М.: Издательский дом «Вильямс», 2005. — 1328 с.
© Шаталова Ю. Г., Жиглов Я. В., 2017
