ДжазТим — надежный технологический партнер

Agile разработка ПО на Java

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

Введение

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

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

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

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

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

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

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

Проблема выбора: 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 базы данных являются более оптимальным решением, если ваши требования к БД:

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

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