SQL или NoSQL: что выбрать для управления большими массивами данных

Тема: Бизнес  |   Дата: 30.03.2015   |  Автор: Александр Длабик

Грамотное управление БД

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

SQL-платформы проверены временем и популярны до сих пор

Структурированный язык запросов (SQL) доминировал в качестве такового десятки лет, и в настоящее время в него активно инвестируют такие крупные информационные компании, как Google, Facebook, Cloudera и Apache.

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

После того, как SQL стал доминирующей технологией, причины его успеха немного подзабылись. Тем не менее, факты говорят о том, что SQL одержал победу благодаря исключительному сочетанию своих сильных сторон:

• SQL – декларативный язык. Он интерактивен и обладает широким набором запросов. Пользователю достаточно правильно сформулировать запрос, чтобы получить на него корректный ответ. В технологии NoSQL, напротив, используется процедурный язык запросов. Это значит, что пользователю, кроме самого запроса на получение информации, необходимо еще дополнительно указать способ обработки этого запроса.
• SQL стандартизирован. Несмотря на то, что SQL-интерфейс может быть реализован на одном из многочисленных диалектов, само ядро языка остается полностью стандартизированным, а такие дополнительные спецификации как ODBC или JDBC реализуют общедоступные стабильные интерфейсы к хранилищам данных SQL.
• SQL отлично масштабируется. Было бы совершенно неверным предполагать, что мы должны жертвовать SQL ради масштабируемости. Facebook, например, использует SQL для доступа к петабайтам пользовательских данных. Точно так же, SQL совершенно отвечает транзакционным требованиям ACID. Кроме того, уровень абстракции, реализованный в SQL, позволяет ему чрезвычайно эффективно обслуживать кластерные хранилища данных с непрерывной репликацией. Современные системы на базе SQL поддерживают также облачные технологии, они горизонтально масштабируемы и отказоустойчивы.
• SQL поддерживает JSON.  Несколько лет тому назад в SQL появилась поддержка XML. В настоящее время поставщики SQL добавили в него еще и поддержку JSON, поскольку он уже успел приобрести популярность в качестве формата обмена данными. Существуют весьма уважительные причины для включения в SQL такого рода поддержки структурированных типов данных. Именно поэтому такие БД, как Oracle 12c, PostgreSQL 9.2, VoltDB и другие обладают полной поддержкой формата JSON, и при этом их производительность часто превосходит хранилища NoSQL, для которых данный формат является «родным».

SQL продолжает завоевывать рынки и привлекать новые инвестиции. Что же касается NoSQL, то он со своим проприетарным языком запросов и простой семантикой оказался в довольно непростой ситуации.

NoSQL предназначен для обработки больших массивов данных

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

Выбор NoSQL критичен при необходимости масштабирования

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

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

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

Выбор NoSQL критичен для обеспечения гибкости

Реляционная и NoSQL модели совершенно не похожи друг на друга. В реляционной модели данные содержатся в наборах связанных между собой таблиц, состоящих из строк и столбцов. Эти таблицы соотносятся другу с другом посредством внешних ключей, которые также хранятся в столбцах. Когда к базе данных поступает запрос, данные из множества разных таблиц объединяются для формирования выборки. То же самое касается и записи данных, которые в этом случае должны быть распределены по соответствующим таблицам и определенным образом скоординированы. Если объем данных и скорость чтения/записи невелики, реляционная БД прекрасно справится с их обработкой. Но беда в том, что современные приложения генерируют просто колоссальное количество данных, которые, к тому же, должны быть прочитаны/записаны, по сути, в реальном времени.

NoSQL строится по совершенно иной модели. NoSQL документно-ориентирован и хранит данные, используя JSON формат. Каждый JSON документ представляет собой объект, с которым и работает приложение БД. В одном таком объекте/документе может содержаться до 25 агрегированных таблиц реляционной БД.

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

Выбор NoSQL критичен при наличии больших массивов данных

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

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