CC BY
109
УДК 004.65
О СОВРЕМЕННЫХ ТЕНДЕНЦИЯХ ХРАНЕНИЯ ДАННЫХ В ДОКУМЕНТО-ОРИЕНТИРОВАННЫХ СУБД
А. В. Дьяконов Научный руководитель - Ю. Б. Козлова
Сибирский государственный аэрокосмический университет имени академика М. Ф. Решетнева
Российская Федерация, 660037, г. Красноярск, просп. им. газ. «Красноярский рабочий», 31
Е-mail: AntXXI@mail.ru
Рассмотрены основные проблемы хранения данных в системе для совместной работы над проектом. Рассмотрено и проанализировано хранение данных в документо-ориентированных СУБД. Реализован метод MapReduce. Обосновывается применение документо-ориентированной СУБД в системе для совместной работы над проектом.
Ключевые слова: хранение данных, документо-ориентированная СУБД, MapReduce, система для совместной работы над проектом.
ABOUT CONTEMPORARY TRENDS STORING DATA IN DOCUMENT DATABASE
А. V. Dyakonov Scientific supervisor - Y. B. Kozlova
Reshetnev Siberian State Aerospace University 31, Krasnoyarsky Rabochy Av., Krasnoyarsk, 660037, Russian Federation E-mail: AntXXI@mail.ru
Reviewed main problems storing data in the system collaborative work on a project. Reviewed and analyzed storing data in the document database . The method of MapReduce realized. The use of document database development in the system to collaborative work on a project.
Keywords: storing data, document database, MapReduce, system collaborative work on a project.
Для реализации системы для совместной работы над проектом, стоит одна из нескольких задач, каким образом и с помощью чего хранить данные в проекте, при этом работа с данными должна быть максимально проста и производительна. Проблема заключается в том, что документ не имеет строгой структуры, и использование реляционных баз данных (РБД) не актуально. Они следуют строгой структуре и требуют значительного объема подготовительной работы, такой как предварительная разработка схемы и модели данных. Новое поколение NoSQL и документо-ориентированных баз данных (ДОБД) значительно упрощает большую часть этой подготовки, позволяя создавать и хранить информацию в гибком формате. Кроме того, можно разработать методы извлечения этих данных в требуемом фиксированном формате [2].
Основные достоинства:
Масштабируемость. Горизонтальное масштабирование существующих традиционных СУБД обычно является трудоемкой, дорогостоящей и эффективной только до определенного уровня задачей. В то же время многие NoSQL-решения проектировались исходя из необходимости масштабироваться горизонтально и делать это «на лету». Поэтому эта процедура обычно проще и прозрачнее в NoSQL, чем в РСУБД [1].
Производительность БД на одном узле, а не в кластере также является немаловажным параметром. Для многих задач такие свойства традиционных СУБД, как транзакционность, изолированность изменений, надежность в пределах одного узла или даже сама реляционная модель, не всегда нужны в полном объеме. Поэтому отказ от этих свойств (всех или некоторых) позволяет NoSQL иногда добиваться большей производительности на одном узле, чем традиционным решениям.
Секция «Программные средства и информационные технологии»
Надежная работа в условиях, когда отказ железа или сетевая недоступность - обычное дело, является одним из свойств многих решений NoSQL. Основной способ ее обеспечения - это репликация. Сама по себе репликация отнюдь не является уникальной особенностью NoSQL, но здесь, как и при масштабировании, важную роль играют эффективность и легкость внесения изменений в существующую инсталляцию. Переход БД к работе в режиме репликации - это простая задача для большинства NoSQL-решений.
Map/Reduce - это подход к обработке больших объемов данных, который состоит из двух фаз: Map - предварительная обработка входных данных и Reduce - обработка тем или иным способом выборки, полученной на стадии Map [1].
Преимущества такого подхода очевидны при соблюдении двух условий. Первое - фаза Map реализована так, что её можно запускать параллельно на нескольких узлах. Второе - Reduce позволяет принимать на вход не только результат выполнения Map, но и применения предыдущего Reduce.
Реализация Map/Reduce в системе для совместной работы над проектом:
Есть большая база данных пользователей, распределенная по нескольким узлам, и стоит задача посчитать количество внесенных изменений пользователем в документ в зависимости от даты. Тогда в качестве Map будет функция, возвращающая для каждой записи БД структуру вида «дата | количество символов | количество записей», где при выполнении первой фазы «количество записей» будет равно единице. В качестве Reduce будет функция, складывающая «количество символов» и «количество записей» с группировкой по «дате». Таким образом, получим возможность запустить Map на нескольких узлах параллельно и получить предварительную выборку. Далее запускается Reduce на нескольких и подводим промежуточные результаты, а по итогам - тот же самый Reduce по финальному набору данных, собранному из промежуточных. Структура выполнения Map/Reduce представлена на рисунке.
Inpul Map Reduce Output
Структура работы Map/Reduce Документе -ориентированные СУБД
Они хранят данные в виде коллекций документов, состоящих из набора полей. Этот набор может различаться в документах одной коллекции благодаря «бессхемности» таких СУБД. Так же допускаются вложенные документы и сложные типы значений полей (массивы, ссылки и т. п.). Идеальный вариант их применения - это хранение более-менее независимых документов, не требующих поддержания ссылочной целостности между ними или коллекциями [3].
Также они хорошо подходят для работы с данными нестрогой структуры. Такого рода данные часто встречаются при решении задач для работы с документами, логирования и сбора статистики: существует множество типов событий, относящихся к одной категории, но с различными атрибутами. В традиционных СУБД хранение такого рода данных осуществляют двумя способами. Либо записывают основные параметры событий в одну таблицу, а дополнительные поля - в множество связанных таблиц, либо осуществляют сериализацию дополнительных полей в строки, бинарные данные и т. п. Такой подход сильно усложняет логику приложения и затрудняет дальнейшую работу с данными.
Самые популярные представители этого семейства - MongoDB и CouchDB. Обе поддерживают репликацию и шардинг, причем MongoDB - шардинг с автоматической миграцией данных при добавлении или отключении «шардов» из кластера. Кроме того, оба решения реализуют Map/Reduce. CouchDB использует его в качестве замены сложным ad-hoc запросам: СУБД создает «отображения» (view), данные которых вычисляются операциями Map/Reduce и автоматически обновляются при изменении. MongoDB также поддерживает достаточно сложные запросы. Для этого в решении реализован собственный, не похожий на SQL, язык запросов [3].
Основное отличие между MongoDB и CouchDB - это разный подход к конкурентным изменениям данных. MongoDB не реализует транзакционность и осуществляет лишь простейшие атомарные операции над объектами. CouchDB же реализует управление конкурентным доступпом с помощью мультиверсионности. Таким образом, в CouchDB изменение документов одним пользователем не видно другим до момента «фиксации». А это не удовлетворяет условиям системы для совместной работы над проектом, потому была выбрана СУБД MongoDB.
Документо-ориентированные базы данных радикально меняют привычные представления о структурах данных и правилах их обработки. Достаточно сохранять данные в том формате, в каком они поступают, а затем выполнять обработку, по ходу дела анализируя данные и манипулируя различными форматами и структурами. Этот процесс позволяет очень легко упростить и сократить огромное количество данных. Серверный процесс, который может работать с очень большими, распределенными базами данных, обычно облегчает работу, а не затрудняет ее. NoSQL с документо-ориентированной моделью хорошо подходит для задач связанных с реализацией системы совместной работы над проектом.
Библиографические ссылки
1. Data mining in a document world [Электронный ресурс]. URL http://www.ibm.com/ developerworks/opensource/library/ba-datamining/index.html (дата обращения: 20.03.2015).
2. Лучинкин З. С., Сидоркина И. Г. Проектирование модели данных, слабоструктурированной, нереляционной, документо-ориентированной базы данных // Вестник Чувашского университета. 2014. № 2. С. 103-107.
3. Прамодкумар Дж. Садаладж, Мартин Фаулер. NoSQL. Новая методология разработки нереляционных баз данных : Вильямс, 2015. 192 с.
© Дьяконов А. В. 2015
