CC BY
57
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() *ServerDescriptor() *getlastSyncDate()
*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 (Дата обращения Nov. 2009)
2. NoSQL - подходы к решению типичных задач [Электронный ресурс] // Highload Web // Режим досту-
па: http://highload.com.ua/index.php/2010/06/03 (Дата обращения June 2010)
3. Шардинг, партиционирование, репликация - зачем и когда? [Электронный ресурс] // Highload Web // Режим доступа: http://highload.com.ua/index.php/2009/05/06 (Дата обращения May 2009)
