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