Преимущества и недостатки нереляционных баз данных

Определим, что в данной статье речь пойдёт о NoSQL базах данных, которые были спроектированы и созданы после массового внедрения реляционных баз данных. Логически понятие NoSQL может включать в себя и дореляционные БД, которые проектировались без оглядки на опыт использования SQL систем и не несут в себе цели создания современных NoSQL решений. Эта цель - отступление от реляционной модели хранения данных в попытке устранить некоторые известные недостатки SQL или достичь более высокой производительности в конкретных задачах.

Предпосылки появления

Ключевым фактором, заставившим мировое IT-сообщество задуматься над новыми стратегиями хранения и доступа к информации, стал планомерный рост объемов данных в сети Интернет. В связи с этим был создан термин Big Data, включающий в себя некую стратегию, позволяющую эффективно работать с огромными постоянно растущими массивами данных. И на фоне этой концепции четко вырисовывалась необходимость в модели базы данных, которая будет больше нацелена на скорость доступа и масштабируемость. Нужно было какое-то более простое решение, чем существующие реляционные БД, при этом не уступающее им в ряде конкретных задач. В первую очередь, это задачи построения облачных хранилищ, где конечному пользователю в первую очередь важна скорость доступа и возможный объем хранимой информации.

История популярности

Пик самого активного обсуждения NoSQL баз данных пришелся на 2009 год и принес с собой множество мифов и спорных теорий. Рассмотрев их, можно представить себе путь NoSQL решений и представления о них в головах людей.

NoSQL - это революция

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

Принципиально новыми подходами NoSQL решения тоже не могут массово похвастаться - к примеру, концепция запущенной в 2008 году MongoDB - это более эффективная реализация модели работы БД Pick 1965-го года выпуска.

SQL базы данных обречены

Подобные разговоры ведутся уже почти второй десяток лет, и по-прежнему реляционные БД держат доминирующие позиции на рынке с огромным отрывом от любых NoSQL решений. Это происходит в первую очередь потому, что NoSQL базы данных не могут более эффективно решать задачи SQL. Наиболее удачные NoSQL решения, в первую очередь, нацелены на решения специфических задач и создаются гигантами IT-индустрии для собственных нужд - это продукты от Google, Amazon, Microsoft и Apache, обслуживающие конкретные проекты. Google AppEngine Data Store возможно использовать столько с веб-сервисами Google, хранилище SQL Data Services является частью платформы Microsoft Azure, а SimpleDB входит в состав Amazon WebServices.

Необлачные хранилища, которыми можно пользоваться, просто скачав и установив их у себя, зачастую являются достаточно молодыми открытыми проектами, которые так же создавались под конкретные нужды. Они не были созданы, чтобы решать весь объем задач, который позволяют решать SQL системы. Более того, назначение чаще всего не является ключевой преградой для массового внедрения NoSQL систем - они имеют определенный набор недостатков, который не критичен для гигантов IT-индустрии, но становится решающим для большей части обычных компаний.

Вся шумиха вокруг NoSQL и Big Data - это обман

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

Скорее всего, в процессе эволюции хранения и обработки данных мир увидит а первую очередь все больше комбинированных решений, где NoSQL системы используются чтобы “прикрыть” слабые места SQL.

Виды NoSQL баз данных

Всего выделяют четыре основных типа NoSQL-хранилищ. Они различаются моделью данных, подходом к распределенности и репликации, благодаря чему могут в различной степени подходить под те или иные виды конкретных задач.

Хранилище вида “ключ-значение”

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

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

Именно потому подобные хранилища используются в тех случаях, когда конкретное содержимое отдельной ячейки не интересно оператору базы данных - иначе говоря, полностью отсутствуют связи между отдельными ячейками хранилища. Базы данных типа “ключ-значение” не очень хорошо подходят в качестве полной замены реляционных БД, но нашли своё применение в качестве кэшей для объектов - ведь между кэшированными объектами разных пользователей точно так же нет связей, важна лишь скорость доступа к кэшу, а так же возможность быстро менять масштаб системы.

Наиболее известные примеры СУБД данного типа это Amazon DynamoDB, Berkeley DB, MemcacheDB, Redis и Riak.

Документоориентированные базы данных

Документоориентированная БД представляет собой систему хранения иерархических структур данных (документов), имеющую структуру дерева или леса. Структура дерева начинается с корневого узла и может иметь несколько внутренних и листовых узлов. Листовые узлы содержат конечные данные, которые при добавлении заносятся в индексы базы, благодаря которым можно осуществлять быстрый поиск даже при достаточно сложной общей структуре хранилища. Фактически документоориентированные БД являются более сложной версией хранилищ “ключ-значение” - они все ещё не очень хороши для систем, подразумевающих множество связей между элементами, но позволяют осуществлять выборку по запросу без полной загрузки отдельных документов в оперативную память. Механизмы поиска позволяют находить как документы целиком, так и части документов, а древовидная структура позволяет организовывать отдельные коллекции документов одного типа или схожей тематики.

К примеру, при создании музыкального хранилища можно создать коллекцию музыки 80х годов, в ней сделать отдельные коллекции по годам, а внутри них отдельные документы с треками выпущенных в этот год альбомов. Но если пользователь пожелает увидеть рейтинг самых популярных композиций определенного десятилетия - этот запрос будет выполняться достаточно долго, ведь придется просмотреть каждый документ всей базы данных. Таким образом, можно сделать вывод что документоориентированные БД найдут своё применение в задачах, где требуется упорядоченное хранение информации, но нет множества связей между данными и не нужно постоянно собирать статистику по ним. Документы не требуют определения схемы - это значит что каждый отдельный документ может состоять из любого количества уникальных полей - в отличие от реляционных баз данных, в которых при попытке хранить разнородные данные неизбежно появляются пустые поля.

Примеры СУБД данного типа: CouchDB, Couchbase, MarkLogic, MongoDB, eXist.

Графовые базы данных

Графовая модель базы данных представляет собой обобщение сетевой модели данных и отличается сильными связями между узлами.

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

Наиболее известные графовые СУБД это ArangoDB, FlockDB, Giraph, HyperGraphDB, Neo4j, OrientDB.

Bigtable-подобные базы данных

Bigtable-подобные базы данных или иначе хранилища семейств колонок содержат данные, упорядоченные в виде разреженной матрицы, строки и столбцы которой используются в качестве ключей. Эти хранилища имеют много общего с документоориентированными БД - системы управления содержимым, регистрацию событий, блоги. Не стоит путать bigtable-подобные базы данных с колоночными хранилищами, которые являются, по сути, реляционными БД с раздельным хранением колонок.

Как правило, эти хранилища применяются для веб-индексирования и решения прочих задач, предполагающих огромные объемы данных.

Примерами СУБД данного типа являются: HBase, Cassandra, Hypertable, SimpleDB.

Сильные и слабые стороны NoSQL

Чтобы понять основную причину популярности NoSQL решений, а так же обозначить сферу их разумного применения стоит рассмотреть все предложенные варианты с нескольких сторон: выделить общие отличия всех NoSQL систем от реляционных БД, а так же обсудить те проекты, в которых NoSQL базы данных будут сильнее за счет конструктивных особенностей.

Отсутствие SQL

Первая особенность весьма очевидна - это отсутствие SQL (Structured Query Language) - универсального языка запросов, который используется всеми реляционными системами. Все NoSQL системы имеют собственный API для взаимодействия или встроенный язык запросов, зачастую являющийся просто урезанной версией SQL. Это решение имеет свои позитивные стороны:

• Простота работы. Многие NoSQL решения, в основном хранилища вида “ключ-значение” имеют по сравнению с реляционными базами данных очень сильно урезанную функциональность, которая им просто не требуется для выполнения поставленных задач. В таком случае оператору базы данных не требуется глубоких знаний достаточно мощного и гибкого механизма работы с SQL-запросами. Это очень сильно снижает входной порог для начала работы с NoSQL хранилищами.
• Более простой синтаксис запросов - меньше ошибок. Для упрощения работы с базой данных некоторыми разработчиками используется ORM (Object-Relational Mapping) - технология, позволяющая автоматически транслировать операции с объектами в запросы к базе данных. Зачастую подобные решения работают неэффективно и плодят множество ненужных или откровенно ошибочных запросов. Нельзя сказать, что разработчики ORM плохо выполняют свою работу - просто задача слишком сложна. Язык SQL универсален и очень емок, для полноценной работы с ним необходим определенный багаж знаний. При этом собственные языки запросов современных NoSQL хранилищ гораздо больше подходят для выполнения простых манипуляций с базой данных.

Недостатки у данного решения так же присутствуют, притом в долгосрочной перспективе они могут серьёзно перевесить все позитивные моменты:

• Приложение сильно привязывается к конкретной СУБД. Язык SQL универсален для всех реляционных хранилищ и пользователю не придётся кардинально переписывать весь код в случае смены СУБД. Даже если две NoSQL системы концептуально практически не отличаются, они будут иметь очень мало общих стандартов в API и в специфике запросов.
• Ограниченная емкость встроенного языка запросов. SQL имеет очень богатую историю и множество стандартов. Это очень мощный и сложный инструмент для операций с данными и составления отчетов. Практически все языки запросов и методы API хранилищ NoSQL были созданы на основе тех или иных функций SQL - как следствие, они имеют куда меньшую функциональность.
• Низкая ценность и узкопрофильность знаний - специалистов с хорошим знанием SQL гораздо проще найти, в то время когда спецификой работы API некоторых NoSQL решений на серьёзном уровне мало кто увлекается - это значит, что многие специфические моменты оператору базы данных придется осваивать “на ходу”.

Простота и молодость NoSQL

Если преимущества простоты NoSQL хранилищ достаточно очевидны, то недостатки зачастую выясняются только с горьким опытом. Во-первых, ограничения структуры реляционных БД в определенной степени гарантируют целостность данных - информация, которая не удовлетворяет ограничениям по типу, просто не сможет попасть в базу. В случае использования, например, хранилищ типа “ключ-значение” задача контроля целостности данных полностью ложится на приложение. Во-вторых, процесс создания реляционного хранилища включает в себя этап проектирования модели данных. На этой стадии можно оценить узкие места выбранной стратегии и спроектировать действительно надёжную и удобную систему. NoSQL решения не требуют определять схему базы данных перед началом работы. Но без этапа первоначального тестирования и планирования можно в процессе разработки наткнуться на непредвиденные трудности, которые могут даже полностью отсечь вариант работы с конкретным NoSQL решением. А учитывая описанные в предыдущем пункты трудности быстрого перехода с одной нереляционной базы данных на другую - цена ошибки становится очень высокой.

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

Самые сильные стороны NoSQL

После обзора спорных особенностей большинства NoSQL решений есть смысл рассмотреть то направление, в котором эти системы максимально раскрывают свой потенциал. Это распределённые системы. Весомыми преимуществами при работе с распределенными системами обладают все типы нереляционных хранилищ, за исключением графовых БД - они по определению предполагают большое количество связей между узлами данных.

Лавинообразный рост количества данных в мировой сети обострил проблему вертикальной масштабируемости - вычислительные мощности железа могут расти не бесконечно, да и цена нескольких простых серверов меньше, чем одного высокопроизводительного. В такой ситуации хорошим выходом станет горизонтальное масштабирование, когда несколько независимых машин соединяются вместе и каждая из них обрабатывает только часть запросов. Такая архитектура делает возможным быстрое увеличение мощности кластера путем добавления нового сервера. Рассчитанные на работу в распределенных системах NoSQL хранилища изначально проектируются с таким расчетом, что все процедуры репликации, распределения данных и обеспечения отказоустойчивости выполняются самой NoSQL базой.

Ключевые преимущества NoSQL баз в распределенных системах заключаются в процедурах шаринга и репликации.

Репликация - это копирование данных при их обновлении на другие сервера. Этот механизм позволяет добиться большей отказоустойчивости и масштабируемости системы. Принято выделять два вида репликации: master-slave и peer-to-peer.

Первый тип подразумевает наличие одного мастер-сервера и нескольких дочерних серверов. Запись может производиться только на мастер-сервер, а он в свою очередь передаёт изменения на дочерние машины. Этот тип репликации даёт хорошую масштабируемость на чтение(чтение может происходить с любого узла сети), но не позволяет масштабировать операции записи - запись идёт только на один мастер-сервер. Так же такой вариант организации репликации предполагает сложности в случае неисправности мастер-сервера - в таком случае должен происходить автоматический или ручной выбор нового мастер-сервера из оставшихся.

Второй тип - peer-to-peer - предполагает, что все узлы равны в возможности обслуживать запросы на чтение и запись. Информация о обновлении данных передаётся от сервера к серверу по кругу.

Шаринг - это разделение массива информации по разным узлам сети - когда каждый узел отвечает только за определенный набор данных и обрабатывает запросы на чтение и запись, относящиеся только к этому набору данных. Эта технология использовалась при работе с реляционными базами данных в достаточно сыром виде - на уровне приложения создавались независимые базы данных, по которым распределялись запросы пользователей. Концепция NoSQL предполагает, что ответственность за этот механизм будет лежать на базе данных, и шаринг будет производиться автоматически.

Социальные данные

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

Пик популярности NoSQL решений был во многом связан с амбициозным заявлением, поступившим от социальной сети Twitter. Они видели определенные недостатки работы с реляционным хранилищем MySQL для своих твитов и изъявили желание перейти на новую NoSQL СУБД Cassandra. Но эта идея так и не была воплощена в жизни - как комментируют этот момент сами сотрудники Twitter - компания оценила свои приоритеты, после чего решение было признано слишком рискованным. С другой стороны, то же самое NoSQL хранилище отлично прижилось в качестве основной базы данных для социальных сетей Instagram и Facebook - а это уже очень весомые истории успеха для всего семейства NoSQL.

Аналитика данных

В облачных хранилищах и разработанных для них NoSQL решениях часто используется принцип множественной аренды. Он заключается в том, что большое количество пользователей одновременно использует одну и ту же систему. Чтобы предотвратить её перегруз в решениях, рассчитанных на большую масштабируемость, применяют политику ограничения запросов. Например, в SimpleDB время выполнение запроса не может превышать 5 секунд, а в Google AppEngine Datastore один запрос к базе не позволяет получить более 1000 записей.

Эти ограничения не страшны для простой работы приложения, но значительно сказываются на возможностях аналитики данных. Компании часто извлекают выгоду из больших объемов пользовательских данных - на основе их анализа можно выделять наиболее популярные продукты, составлять “на лету” списки рекомендаций для конкретных групп пользователей основываясь на их личных данных или истории. Для многих NoSQL решений подобные функции сложно реализуемы или попросту невозможны.

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

Выводы

Резкий скачок популярности NoSQL баз данных и связанные с ним истории использования нереляционных СУБД показали миру IT важность реалистичной оценки приоритетов компании. Некоторые вендоры успешно внедрили у себя NoSQL хранилища и получили заметное снижение убытков и повышение качества приложений. Другие потерпели неудачу, поздно поняв, что принятое решение им не подходит. А третьи просто остались со своими технологиями. Реляционные или нереляционные базы данных - это не единственный выбор, который предстоит сделать компании. Не менее важен и выбор между конкретными системами и конкретными стратегиями работы с ними.

В любом случае, NoSQL-революции не произошло - реляционные базы данных удерживают стабильно доминирующие позиции. Они являют собой симбиоз надежности, функциональности и универсальности. При этом многие NoSQL решения направлены на закрытие совершенно конкретных проблем SQL хранилищ - в первую очередь на усиление горизонтальной масштабируемости. Многие нереляционные базы данных отлично работают, выполняя цель своего создания, но при этом они уже не являются тем универсальным продуктом, которым являются SQL. У большинства компаний просто нет таких объемов данных и других специфических условий работы, в которых NoSQL решения являлись бы панацеей или просто были бы выгодны в качестве основной базы данных. NoSQL хранилища показывают себя с очень хорошей стороны в симбиозе с реляционными базами данных. Например, в системах, где основной объем инофрмации хранит SQL, а за кэш отвечает NoSQL. Для захвата более существенных позиций на рынке нереляционным системам всё ещё не хватает множества базовых вещей - универсальности, надежности, целостности и предсказуемости.