Хранение данных в NoSQL системах на примере MongoDB Текст научной статьи по специальности «СМИ (медиа) и массовые коммуникации»

Хранение данных в NoSQL системах на примере MongoDB

Довбенко А. В.

Довбенко Алексей Викторович /Dovbenko Alexey Victorovich - аспирант, кафедра теоретических основ информатики, факультет прикладной математики, информатики и механики, Воронежский государственный университет, г. Воронеж

Аннотация: в работе произведен анализ хранения информации в базах данных типа NoSQL на примере MongoDB, оценены основные преимущества и недостатки. Актуальность темы объясняется выбором не реляционной системы для хранения больших объемов данных.

Ключевые слова: базы данных, NoSQL, MongoDB, архитектура баз данных

Совсем не так давно NoSQL начало выходить в массы, хорошая пиар компания и сама идея «хранить данные как вам удобно» очень интриговали, в скором времени NoSQL стало трендом, в каждом новом проекте старались использовать именно эту систему хранения, ведь записывать и читать данные стало в разы проще, данные не надо обрабатывать, записывать можно было как стандартные типы (int, float, text, string), так и более новые (Boolean, Array, object). Причем на вложенные элементы можно было накладывать индексы и искать по ним. Но пиар компания «храните данные как угодно» сыграла с NoSQL злую шутку. Многие разработчики полностью отказывались от реляционной, структурированной системы хранения данных и писали всё в один документ. Хорошо эта проблема описана в статье Sarah Mei «Why You Should Never Use MongoDB» (Почему вы никогда не должны использовать MongoDB) [1]. В ней разработчики социальной сети Diaspora решили использовать MongoDB, как и многие разработчики Diaspora решили, что NoSQL это панацея от продумывания архитектуры базы данных (а именно все связи можно хранить в одном документе), но, к сожалению, архитектуру в NoSQL надо продумывать гораздо тщательней, чем в реляционных базах данных. В итоге у разработчиков Diaspora начались проблемы с хранением, а именно проблема с памятью, дублирование данных и проблемы с чтением данных. Так что же хорошего в NoSQL, если архитектуру всё же стоит продумывать, к тому же та же MongoDB имеет строгую типизацию данных в отличие от того же MySQL (эта проблема всплывает в слабо типизированных языках).

Для нашего исследования мы будем использовать MongoDB 3.0.1. Стоить отметить, что в отличие от MongoDB 2.6, версия 3 может похвастаться новой более экономной системой хранения WiredTiger, основной плюс которой, что при записи происходит блокировка документа, а не всей коллекции, что ранее было сильной проблемой при очень высокой скорости записи. Ещё в MongoDB 3.0 окончательно реализовали поддержку текстового индекса, который впервые появился в версии 2.6.

Итак, в нашем примере мы имеем коллекцию страниц из Википедии со структурой _id - MongoId специальной уникальный идентификатор у Mongo, title - string название страницы, html - string полный html-код страницы, date - MongoDate дата добавления документа, url - URL документа, links - массив ссылок на странице. Информация о нашей коллекции (команда db.getCollection ('collection').stats() ):

fcy__________________________

‘ О (1)

0 П5

0 count 0 see 0 avgObjSize 0 numExtents 0 storageSize 0 lastExtentSize 0 paddingFador 0 paddingFadorNote 0 used-lags 0 capped 0 nindexes J И indedktaib 0 totaDndexSize J И indexSizes 0 Jd_

0 uri_l 0 frttetext 0 datel 0 date_-l 0 linksl 0 ok

[Value____________________________________________________________________| Type

{1& Helds} Object

dissertation-colled'ion String

103877 Int32

18597684144000000 Double

179035 Int32

23 Int32

19203854240000000 Double

2146426864000000 Double

1 оооооо Double

paddingFador is unused and unmaintained in 3D. It remains hard coded t.. String

1 Int32

false Boolean

6 Irrt32

[0 fields} Object

3354040480000000 Double

[6 fields} Object

4112528 Int32

9263408 Int32

31592064 Int32

2927008 Int32

5208112 Int32

3300937360000000 Double

1000000 Double

Рис.1. Информация о коллекции

В рисунке 1 нас интересуют следующие параметры: count - количество документов, 103877 не так много, но для большинства проектов вполне солидное значение, size: 18597684144 - размер коллекции в байтах, т. е. 18,597 гигабайт, avgObjSize - средний размер одного документа - 179 килобайт. Используемые индексы

_id - стандартный уникальный индекс у MongoDB, занимает довольно мало места, всего 4 мегабайта. url_1 -обыкновенный индекс B-TREE, занимает 9 мегабайт, title_text - текстовый индекс на название документа, стоит отметить, что в версии 2.6 это был очень тяжелый индекс, сейчас он занимает 31 мегабайт, что относительно немного, date_1 и date_-1 - индексы на поле date, стоить отметить, что в mongo, чтобы сортировка шла по индексу, индекс надо ставить как на прямую сортировку date_1, так и на обратную date_-1, занимают они 2.9 и 5.2 мегабайта соответственно, заметьте, что обратный индекс занимает почти в два раза больше места, чем прямой, ну и самый большой индекс - это индекс на массив ссылок, занимает он 3.3 гигабайта, к слову, массив links имеет в среднем 200 элементов. Это и есть основная проблема использования не реляционных баз данных, в данном случае вложенность оправдана, и создание отдельной коллекции links излишне, но часто разработки используют во вложенности целые документы, которые тоже имеют вложенность, как в примере с Diaspora [1], что в итоге влечет к негативным последствиям и излишнему расходу системных ресурсов.

Итак, проведем базовые запросы по этим индексам: поиск по _id , как и следовало ожидать быстрый и отрабатывает за 17 миллисекунд, сортировка по дате в обратную сторону (самые свежие записи) отрабатывается за 57 миллисекунд, обычная сортировка (самые старые данные в начале) отрабатывается за 64 миллисекунды, стоит отметить, что все запросы кэшируются, и повторные запросы будут в разы быстрее предыдущих. Поиску по тексту мы уделим особое внимание, если при обычных запросах мы указываем, какое именно поле должно совпадать условию, то при текстовом поиске поиск совершается по всем полям, на которых наложен индекс. Поиск по слову Joker у меня занял 180 миллисекунд, поиск по слову perl, и при этом в заголовке не должно содержаться слово language - 220 миллисекунд, что весьма впечатляюще, т. к. раньше такой поиск можно было проводить только с помощью регулярных выражений, и он был очень медленный. Поиск по ссылкам, несмотря на довольно большой размер индекса, тоже довольно шустрый и занимает приблизительно 50 миллисекунд.

В этом анализе мы опустили один из главных плюсов NoSQL, а именно простоту реализации операций шардинга и репликации, но это сделано намеренно, так как и шардинг, и репликация должны быть оправданы, а если база данных требует шардирования на 20 гигабайтах данных, то стоит поискать другие варианты хранения данных.

Вывод: в статье кратко описаны плюсы и минусы NoSQL базы данных, а именно MongoDB. На основе эксперимента выявлено, что основной тезис NoSQL, а именно, «храните данные как угодно», из-за которого многие разработчики выбирают эту систему хранения, является ошибочным и часто губительным для проектов. Но всё же, NoSQL это прекрасный инструмент, который надо использовать с умом, продумывая архитектуру хранения и тип данных ещё больше чем в реляционных базах данных.

Литература

1. Sarah Mei Why You Should Never Use MongoDB [Электронный ресурс]: 2013. Режим доступа: http://www.sarahmei.com/blog/2013/11/11/why-you-should-never-use-mongodb/. (дата обращения: 07.06.2015).