Использование нереляционного подхода в распределенной системе баз данных

2. Блеканов, И.C. Тематический краулинг на основе алгоритма HITS [Текст] / И.С. Блеканов, Д.С. Бон-даренко // Научно-технические ведомости СПбГПУ. -2010. -№ 3 (101). -С. 111-118.

3. Печников, А.А. Вебометрические исследования Web-сайтов университетов России [Текст] / А.А. Печников // Информационные технологии. -2008. -№ 11. -С. 74-78.

4. Печников, А.А. Разработка инструментов для вебометрических исследований гиперссылок научных сайтов [Текст] / А.А. Печников, Н.Б. Луговая, Ю.В. Чуйко, И.Э. Косинец // Вычислительные технологии. -2009. -Т. 14. -№ 5. -С. 66-78.

5. Печников, А.А. Исследование связности научно-образовательного Веба [Текст] / А.А. Печников, А.В. Чирков, Ю.В. Чуйко // Ученые записки Петрозаводского государственного университета. Естественные и технические науки. -2011. -№ 8 (121). -С. 111-113.

6. Arasu, A. Searching the web [Text] / A. Arasu, J. Cho, H. Garcia-Molina [et al.] // ACM Transactions on Internet Technology. -Aug. 2001. -Vol. 1. -№ 1. -P. 2-43.

7. Bar-Ilan, J. How much information the search engines disclose on links to a web page? A case study of the

«Cybermetrics» home page [Text] / J. Bar-Ilan // Proc. VIII Intern. Conf. on Scientometrics and Informetrics. -2001. -Vol. 1. -P. 63-73.

8. Cho, J. The evolution of the web and implications for an incremental crawler [Text] / J. Cho, H. GarciaMolina // In Proc. of the XXVI Intern. Conf. on Very Large Databases. -CA, USA. -2000. -P. 200-209.

9. Mohr, G. Introduction to Heritrix: an open source archival quality web crawler [Text] / G. Mohr, M. Kimpton, M. Stack [et al.] // Proc. of the 4th International Web Archiving Workshop (IWAW'04). -Bath, UK. -2005. -P. 15.

10. Najork, M. High-Performance Web Crawling [Text] / M. Najork, A. Heydon. -MA, USA: Kluwer Academic Publishers, 2002. -P. 25-45.

11. Raghavan, S. Crawling the Hidden Web [Text] / S. Raghavan, H. Garcia-Molina. -San Francisco, CA, USA: Morgan Kaufmann Publishers Inc., 2001. -P. 129-138.

12. Sang, Ho Lee. On URL normalization [Text] / Lee Sang Ho, Sung Jin Kim, Seok Hoo Hong // Proc. of the Intern. Conf. on Computational Science and its Applications (ICCSA). -2005. -Vol. 2. -P. 1076-1085.

УДК 681.3

Ю.Н. Торган, Т.В. Зубрилина

использование нереляционного подхода

в распределенной системе баз данных

Резкое увеличение объемов данных привело к появлению новых тенденций в области систем хранения. Одна из популярных тенденций - использование NoSQL баз данных (БД). Названный термин подразумевает под собой ряд подходов, которые реализуют модели БД, имеющие существенные отличия от используемых в традиционных реляционных СУБД.

Для классических реляционных СУБД проблемой является работа с данными большого объема в проектах с высокой нагрузкой. По этим причинам основными принципами NoSQL стали отказ от реляционной модели для учета специфики обрабатываемых данных, а также горизонтальная масштабируемость до сотен и тысяч серверов для обеспечения необходимой скорости работы.

Однако это выявило проблему нереляционных БД: невозможно одновременно выполнить

требования по согласованности данных, доступности системы и устойчивости к разделению. В то же время для решения проблемы скорости работы системы для реально существующей информационной системы (ИС) полное перенесение БД из реляционной СУБД в нереляционную потребовало бы значительных временных и денежных затрат.

Альтернативным вариантом является написание «нереляционной надстройки» над существующей реляционной СУБД с использованием методов нереляционного подхода [2].

Существуют три типовых метода, используемые в нереляционных БД для решения проблемы масштабирования: партиционирование (partitioning), репликация (replication) и шардинг (sharding).

Партиционирование представляет собой раз-

биение больших структур баз данных, таких, как таблицы и индексы, на логические части по некоторым выбранным критериям, позволяющее увеличить скорость выборки данных из этих таблиц. Однако оно уже выполняется средствами большинства известных СУБД.

Репликация представляет собой синхронное (асинхронное) копирование данных с ведущих серверов на ведомые (возможно также на ведущие) сервера. Ведущие сервера называют «master-сервер», ведомые - «slave-сервер». В таких системах запрос на чтение данных можно сделать любому серверу, а запрос на изменение -только мастеру [3].

В случае синхронной репликации все запросы на изменение сразу же дублируются master-сервером на все slave-сервера. При синхронной репликации не придется заботиться о реплика-ционном лаге, однако это отразится на скорости отработки запросов на изменение и вставку данных. В случае асинхронной репликации master-сервер ведет журнал изменений и через определенные промежутки времени рассылает журнал всем slave-серверам для синхронизации данных. В связи с наличием проблем в существующей ИС, связанных с ограничением пропускной способности чтения данных, для реализации надстройки выбрана асинхронная репликация (master-slave).

Шардинг представляет собой разделение данных на уровне ресурсов. В реализации над-

стройки выбран горизонтальный шардинг, т. е. размещение разных данных одной таблицы на нескольких серверах. На сегодняшний день для шардинга не существует решения на уровне известных платформ, т. к. он - специфическая задача для отдельно взятого приложения. Главное преимущество использования данного метода в надстройке - горизонтальный шардинг бесконечно масштабируем [3].

На рис. 1 представлена общая схема нереляционной надстройки.

На схеме показано взаимодействие сервера балансировки нагрузки LoadBalancer, мастер- и слэйв-серверов. Запросы на чтение данных отправляются сервером балансировки всем серверам, запросы на изменение данных отправляются только мастер-серверам. Периодически мастер-серверы асинхронно отправляют журнал с изменениями слэйв-серверам для синхронизации данных. Для настройки и масштабирования в системе предусмотрена программа для администратора.

При проектировании системы использовался объектно-ориентированный подход. Диаграммы построены с использованием языка UML в среде Rational Rose. Основными компонентами нереляционной надстройки системы являются:

Load Balancer - серверная программа, взаимодействующая с клиентом, предназначена для распределения нагрузки на серверы;

Administrator

© 1

Load Balancer

Users

\

© ©

Master -1

РСУБД

Master #N

РСУБД

A

a

Slave #1. M

РСУБД

Slave #1.M

С

РСУБД

А

Slave #N.1

РСУБД

Slave #N.M

РСУБД

о

Рис. 1. Общая схема проектируемой системы

SocketApplication

*main(args : String[]) : void

«create»

_Y_

Socke tServer

LoadBalancer LoadBalancer ^>clientSocket : Socket

ServerDescriptor

Oport : int

<>isMaster : boolean <?keyFrom : char <£>keyTo : char OlastSyncDate : Date

*ServerDescriptor

*SocketServer(socket : Socket) *run() : void

LoadBalancer

LcountGetQuerv : int ^serverList : List<ServerDescriptor>

^LoadBalancer() *getlnstance(): LoadBalancer *execute(strQuery : String): String i^addNewMaster(parameters : StringQ): String ^addNewSlave(parameters : Stringf]): String ^getQueryExecute(query Query): String ^changeDataQueryExecute(query Query) String ^getMaster(address InetAddress. port: int) : ServerDescriptor ^locateNeedMaster(ch : char): ServerDescriptor ^locateNeedServersfch char): List<ServerDescriptor>

¿L

«create»"! *

<<create>>

JL

Query

^>parameters[] : String = null

♦QueryO

^getArrayParametersFromStringO *getQueryType

*getQueryParameters

QueryType

OPUT

OGET

¿»REMOVE

OUPDATE

OADD_MASTER

OADD_SLAVE

<?MOVE DATA

Рис. 2. Диаграмма классов Load Balancer

Server Programm - универсальная серверная программа для master- и slave-сервера, взаимодействующая с балансером, принимает запросы от балансера, обрабатывает и выполняет их, результаты выполнения запросов отправляет обратно балансеру. Содержит компоненты для реализации обработки и выполнения запросов. Для работы с реляционной базой данных в СУБД MS SQL Server используется фреймворк Hibernate;

Lib - пакет утилитных классов, необходимых для работы в сети, например сериализация, десе-риализация объектов. Утилитные классы уже в скомпилированном виде могут поставляться со всеми перечисленными программами в виде jar-архива.

Для каждой компоненты нереляционной надстройки построена диаграмма классов, предназначенная для представления статической структуры модели системы в терминологии классов объектно-ориентированного программирования (рис. 2).

Load Balancer предназначен для управления нагрузкой на серверы в системе. Он определяет, к какому серверу отправлять запрос на чтение - решает, считывать с master-сервера или slave-сервера; и к какому на запись - локализует master-сервер с необходимыми данными. Класс

Load Balancer (рис. 2) реализует основную логику работы - обработку запросов клиентов или администраторов системы: определение типа запроса, локализацию сервера по необходимому ключу в запросе, транспортировку запроса, обработку ответов от серверов и транспортировку результатов клиенту или администратору.

Так как Load Balancer представляет собой консольную программу, работающую со всеми компонентами в системе по TCP/IP, предусмотрены классы SocketServer, отвечающий только за работу с клиентом или администратором (общение с серверами хранения данных происходит в основном классе LoadBalancer), и SocketApplication, запускающий работу сервера. Благодаря реализованной схеме классы, отвечающие за работу c клиентами и администраторами по TCP/IP, могут быть заменены на HTTP-сервер, в результате чего балансер сможет принимать запросы по протоколу HTTP.

Сервер хранения данных в проектируемой системе представляет собой универсальную программу как для master-сервера, так и для slave-сервера, поэтому сервер при запуске не знает, какую роль он будет исполнять.

Функциональность сервера описывают три интерфейса:

Рис. 3. Диаграмма классов Server

• BaseServer - интерфейс, определяющий общий функционал для master- и slave-серверов. К нему относятся установка типа сервера setServerMode() и общий метод для мастера и слэйва - getQueryResult(), т. к. запрос на чтение данных в системе может осуществляться как с master-сервера, так и со slave-сервера;

• MasterServer - интерфейс, описывающий функциональность master-сервера по выполнению запросов на изменение данных executeQuery();

• SlaveServer - интерфейс, описывающий функциональность slave-сервера, - возможность обновления данных после получение журнала изменений.

В системе предусмотрен один универсальный класс Server (рис. 3), реализующий все три интерфейса, это сделано в связи с тем, что master-сервер может прямо в процессе работы переключиться и стать slave-сервером, аналогичная ситуация для slave-сервера.

Journal - класс, осуществляющий запись запросов на изменение данных с указанием времени поступления запроса в файл, загрузку логов в оперативную память, получение времени послед-

ней рассылки журнала slave-серверам. Данная функциональность используется только master-сервером. SyncThread реализует асинхронную отправку журнала списку slave-подписчиков.

BaseDataStorage - интерфейс, описывающий функциональность работы любого хранилища. Выделен специально в случае если хранилище необходимо будет изменить, допустим, с реляционной СУБД на другой формат хранения данных, например, xml-формат. Storage - класс, реализующий интерфейс BaseDataStorage для реляционной СУБД.

Система реализована средствами языка Java. Для реализации работы с реляционной СУБД использовался фреймворк Hibernate.

Для начала работы с системой необходимо запустить сервер, после запуска на консоль сервер выведет свой адрес IP и порт. Следующим шагом является запуск работы сервера балансировки нагрузки (его IP адрес и порт прописаны в программе).

Далее необходимо запустить программу для администрирования работы системы. На консоль выведется инструкция по типам команд и передаваемым параметрам.

Balancer

Л

as щ m й я

о

О

"C:\Program ... =Actainistrator process=

For working with data you can U3e next ccirn <all information about new applicants-, exj For administration you can use next ccmman: Chosen balancer:localho3t/127.0.0.1:1234

add master 127.0.0.1 41391 A Z Ok

put Torgac 13.07.19S9 OK

put Zorro 01.01.2001 OK

add slave 127.0.0.1 41402 127.0.0.1 41391 Ok

get Torgan Torgan 13.07.1989 get Zorro Zorro 01.01.2001

=Load Balancer=

got request: ADD_MASTER

result -> Ok

got request: FUT

result -> OK

got request: POT

result -> OK

got request: ADD_SLAVE

Slave wa3 successfully added

result -> Ok

got request: GET

get query gees to: /127.0.0.1 41391 result -> Torgan 13.07.1989 got request: GET

get query goes to: /127.0.0.1 41402 result -> Zorro 01.01.2001

Ъ Server

a

ви m m

G

X

9

* +

1

а

_= Server =_ Network addre33: 127.0.0.1 41391

Got query. Start processing... query for setting 3erver mode result -> Ok

Got query. Start proce33ing... executing PUT query query for changing data: PUT result -> OK

Got query. Start processing... executing PUT query query for changing data: PUT result -> OK

Got query. Start processing... adding new slave... result -> Ok

Got query. Start processing... get query result of GET query query GET

result -> Torgan 13.07.1989

_= Server =_ Network address: 127.0.0.1 41402

Got query. Start processing___

query for setting server mode result -> Ok

Got query. Start processing... JOURNAL UPDATE result ->

Got query. Start processing... get query result of GET query] query GET

result -> Zorro 01.01.2001 Got query. Start processing... JOURNAL UPDATE result ->

Got query. Start prcce33ing... JOURNAL UPDATE result ->

Got query. Start processing___

JOURNAL UPDATE result ->

Рис. 4. Пример работы реализованной системы

При добавлении первого master-сервера системный администратор использует команду add master. В качестве параметров кроме адреса сервера указывается полный диапазон ключей. В дальнейшем при добавлении нового master-сервера администратору следует указать только один ключ «keyFrom» - нижнюю границу для добавляемого master-сервера. Balancer по заданным параметрам распределит данные между серверами: укажет master'1 передать необходимые данные на новый master'2. Таким образом, добавле-

ние новых серверов не требует ручной работы по перемещению данных, новые серверы сами конфигурируют свою работу в соответствии с командами администратора. Пример работы системы представлен на рис. 4.

Предложенная нереляционная надстройка позволит обеспечить хорошую горизонтальную масштабируемость, повышение производительности, надежности и отказоустойчивости существующей ИС.

СПИСОК ЛИТЕРАТУРЫ

1. NOSQL Patters [Электронный ресурс] // Pragmatic Programming Techniques // Режим доступа: http:// horicky.blogspot.com/2009/11/nosql-patterns.html

2. NoSQL - подходы к решению типичных задач [Электронный ресурс] // Highload Web // Режим досту-

па: http://highload.com.ua/index.php/2010/06/03

3. Шардинг, партиционирование, репликация - зачем и когда? [Электронный ресурс] // Highload Web // Режим доступа: http://highload.com.ua/index.php/2009/05/06