NoSQL и его возможности

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

В двух словах NoSQL - это необходимость выбора в рамках проекта двух из трех принципов работы с БД: согласованность данных (Consistency), доступность (Availability), устойчивость к разделению (Partition tolerance).

Причина такой необходимости - новые бизнес-задачи, которые возникли в последнее время:

• База должна быть всегда доступна для записи и чтения, и кейсы типа: сервер перезагружается, сеть упала - становятся критичными для бизнеса.
• Интенсивный рост объемов данных и ужесточение требований к их доступности, в том числе из-за бурного развития всемирной сети (в одной базе данные просто перестали помещаться).
• Клиентов становится много в разных точках мира, и нужно сохранить заказы как можно быстрее.
• Бурный рост веб-сервисов, появление мобильных устройств.

В техническом плане эти требования означают, что база должна:

• быть доступна всегда, нельзя потерять заказ клиента или его корзину, даже если пропала синхронизация между нодами базы данных.
• быть доступна везде (Европе и США), и, конечно, синхронизировать данные между копиями.
• неограниченно масштабироваться при увеличении объема данных.
• масштабироваться под нагрузку: на запись, на чтение.

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

• Oracle RAC - дорого и сложно, тяжеловесно, и непонятно, как раскидывать по разным материкам.
• MySQL cluster - быстрый мастер-мастер, но много подводных камней и ограничений вроде хранения данных только в памяти. Всё же достаточно удобен для некоторых кейсов.
• galera cluster for mysql - честный мастер-мастер, пиши куда хочешь (но должен знать, куда именно). Нет "устойчивости к разделению", может зависнуть при отсутствии кворума. Трудно восстанавливается при падении и тормозит при геораспределенном использовании, т.к. синхронно передает данные на все копии. Нет шардинга данных между мастерами.

Так вот, прошло не так много времени, как в начале нынешнего столетия появились NoSQL-продукты и стало возможным:

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

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

  Ограничения NoSQL

Но и у NoSQL есть свои ограничения.

• NoSQL позволяет писать на любую ноду кластера, но по умолчанию читать приходится устаревшую неконсистентную информацию, так как информация распространяется с ограниченной скоростью. NoSQL-продукты предоставляют опцию чтения только что записанной информации, но за это придется платить увеличением времени ожидания.
• NoSQL позволяет разместить ноды кластера на разных материках, но так как информации нужно время, чтобы она разошлась по континентам, то приложение должно уметь это обработать.
• NoSQL позволяет выключать любую ноду кластера, но устойчивость к разделению кластера реализована за счет технологий, похожих на версионность. Следовательно, периодически нужно будет запускать поиск рассогласований типа Anti-entropy using Merkle trees.
• NoSQL позволяет добавлять ноды кластера по необходимости, но конфигурировать остальные ноды все-таки придется, и иногда это совсем не просто сделать.

Это общие для продуктов NoSQL ограничения. Но есть нюансы и в использовании конкретных реализаций. Рассмотрим их на примере Amazon DynamoDB (очень похожий на Apache Cassandra.)

Ограничения Amazon DynamoDB:

• Мало типов данных: число, строка, бинарные данные. Нет DATETIME (их можно эмулировать таймстампом).
• Ограничения по индексам. Индексы нужно указать сразу, их должно быть не более 5 на таблицу. Причем добавлять их в существующую таблицу нельзя, нужно ее удалять, пересоздавать и перезаливать туда данные.
• Можно хранить любой объем данных, но размер одной "строки таблицы" с именами и значениями "колонок" не должен превышать 64КБ. Правда число "колонок" не ограничивается. И на одной ноде кластера (c одним значением основного индекса hash key) при наличии дополнительных индексов нельзя хранить больше 10ГБ. (Термин "колонока" - условный. В NoSQL нередко понятия схемы данных просто нет, поэтому в каждой "строке таблицы" могут быть разные "колонки" или "атрибуты".)
• Запросы. Можно выбрать данные только по одному индексу. Есть еще основной (hash key) индекс, но диапазонные выборки делать по нему нельзя - только константные. Отсортировать можно только по одному индексу.

  Нельзя использовать сложные WHERE, GROUP BY, не говоря уже о подзапросах: NoSQL-движки их просто эмулируют и могут выполнять очень медленно.

  Можно выполнять более сложные выборки, но методом полного сканирования таблицы (table scan) и затем поэлементной фильтрации результатов на серверной стороне, что и долго и дорого.

• Транзакции: гарантируется лишь атомарное обновление отдельных сущностей. (Есть, правда, приятные возможности с чтениями/инкрементами за одну операцию). Так что транзакции придется эмулировать: данные разнесены по 20 серверам/дата-центрам всего земного шара.
• Атрибуты. Нередко в NoSQL, в том числе в DynamoDB можно использовать что-то типа:

  user=john blog_post_$ts1=12 blog_post_$ts2=33 blog_post_$ts3=69

  где $ts1-3 - таймстампы публикаций пользователя в блог. Это позволяет получить список публикаций за один запрос. Но работа программиста увеличивается.

  Варианты подходов NoSQL

CA - согласованность данных (Consistency) и доступность (Availability)

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

Такие системы возможны на основе технологического программного обеспечения, поддерживающего транзакционность в смысле ACID. Примерами таких систем могут быть решения на основе кластерных систем управления базами данных или распределённая служба каталогов LDAP.

CP - согласованность данных (Consistency) и устойчивость к разделению (Partition tolerance)

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

AP - доступность (Availability), устойчивость к разделению (Partition tolerance)

Распределённая система, отказывающаяся от целостности результата. Большинство NoSQL-систем принципиально не гарантируют целостности данных. Задачей при построении AP-систем становится обеспечение некоторого практически целесообразного уровня целостности данных, в этом смысле про AP-системы говорят как о "целостных в конечном итоге" (eventually consistent) или как о "слабо целостных" (weak consistent). Наиболее распространённые системы.

  Выводы

Прежде чем выбирать для проекта NoSQL хранилище, оцените все возможные призы и риски:

1. NoSQL - это часто не что иное, как набор memcached-подобных серверов с надстроенной довольно простой логикой и, соответственно, сохранение данных и простые выборки будут действительно быстрыми. В случае более сложных запросов задачу придется решать на стороне приложения.
2. Помните, что по теореме Брюера при реализации придётся выбирать не более двух из трёх свойств: согласованность данных, их доступность и устойчивость к разделению.
3. Внимательно изучить документацию по используемому продукту, особенно ограничения, к которым нужно будет аккуратно подготовиться.
4. NoSQL создает ложное впечатление, что можно не знать принципы работы SQL. На самом деле, нужно хорошо понимать классическую реляционную теорию, чтобы предвидеть развитие модели данных приложения в NoSQL, угадать варианты денормализации, чтобы приложение не пришлось потом несколько раз переписывать.

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