NoSQL – коротко о главном

SQL и NoSQL: разбираемся в основных моделях баз данных

SQL и NoSQL: разбираемся в основных моделях баз данных

• Переводы , 4 сентября 2016 в 3:57
• Иван Бирюков

С незапамятных времен память была одной из самых важных и необходимых составляющих компьютера. Несмотря на разницу в методах реализации, большинство вычислительных машин оснащены необходимым аппаратным обеспечением для обработки и хранения информации. В наше время невозможно представить работу какого-либо приложения, хоть игры, хоть сайта, без получения, обработки и записи определённого типа данных. Системы управления базами данных (СУБД) — это высокоуровневое программное обеспечение, работающее с низкоуровневыми API. Для решения различных проблем создавались новые виды СУБД (реляционные, NoSQL и т.д.) и их новые реализации (MySQL, PostgreSQL, MongoDB, Redis и т.д.). В этой статье мы разберемся в основах баз данных и СУБД.

Системы управления базами данных

СУБД — это общий термин, относящийся ко всем видам абсолютно разных инструментов, от компьютерных программ до встроенных библиотек. Эти приложения управляют или помогают управлять наборами данных. Так как эти данные могут быть разного формата и размера, были созданы разные виды СУБД.

СУБД основаны на моделях баз данных — определённых структурах для обработки данных. Каждая СУБД создана для работы с одной из них с учётом особенностей операций над информацией.

Хотя решений, реализующих различные модели баз данных, очень много, периодически некоторые из них становятся очень популярными и используются на протяжении многих лет. Сейчас самой популярной моделью является реляционная система управления базами данных (РСУБД).

Модели баз данных

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

26 мая в 18:00 в 18:00, онлайн, беcплатно

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

Реляционная модель

Представленная в 70-х, реляционная модель предлагает математический способ структуризации, хранения и использования данных. Отношения (англ. relations) дают возможность группировки данных как связанных наборов, представленных в виде таблиц, содержащих упорядоченную информацию (например, имя и адрес человека) и соотносящих значения и атрибуты (его номер паспорта).

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

Несмотря на строгие принципы формирования и обработки данных, РСУБД могут быть весьма гибкими, если приложить немного усилий.

Безмодельный (NoSQL) подход

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

Популярные СУБД

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

РСУБД

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

РСУБД требуют чётких и ясных схем — не стоит путать со специфическим определением для PostgreSQL — для работы с данными. Эти рамки, определённые пользователем, задают способ их хранения и использования. Схемы очень похожи на таблицы, столбцы которых отражают порядковый номер и тип информации в каждой записи, а строки — содержимое этих записей.

Самыми популярными РСУБД сейчас являются:

• SQLite: очень мощная встраиваемая РСУБД.

• MySQL: самая популярная и часто используемая РСУБД.

• PostgreSQL: самая продвинутая и гибкая РСУБД.

NoSQL-СУБД

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

В отличие от традиционных РСУБД, некоторые базы данных NoSQL, например, MongoDB, позволяют группировать коллекции данных с другими базами данных. Такие СУБД хранят данные как одно целое. Эти данные могут представлять собой одиночный объект наподобие JSON и вместе с тем корректно отвечать на запросы к полям.

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

Сравнение SQL и NoSQL

Для того, чтобы прийти к простому и понятному выводу, давайте проанализируем разницу между SQL- и NoSQL-подходами:

• Структура и тип хранящихся данных: SQL/реляционные базы данных требуют наличия однозначно определённой структуры хранения данных, а NoSQL базы данных таких ограничений не ставят.

• Запросы: вне зависимости от лицензии, РСУБД реализуют SQL-стандарты, поэтому из них можно получать данные при помощи языка SQL. Каждая NoSQL база данных реализует свой способ работы с данными.

• Масштабируемость: оба решения легко растягиваются вертикально (например, путём увеличения системных ресурсов). Тем не менее, из-за своей современности, решения NoSQL обычно предоставляют более простые способы горизонтального масштабирования (например, создания кластера из нескольких машин).

• Надёжность: когда речь заходит о надёжности, SQL базы данных однозначно впереди.

• Поддержка: РСУБД имеют очень долгую историю. Они очень популярны, и поэтому получить поддержку, платную или нет, очень легко. Поэтому, при необходимости, решить проблемы с ними гораздо проще, чем с NoSQL, особенно если проблема сложна по своей природе (например, при работе с MongoDB).

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

Что такое NoSQL?

Высокопроизводительные нереляционные базы данных с гибкими моделями данных

Что такое базы данных NoSQL?

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

Как работает база данных NoSQL (нереляционная БД)?

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

Рассмотрим пример моделирования схемы для простой базы данных книг.

• В реляционной базе данных запись о книге часто разделяется на несколько частей (или «нормализуется») и хранится в отдельных таблицах, отношения между которыми определяются ограничениями первичных и внешних ключей. В этом примере в таблице «Книги» имеются столбцы «ISBN», «Название книги» и «Номер издания», в таблице «Авторы» – столбцы «ИД автора» и «Имя автора», а в таблице «Автор–ISBN» – столбцы «Автор» и «ISBN». Реляционная модель создана таким образом, чтобы обеспечить целостность ссылочных данных между таблицами в базе данных. Данные нормализованы для снижения избыточности и в целом оптимизированы для хранения.

• В базе данных NoSQL запись о книге обычно хранится как документ JSON. Для каждой книги, или элемента, значения «ISBN», «Название книги», «Номер издания», «Имя автора и «ИД автора» хранятся в качестве атрибутов в едином документе. В такой модели данные оптимизированы для интуитивно понятной разработки и горизонтальной масштабируемости.

Для чего можно использовать базы данных NoSQL?

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

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

Эволюция NoSQL, основные преимущества перед SQL

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

Проблема масштабируемости SQL была признана интернет-компаниями с огромными растущими потребностями в данных и инфраструктуре, такими как Google, Amazon и Facebook. Они придумали свои собственные решения проблемы – такие технологии, как BigTable, DynamoDB и Cassandra.

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

Во-первых, существовали запатентованные (с закрытым исходным кодом) типы баз данных NoSQL, разработанные крупными компаниями для удовлетворения их конкретных потребностей, такие как Bigtable от Google, которая считается первой системой NoSQL, и DynamoDB от Amazon.

Успех этих проприетарных систем положил начало разработке ряда аналогичных систем баз данных с открытым исходным кодом и проприетарных систем, наиболее популярными из которых являются Hypertable, Cassandra, MongoDB, DynamoDB, HBase и Redis.

Что отличает NoSQL?

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

Это означает, что базы данных NoSQL не имеют фиксированной структуры таблиц, как в реляционных базах данных.

Преимущества NoSQL

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

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

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

Обычно каждое значение в базе данных обозначается ключом. Некоторые хранилища баз данных NoSQL также позволяют разработчикам хранить сериализованные объекты в базе данных, а не только простые строковые значения.

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

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

Недостатки NoSQL баз данных

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

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

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

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

NoSQL против реляционных баз данных

Давайте сравним NoSQL с обычной базой данных:

Записки программиста

Почему эти ваши модные NoSQL решения не так уж хороши

Многие скажут, что сегодня я выступаю в роли Капитана Очевидности, и будут совершенно правы. Тем не менее, в разных мейлинг листах и чятиках то и дело появляются люди с вопросами типа «посоветуйте мне идеальную базу данных, а то у меня SQL тормозит и вообще все говорят, что MongoDB сейчас в моде». C 2007-го года я успел поработать со многими СУБД, не исключая ряда NoSQL решений, и по данному вопросу я имею сказать следующее.

Сразу отмечу несколько моментов:

• Дальше речь идет про базы данных, но те же соображения применимы, например, и в вопросе «простой и понятный Sphinx против типа распределенного из коробки ElasticSearch»;
• Redis и Memcached я отношу к распределенным кэшам, а не базам данных — в редком проекте вы сможете использовать один только Redis;

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

Пробовали Cassandra. Большая проблема с Cassandra заключается в том, что она разрешает конфликты при помощи таймстемпов, хранимых вместе со значениями в столбцах по принципу last write wins. Также Cassandra не поддерживает транзакций (так называемые «микротранзакции» — это всего лишь CAS). Для аналитики все это может быть ОК. При использовании Cassandra в качестве основной СУБД ваши данные очень быстро испортятся, если только вы не написали поверх CAS собственные транзакции, что медленно и на что все поголовно забивают, мол и так прокатит.

Еще большая проблема в Cassandra, что она написана на Java. В комментариях, конечно, скажут, что Java не тормозит. Проблема в том, что это не так. Вот РСУБД иногда ругают, что там нужно прочитать 5 страниц документации и подтюнить 10 параметров, чтобы все хорошо работало. Используя Cassandra с настройками по умолчанию, вы быстро столкнетесь с тем, что база данных иногда отвечает за 1 мс, а иногда — за 200 мс из-за stop the world. Эта проблема решаемая, но путем тюнинга уже около сотни параметров JVM, которые буквально никем не документированы и которые нужно грепать по исходникам этой самой JVM. Та же проблема характерна и для многих других NoSQL решений, написанных на высокоуровневых языках. Внезапно 10 прекрасно документированных параметров в мире РСУБД стали казаться не такой уж большой проблемой, правда?

Наконец, Cassandra использует LSM-tree. Этот способ хранения данных подходит далеко не под все нагрузки. Если вы пишите и удаляете много данных (например, решили использовать Cassandra для хранения очередей), это будет работать очень и очень плохо.

Пробовали Couchbase. В отличие от Cassandra, Couchbase не умеет даже ренджсканы, куда уж там до транзакций. И в отличие от Redis, Couchbase не умеет работать со значениями, как со словарями, массивами или какими-то иными контейнерами. На практике это жутко неудобно, особенно учитывая, что максимальная длина значения в Couchbase ограничивается 20 Мб. То есть, даже просто положить в Couchbase какой-нибудь список контактов с эффективным добавлением и удалением контактов, и так, чтобы они еще и не разъезжались, представляет собой большую проблему. Что еще представляет собой проблему, это автофейловер. Я столкнулся с неприятной ситуацией, когда он успешно отработал, но заново собрать кластер после восстановления упавшего узла никак не удавалось. При этом помочь с проблемой разработчики не особо спешили ни в мейлинг листе, ни в IRC. А починить все самому не представлялось возможным, так как что, где и как хранится — неясно. Как по мне, уж лучше шардировать данные вручную, точно зная, что, где и как лежит, чем использовать такие готовые решения.

Пробовали MongoDB. К счастью, с этой СУБД мне пришлось работать совсем недолго. MongoDB не выдерживает никакой критики, и ее недостатки, похоже, поняли уже все. Вручную шардированный PostgreSQL, который, напомню, уже давно умеет формат JSONB и автофейловер (см Stolon), будет куда более удачным выбором, чем MongoDB. Подробности смотри у Афира и еще, например, вот тут. Выбрав PostgreSQL, вы получите все тоже самое, только куда более стабильное, не теряющее данные, а также с нормальными локами, вьюхами, транзакциями, джоинами и вот этим всем.

Riak почти не пробовали, но много общались с теми, кто пробовал. Решение, видимо, довольно неплохое, при условии, что вас не смущает отсутствие транзакций и вьюх, мешанина из Erlang, Java и С в одном проекте (про Java см выше), необходимость платить деньги, если вы хотите репликацию между ДЦ, а также необходимость писать свою логику для разрешения конфликтов. Последнее представляет большую проблему для типичных веб-программистов, потому что на практике они скорее всего скажут «а чего париться, last write wins и все дела». Также беспокоит, что не так давно в компании-разработчике Basho все из-за чего-то переругались, и программистов, которые реально знали, как работает Riak, в ней, похоже, уже не осталось. Наконец, в качестве бэкенда для Riak обычно используют LevelDB, которому присущи все те же проблемы, что и в случае с Cassandra.

Также немного работали с Tarantool. Насколько я помню, Tarantool был довольно неплох. Думается, потому что в нем как раз нет никакого авторешардинга и автофейловера. В первом приближении, это облегченная РСУБД, целиком живущая в памяти, а также ведущая WAL и периодически делающая снапшоты. Пожалуй, главная проблема с Tarantool заключается в том, что он сравнительно мало распространен, и что вся разработка ведется в Mail.ru для своих задач. Также, будучи in-memory базой данных, Tarantool ближе к решениям вроде Redis, чем к полноценным СУБД. Помимо Tarantool вас также может заинтересовать его форки, например, Octopus.

Еще пара слов про некоторые другие СУБД. Была такая многообещающая СУБД под название FoundationDB. Потом ее купила Apple и СУБД не стало. Завтра точно так же может не стать какого-нибудь еще NoSQL решения. Выглядят многообещающими CockroachDB, RethinkDB и ScyllaDB. Все эти СУБД имеют те или иные недостатки из названных выше. К тому же, на момент написания этих строк, CockroachDB и ScyllaDB являются слишком сырыми, чтобы тащить их в продакшен. RethinkDB выглядит довольно стабильно, но там еще есть своя заморочка с драйверами — нормально использовать эту СУБД можно далеко не из всех языков программирования.

• Иногда говорят глупости вроде «а нам в проекте не нужны транзакции». Если вы не хотите чинить прод в ночь с субботы на воскресенье, вам нужна консистентность данных. А ее очень сложно получить, не имея транзакций. Подумайте, к примеру, о случае, когда вам нужно поменять значения по двум ключам, и приложение падает после изменения первого;
• Люди, которым «не нужны транзакции», видимо, не знают про уровни изоляции в РСУБД. Вы можете не только не использовать транзакции, но и проставить заодно уровень read uncommited, эффективно отказавшись от MVCC. Более того, по умолчанию редкая РСУБД использует по умолчанию (если вообще предоставляет) честный уровень serializable. В PostgreSQL, например, по умолчанию используется read commited, при котором два последовательных SELECT запроса могут увидеть разные данные. Получается забавно — люди хотят отказаться от транзакций, которые они вообще-то и так могут не использовать, и которые они, скорее всего, на самом деле и не использовали вовсе;
• Без нормальных ренджсканов, вьюх, джоинов, данных неограниченного размера и так далее жизнь тоже очень печальна. NoSQL решения попросту убоги по функционалу;
• NoSQL решения недостаточно гибкие. Способы хранения и шардирования данных, фейловера, репликации и так далее почти всегда жестко зашиты в коде и поменять их не представляется возможным. Что намного хуже, способы эти часто документированы либо плохо, либо совсем никак, и потому в случае возникновения проблем самому что-то починить оказывается невозможным;
• С NoSQL связаны высокие риски. Проблемы с драйверами, сырость кода, недостающие инструменты (различные прокси, инструменты резервного копирования и тд), и вообще выбранной вами СУБД завтра может попросту не стать. В мире NoSQL завести совершенно новый API или переписать дисковый бэкенд с нуля — вполне обычное дело, посмотрите на историю развития тех же Riak с Cassandra. См также Десять веских причин не тащить в продакшн новые игрушки;
• Иногда говорят «мы можем терять данные, и нам важна скорость и масштабируемость». Если вы можете терять данные, почему бы тогда не писать их сразу в /dev/null? Это работает очень быстро и просто прекрасно масштабируется;
• Использование Java, Go и прочих высокоуровневых языков, на которых так любят писать NoSQL, к сожалению, приводит к непредсказуемому времени ответа СУБД, и обходится эта проблема весьма нетривиально. Подумайте также про JIT с сопутствующими накладными расходами и вот это все. NoSQL решения весьма прожорливы в плане ресурсов. (Прежде, чем приплетать к этой проблеме autovacuum в мире РСУБД, примите во внимание, что vacuum можно делать по расписанию, когда нагрузка на базу минимальна. Все это, конечно, только если он вам действительно чем-то мешает);
• Никакая СУБД никогда волшебным образом не заработает хорошо из коробки (особенно в виртуалках AWS, особенно в Docker-контейнере, но это уже другая история). Да, ребята, программирование — это сложно, тут иногда приходится думать, иногда даже головой. Есть великое множество способов сделать репликацию, шардинг и автофейловер, ни один из которых не подходит всем и всегда, десятки параметров железа, которые приходится учитывать, и так далее;
• Заметьте также, что NoSQL решения, вообще-то говоря, имеют высокий порог вхождения. Работать с РСУБД умеют вообще все, кто когда-либо что-то делал для веба. Как с ними работать из любимого языка программирования, как проектируется схема БД, как производить миграции, как делать бекапы и восстанавливаться из них, как все это правильно мониторить и так далее — это всем давно известно. А вот найти человека, реально умеющего работать с какой-нибудь Cassandra, не так-то и просто;
• Забыл сказать, что в мире NoSQL вас ждет огромное количество маркетингового булшита с подогнанными невоспроизводимыми бенчмарками, пятью «новостями» за неделю в казалось бы технических блогах типа «еще 15 причин использовать для всего наш MapReduce в Docker-контейнере», при условии, что MapReduce и другой притянутый за уши функционал не работает нормально ни в одном из названных выше NoSQL решений, и так далее. Вам вообще хочется в этом всем вариться?

Тогда что же выбрать в качестве основной СУБД для нового проекта? Совет стандартный — возьмите любую РСУБД по вкусу. Если конкретнее, то я бы рекомендовал PostgreSQL, но в крайнем случае и какая-нибудь MariaDB, пожалуй, будет как минимум не хуже Монги. Затем масштабируйтесь вертикально до тех пор, пока это позволяет кошелек. Может так получиться, что для всего проекта вам будет достаточно одного сервера, плюс еще одной реплики для фейловера. Если это ваш случай, то вам крупно повезло, поздравляю! Иначе все тоже не так уж плохо, так как обычно 90% операций идут только на чтение, и их можно спокойно распределить по множеству реплик.

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

NoSQL

NoSQL – это подход к реализации масштабируемого хранилища (базы) информации с гибкой моделью данных, отличающийся от классических реляционных СУБД. В нереляционных базах проблемы масштабируемости (scalability) и доступности (availability), важные для Big Data, решаются за счёт атомарности (atomicity) и согласованности данных (consistency) [1].

Зачем нужны нереляционные базы данных в Big Data: история появления и развития

NoSQL-базы оптимизированы для приложений, которые должны быстро, с низкой временной задержкой (low latency) обрабатывать большой объем данных с разной структурой [2]. Таким образом, нереляционные хранилища непосредственно ориентированы на Big Data. Однако, идея баз данных такого типа зародилась гораздо раньше термина «большие данные», еще в 80-е годы прошлого века, во времена первых компьютеров (мэйнфреймов) и использовалась для иерархических служб каталогов. Современное понимание NoSQL-СУБД возникло в начале 2000-х годов, в рамках создания параллельных распределённых систем для высокомасштабируемых интернет-приложений, таких как онлайн-поисковики [1].

Вообще термин NoSQL обозначает «не только SQL» (Not Only SQL), характеризуя ответвление от традиционного подхода к проектированию баз данных. Изначально так называлась опенсорсная база данных, созданная Карло Строззи, которая хранила все данные как ASCII-файлы, а вместо SQL-запросов доступа к данным использовала шелловские скрипты [3]. В начале 2000-х годов Google построил свою поисковую систему и приложения (GMail, Maps, Earth и прочие сервисы), решив проблемы масштабируемости и параллельной обработки больших объёмов данных. Так была создана распределённые файловая и координирующая системы, а также колоночное хранилище (column family store), основанное на вычислительной модели MapReduce. После того, как корпорация Google опубликовала описание этих технологий, они стали очень популярны у разработчиков открытого программного обеспечения. В результате этого был создан Apache Hadoop и запущены основные связанные с ним проекты. Например, в 2007 году другой ИТ-гигант, Amazon.com, опубликовав статьи о своей высокодоступной базе данных Amazon DynamoDB. Далее в эту гонку NoSQL- технологий для управления большими данными включилось множество корпораций: IBM, Facebook, Netflix, eBay, Hulu, Yahoo! и другие ИТ-компаний со своими проприетарными и открытыми решениями [1].

Многообразие NoSQL-решений

Какие бывают NoSQL-СУБД: основные типы нереляционных баз данных

Все NoSQL решения принято делить на 4 типа:

1. Ключ-значение (Key-value) – наиболее простой вариант хранилища данных, использующий ключ для доступа к значению в рамках большой хэш-таблицы [4]. Такие СУБД применяются для хранения изображений, создания специализированных файловых систем, в качестве кэшей для объектов, а также в масштабируемых Big Data системах, включая игровые и рекламные приложения, а также проекты интернета вещей (Internet of Things, IoT), в т.ч. индустриального (Industrial IoT, IIoT). Наиболее известными представителями нереляционных СУБД типа key-value считаются Oracle NoSQL Database, Berkeley DB, MemcacheDB, Redis, Riak, Amazon DynamoDB, которые поддерживают высокую разделяемость, обеспечивая беспрецедентное горизонтальное масштабирование, недостижимое при использовании других типов БД [2].
2. Документно-ориентированное хранилище, в котором данные, представленные парами ключ-значение, сжимаются в виде полуструктурированного документа из тегированных элементов, подобно JSON, XML, BSON и другим подобным форматам [4]. Такая модель хорошо подходит для каталогов, пользовательские профилей и систем управления контентом, где каждый документ уникален и изменяется со временем [2]. Поэтому чаще всего документные NoSQL-СУБД используются в CMS-системах, издательском деле и документальном поиске. Самые яркие примеры документно-ориентированных нереляционных баз данных – это CouchDB, Couchbase, MongoDB, eXist, Berkeley DB XML [1].
3. Колоночное хранилище, которое информацию в виде разреженной матрицы, строки и столбцы которой используются как ключи. В мире Big Data к колоночным хранилищам относятся базы типа «семейство столбцов» (Column Family). В таких системах сами значения хранятся в столбцах (колонках), представленных в отдельных файлах. Благодаря такой модели данных можно хранить большое количество атрибутов в сжатом виде, что ускоряет выполнение запросов к базе, особенно операции поиска и агрегации данных [4]. Наличие временных меток (timestamp) позволяет использовать такие СУБД для организации счётчиков, регистрации и обработки событий, связанных со временем: системы биржевой аналитики, IoT/IIoT-приложения, систему управления содержимым и т.д. Самой известной колоночной базой данных является Google Big Table, а также основанные на ней Apache HBase и Cassandra. Также к этому типу относятся менее популярные ScyllaDB, Apache Accumulo и Hypertable [1].
4. Графовое хранилище представляют собой сетевую базу, которая использует узлы и рёбра для отображения и хранения данных [4]. Поскольку рёбра графа являются хранимыми, его обход не требует дополнительных вычислений (как соединение в SQL). При этом для нахождения начальной вершины обхода необходимы индексы. Обычно графовые СУБД поддерживают ACID-требования и специализированные языки запросов (Gremlin, Cypher, SPARQL, GraphQL и т.д.) [1]. Такие СУБД используются в задачах, ориентированных на связи: социальные сети, выявление мошенничества, маршруты общественного транспорта, дорожные карты, сетевые топологии [3]. Примеры графовых баз: InfoGrid, Neo4j, Amazon Neptune, OrientDB, AllegroGraph, Blazegraph, InfiniteGraph, FlockDB, Titan, ArangoDB.

Виды NoSQL-СУБД

Чем хороши и плохи нереляционные базы данных: главные достоинства и недостатки

По сравнению с классическими SQL-базами, нереляционные СУБД обладают следующими преимуществами:

• линейная масштабируемость – добавление новых узлов в кластер увеличивает общую производительность системы [1];
• гибкость, позволяющая оперировать полуструктирированные данные, реализуя, в. т.ч. полнотекстовый поиск по базе [2];
• возможность работать с разными представлениями информации, в т.ч. без задания схемы данных [1];
• высокая доступность за счет репликации данных и других механизмов отказоустойчивости, в частности, шаринга – автоматического разделения данных по разным узлам сети, когда каждый сервер кластера отвечает только за определенный набор информации, обрабатывая запросы на его чтение и запись. Это увеличивает скорость обработки данных и пропускную способность приложения [5].
• производительность за счет оптимизации для конкретных видов моделей данных (документной, графовой, колоночной или «ключ‑значение») и шаблонов доступа [2];
• широкие функциональные возможности – собственные SQL-подобные языки запросов, RESTful-интерфейсы, API и сложные типы данных, например, map, list и struct, позволяющие обрабатывать сразу множество значений [2].

Обратной стороной вышеуказанных достоинств являются следующие недостатки:

• ограниченная емкость встроенного языка запросов [5]. Например, HBase предоставляет всего 4 функции работы с данными (Put, Get, Scan, Delete), в Cassandra отсутствуют операции Insert и Join, несмотря на наличие SQL-подобного языка запросов. Для решения этой проблемы используются сторонние средства трансляции классических SQL-выражений в исполнительный код для конкретной нереляционной базы. Например, Apache Phoenix для HBase или универсальный Drill.
• сложности в поддержке всехACID-требований к транзакциям (атомарность, консистентность, изоляция, долговечность) из-за того, что NoSQL-СУБД вместо CAP-модели (согласованность, доступность, устойчивость к разделению) скорее соответствуют модели BASE (базовая доступность, гибкое состояние и итоговая согласованность) [1]. Впрочем, некоторые нереляционные СУБД пытаются обойти это ограничение с помощью настраиваемых уровней согласованности, о чем мы рассказывали на примере Cassandra. Аналогичным образом Riak позволяет настраивать требуемые характеристики доступности-согласованности даже для отдельных запросов за счет задания количества узлов, необходимых для подтверждения успешного завершения транзакции [1]. Подробнее о CAP-и BASE-моделях мы расскажем в отдельной статье.
• сильная привязка приложения к конкретной СУБД из-за специфики внутреннего языка запросов и гибкой модели данных, ориентированной на конкретный случай [5];
• недостаток специалистов поNoSQL-базам по сравнению с реляционными аналогами [5].

Подводя итог описанию основных аспектов нереляционных СУБД, стоит отметить некоторую некорректность запроса «NoSQL vs SQL» в связи с разными архитектурными подходами и прикладными задачами, на которые ориентированы эти ИТ-средства. Традиционные SQL-базы отлично справляются с обработкой строго типизированной информации не слишком большого объема. Например, локальная ERP-система или облачная CRM. Однако, в случае обработки большого объема полуструктурированных и неструктурированных данных, т.е. Big Data, в распределенной системе следует выбирать из множества NoSQL-хранилищ, учитывая специфику самой задачи. В частности, для самостоятельных решений интернета вещей (Internet of Things), в т.ч. промышленного, отлично подходит Cassandra, о чем мы рассказывали здесь. А в случае многоуровневой ИТ-инфраструктуры на базе Apache Hadoop стоит обратить внимание на HBase, которая позволяет оперативно, практически в режиме реального времени, работать с данными, хранящимися в HDFS.

Нереляционные СУБД находят больше областей приложений, чем традиционные SQL-решения

NoSQL убивает SQL?

На прошлой неделе мой друг переслал мне письмо от успешного предпринимателя, который утверждает, что “SQL мёртв”.

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

Я был совершенно шокирован этим письмом: как он пришёл к настолько неверному выводу? Но в то же время мне стало любопытно… Возможно ли, что другие люди так же дезинформированы? Предпринимателя поддержали многие, он был весьма искренен — неужели новые специалисты по данным получают совет избегать SQL?

Поэтому я решил публично написать свой ответ этому предпринимателю в случае, если кто-то ещё верит в то, что SQL грозит вымирание .

Вам абсолютно точно стоит изучать SQL, если вы строите свою карьеру в науке о данных! NoSQL не влияет на ценность изучения SQL.

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

Причина №1: NoSQL базы данных не заменят аналитические, такие как Presto, Redshift или BigQuery.

Независимо от того, используют ваши приложения SQL-бэкенд (например, MySQL) или NoSQL-бэкенд (MongoDB и т.д.), данные из бэкенда в конечном счете будут загружены в специализированные аналитические базы данных, такие как Redshift, Snowflake, BigQuery или Presto.

Зачем компании перемещают свои данные в специализированные колоночные хранилища вроде Redshift? Потому что колоночные хранилища способны запускать аналитические запросы значительно быстрее, чем NoSQL или строчные базы данных вроде MySQL. Готов поспорить, что популярность колоночных хранилищ будет расти так же быстро, как популярность NoSQL баз данных.

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

Причина №2: преимущества баз данных NoSQL не в том, что они не поддерживают язык SQL.

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

Тогда почему колоночные хранилища намеренно выбирают SQL интерфейс?

Это происходит потому, что SQL невероятно силён в выражении инструкций манипулирования данными.

Рассмотрим простой пример запроса, который считает количество документов в наборе из NoSQL базы данных MongoDB.

Примечание: документы в MongoDB аналогичны строкам, а наборы — таблицам.

Сравним с эквивалентом SQL:

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

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

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

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