NoSQL подход в хранении данных

Введение

В данной статье описан иной, отличающийся от классического RDBMS, подход хранения данных — NoSQL. Описаны их общие отличительные характеристики — ACID, BASE, детали и требования к каждому типу базы данных (БД). Раскрываются типы NoSQL баз, приводятся примеры (реализации) каждого из типов и области их применения. Анализируется несколько видов модели: “один ко многим”, “многие к одному”, — и происходит обоснование для какой модели лучше применять RDBMS или NoSQL решение.

Сравнение NoSQL и RDBMS подхода

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

Основные причины внедрения баз данных NoSQL:

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

Не смотря на обилие реализаций NoSQL, основные отличия от классических RDBMS решений таковы:

Виды NoSQL решений

В зависимости от модели данных, подходов к распределенности репликации, можно выделить несколько типов хранилищ:

БД на основе пар “ключ-значение”. Это тип NoSQL базы, в которой данные хранятся как совокупность пар “ключ-значение”. Ключ является уникальным идентификатором. Ключи и значения могут представлять собой любую простую, сложную составную или байтовую информацию (изображения). Этот тип БД имеет большие возможности для горизонтального масштабирования. Примеры БД — DynamoDB, Cassandra, Redis, Riak.
Документоориентированная БД. Этот тип БД предназначен для хранения иерархических структур данных в виде документов, которые легко поддаются чтению человеком (например, JSON). В документной базе нет четкого регламента на схемы документов — документы могут иметь одинаковую или разную структуру. Примеры БД — CouchDB, Couchbase, MongoDB.
Графовые БД. Эти БД применяются для тех задач, где необходимо хранить и отслеживать взаимосвязи. В графовых БД основными элементами являются узлы и связи (ребра). Узлы используются для хранения сущностей, а ребра — для хранения взаимосвязей между сущностями. Работа с БД представляет собой обход определённых типов ребер или всего графа целиком, что происходит очень быстро по причине хранения этой информации в ребрах. Пример использования — соц. сети, сервисы выявления фрода. Примеры графовых БД — Neo4j, Neptune, AllegroGraph.
Поисковые БД. Эти БД используют индексы для классификации общих характеристик для поступающих данных и основная цель этих БД — содействовать быстрому поиску. Поисковые БД оптимизированы для работы (поиска) с информацией, которая может быть велика и быть плохо структурирована. Обычно эти БД предоставляют методы для простого поиска по тексту, по регулярным выражениям и определенную обработку результатов поиска. Примеры БД — Elasticsearch, Splunk.

Проблема выбора: RDBMS или NoSQL. Что выбрать?

Проиллюстрируем возможность выражать некий объект, например, “резюме” — на языке реляционной схемы.

Профиль в целом определяется уникальным идентификатором user_id. Такие поля, как first_name и last_name, встречаются ровно один раз для одного пользователя, так что их можно сделать столбцами в таблице users.

Однако у большинства людей за время карьеры бывает больше одной работы (должности), а также могут меняться периоды обучения и число элементов контактной информации. Между пользователем и этими элементами существует связь “один-ко-многим”. В SQL-модели, в случае наиболее распространенного нормализованного представления “должности”, “образование” и “контактная информация” помещаются в отдельные таблицы со ссылкой на таблицу users в виде внешнего ключа, как показано на Рисунке 1. “Представление профиля”.

Для структур данных типа “резюме”, обычно являющихся самостоятельным документом, вполне подойдет представление в формате JSON.

Пример 1. Представление профиля в виде JSON документа:

{
  "user_id": 251,
  "first_name": "Bill",
  "last_name": "Gates",
  "summary": "Co-chair of the Gates Foundation",
  "region_id": "us:91",
  "industry_id": 131,
  "photo_url": "/p/7/000/253/05b/308dd6e.jpg",
  "positions": [
    {
      "job_title": "Co-chair",
      "organization": "Gates Foundation"
    },
    {
      "job_title": "Co-founder, Chairman",
      "organization": "Microsoft"
    }
  ],
  "education": [
    {"school_name": "Harvard University"},
    {"school_name": "Lakeside School"}
  ]
}

Преимущество данного формата в том, что он намного проще, чем XML, и удобно читаем для человека. Эту модель данных поддерживают документоориентированные БД, такие как Couchbase. У JSON-представления лучшая локальность, чем у многотабличной схемы (см. Рисунок 1. “Представление профиля”).

Для извлечения профиля в реляционном примере необходимо выполнить несколько запросов (по запросу к каждой таблице по user_id) или запутанное многостороннее соединение (Join) таблицы users с подчиненными ей таблицами.

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

Рисунок 1. Представление профиля

На Рисунке 1. “Представление профиля” поля region_id и industry_id представляют собой ссылки на внешние таблицы (foreign key), а не текстовые строки вроде “Seattle Area” или “Philanthropy”.
Сделано это по нескольким причинам:

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

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

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

Заключение

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

Скорость. NoSQL базы данных обычно быстрее, а иногда намного быстрее, когда дело доходит до записи. Операции чтения также могут быть довольно быстрыми в зависимости от того, какую именно БД вы используете.
Требуется хранить большие объемы неструктурированных данных.
Безсхемная разработка. Реляционные СУБД требуют четко описанную структуру данных до начала работы. NoSQL решения предлагают более гибкие решения.
Автоматизированная (или очень простая) репликация/масштабирование. NoSQL базы данных быстро развиваются — разработчики активно решают основные проблемы, одна из которых — репликация и масштабирование. В отличии от реляционных СУБД, NoSQL решения легко масштабируются и работают с кластерами.
Наличие лишь связей one-to-one и one-to-many между сущностями.
Экономия на подписке и поддержке, так как большинство NoSQL БД являются open source проектами.

Используемые ресурсы

http://nosql-database.org/
https://www.couchbase.com/products/server
https://habr.com/post/152477/
https://ru.wikipedia.org/wiki/NoSQL