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

3.1. Слабые ACID свойства

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

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

Это называется eventual consistency и с ним работают крупные компании, включая Facebook и Amazon. Они говорят, что максимальный интервал, в течение которого пользователи могут видеть неконсистентные данные составляет не более секунды. Пример такой ситуации показан на рисунке:

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

Например, разработчик финансовой банковской системы сказал: «Если бы мы действительно ждали завершения каждой транзакции в сети банкоматов, клиенты убегали бы в ярости. Что происходит, если вы и ваш партнер одновременно снимаете деньги и превышаете лимит? Вы оба получите свои деньги, а мы поправим это позже».

На картинке показано бронирование гостиниц. Онлайн-магазины, которые используют eventual consistency, должны предусмотреть меры для решения случаев конфликта (автоматическое решение, откат операции или обновление данных). В реальности гостиницы всегда держат «запас» свободных номеров для непредвиденных ситуаций, чтобы решать проблемы.

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

3.2. Распределенные системы, без совместно используемых ресурсов (share nothing)

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

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

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

Ниже приведены основные характеристики распределенных NoSQL баз данных:

Репликация позволяет копировать данные на другие узлы при обновлении. Она помогает увеличить масштабируемость, а также повысить доступность и сохранность данных. Репликация может быть двух типов:

master-slave:

peer-to-peer:

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

Шардинг — разделение данных по узлам:

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

3.3. NoSQL базы в-основном оупенсорсные и созданы в 21 столетии

Садаладж и Фаулер не классифицировали объектные базы данных как NoSQL, так как они были созданы еще в 1990-х и не приобрели большую популярность. Однако, на сайте NoSQL Database они включены в общий список.

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

3.4. Обзор mongoDB

MongoDB — это кроссплатформенная и распределенная база данных на основе документов (document-oriented) с открытым исходным кодом, предназначенная для упрощения разработки и масштабирования приложений.

База данных MongoDB создана для хранения огромных объемов данных и при этом работать быстро. В ней нет таблиц, строк и столбцов, как в других базах данных SQL (RDBMS). Данные хранятся в коллекциях как документы на основе JSON, называемом BSON.

Ссылки:

• Интерактивное руководство
• Нереляционные данные и базы данных NoSQL
• Что такое базы данных NoSQL?
• Как устроена apache cassandra
• MongoDB vs Cassandra

3.5. Redis

Redis (Remote Dictionary Server) — это open source сервер баз данных типа ключ-значение. Эго часто называют сервером структур данных. Это означает, что Redis обеспечивает доступ к изменяемым структурам данных через набор команд, которые отправляются с использованием модели сервер-клиент с TCP-сокетами и простым протоколом. Таким образом, разные процессы могут запрашивать и изменять одни и те же структуры данных общим способом.