NoSQL базы данных: основные виды и их отличия для системного аналитика

Когда речь заходит о хранении данных, есть два основных подхода — реляционные и нереляционные базы данных. Главное отличие между ними заключается в модели организации данных.

В реляционных базах данных используются таблицы. Каждая таблица представляет собой набор строк и столбцов, описывающих один тип объектов.

Таблицы могут быть связаны между собой через общие поля, образуя отношения (реляции). Для управления ими используются Системы управления базами данных (СУБД). Это программное обеспечение, которое позволяет добавлять, обновлять, читать и удалять данные с помощью запросов на языке SQL (Structured Query Language).

В нереляционных базах данных применяется иерархическая структура. Такие базы данных также называют NoSQL («не только SQL» или «без SQL»).

Реляционные системы имеют долгую историю успешного применения. Они основаны на математическом фундаменте, а строгие правила проектирования помогают избегать проблем, таких как несогласованность данных. Тогда почему такие гиганты, как Google, Amazon и Cisco, обратились к нереляционным базам данных? Чтобы ответить на этот вопрос, рассмотрим:

• Какие характеристики систем управления данными важны для анализа;
• Основные типы NoSQL-решений;
• Как выбрать подходящую СУБД.

Ключевые характеристики систем управления данными

В зависимости от требований конкретного приложения, приоритет характеристик может меняться. Мы рассмотрим

• Масштабируемость
• Гибкость
• Доступность
• Надежность

Масштабируемость

Масштабируемость — это способность системы эффективно справляться с рабочими нагрузками.

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

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

Справедливости ради заметим, что горизонтальное масштабирование СУБД на SQL также используется, а облачные базы данных значительно упрощают настройку.

Стоит также отметить, что ряд сравнительных тестов MongoDB (NoSQL) и PostgreSQL (SQL) не показали существенной разницы в скорости выполнения запросов.

Гибкость

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

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

Доступность

Многие веб-приложения должны быть доступны круглосуточно. Если база данных работает на одном сервере и он выходит из строя, приложение становится недоступным. Хотя можно использовать резервные серверы, это часто неэффективно.

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

Надежность

Реляционные базы данных имеют жесткую структуру и следуют модели согласованности ACID (Atomicity, Consistency, Isolation, Durability), где приоритет отдаётся согласованности над доступностью. Если транзакция завершается с ошибкой, вся операция отменяется.

NoSQL-решения более гибкие и придерживаются модели BASE (Basically Available, Soft state, Eventually consistent), которая приоритезирует доступность над согласованностью. Это делает их более масштабируемыми, но менее надежными для транзакций.

ACID — приоритет согласованности над доступностью. Если на любом этапе транзакции возникает ошибка, вся операция отменяется.

BASE — наоборот, приоритет доступности над согласованностью.

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

Выделяют четыре основных типа NoSQL:

• Базы данных «ключ — значение» (key-value databases)
• Документоориентированные базы данных (document databases)
• Колоночные базы данных (column family store databases)
• Графовые базы данных (graph databases)

Базы данных «ключ — значение»

Это самый простой тип нереляционных баз данных, который хранит данные в виде пар «ключ-значение».

Ключ — уникальный идентификатор, а значение — сами данные.

Это решение идеально подходит для кэширования и быстрого поиска, так как оно оптимизировано для операций CRUD (Create, Read, Update, Delete) и хорошо масштабируется горизонтально. Однако этот тип не подходит для сложных запросов или транзакций.

Примером ключей могут служить номер билета, заказа, артикул товара, номер сессии пользователя и т.д. Ключи упрощают и ускоряют работу с данными.

Важно помнить, что ключи должны быть уникальными.

Значения — это данные, хранящиеся вместе с ключами.

Значения могут быть как простыми строками (имя, название) или числами (количество товаров в заказе) так и более сложными типами, например, изображениями или двоичными объектами. Для последнего используется тип BLOB (Binary Large Object/двоичный большой объект).

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

• Обладают самой простой архитектурой среди нереляционных БД;
• Хорошо оптимизированы для поиска по ключу или диапазону ключей, поэтому эффективны для кэширования и быстрого поиска по словарям;
• Оптимизированы для простых операций CRUD (Create, Read, Update, Delete);
• Хорошо масштабируются горизонтально, так как могут легко распределять данные между несколькими узлами на разных машинах. А значит, способны обеспечить очень высокую скорость манипулирования данными.

• Не предназначены для сложных запросов, например, объединение таблиц или фильтрация;
• Менее гибкие при индексировании и запросах данных, чем другие типы БД.

Варианты использования:

• Кеширование данных (в том числе и данных от основной СУБД)
• Хранение и извлечение информации о сеансе для веб-сайтов. Каждый сеанс имеет уникальный «Ключ» (идентификатор сессии), а данные о сеансе хранятся в «Значении» в объекте, например, имеющим тип BLOB.
• Хранение пользовательских профилей, корзин в интернет-магазинах и т.д.
• БД «Ключ-Значение» не подойдут в качестве основной СУБД в системах с большим количеством связанных сущностей, и в системах, требующих высокой согласованности данных. Также они не подойдут для систем, в которых требуются запросы на основе значений, а не ключей, и для систем, где изменение данных подразумевает использование транзакций.

Примеры СУБД: Redis, Amazon DynamoDB, Cassandra, Oracle NoSQL Database.

Документоориентированные базы данных

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

Документы — это полуструктурированные сущности в формате JavaScript Object Notation (JSON) или Extensible Markup Language (XML). Как и другие NoSQL базы данных они не требуют строгой схемы, благодаря чему можно хранить документы с совершенно разными структурами.

Вместо объединения (как это делалось бы в реляционных базах данных) используется вложение документов или списков значений в документ.

В отличие от баз данных «ключ — значение», которые хранят ключ для каждого атрибута сущности, документоориентированные базы данных хранят несколько атрибутов в одном документе.

Еще одно важное преимущество этого типа перед базами данных «ключ — значение» заключается в том, что данные можно получить не только по ключу, но и по значениям.

• Обладают большой гибкостью, документы могут быть совершенно разными и не повторять одну схему;
• Подходят для индексирования и поисковых или аналитических запросов по содержимому документов;
• Эффективны при работе с операциями CRUD (Create, Read, Update, Delete);
• Оптимизированы под JSON и RESTful APIs;
• Хорошо масштабируются горизонтально и распределяют данные по узлам по уникальному ключу в документе.

Варианты использования:

• Регистрация событий (логирование), где все информация о событии представлена в виде документа.
• Хранение данных для онлайн-блогов, где каждый пользователь, сообщение, лайк и комментарий представлены в виде отдельных документов.
• Применяется в Системах управления содержимым (CMS) для хранения документов, изображений и пользовательских данных. 
• А также в электронной коммерции для эффективного управления каталогами товаров.

Однако документно-ориентированные БД по-прежнему не подойдут для транзакций.

Примеры СУБД: MongoDB, Amazon DocumentDB, CouchDB, Google Firestore.

Колоночные базы данных

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

Столбец — состоит из названия и значения (иногда еще добавляют временную метку).

Набор столбцов образует строку. При этом в разных строках могут быть разные столбцы.

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

Колоночные базы данных предназначены для строк с большим количеством столбцов. Нередко базы данных семейства столбцов поддерживают миллионы столбцов.

В них все так же отсутствует заранее определенная схема и возможность объединения таблиц. Однако запросы могут походить на SQL из-за поддержки SELECT, INSERT, UPDATE и DELETE.

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

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

Варианты использования:

• В приложениях интернета вещей (IoT) для работы с большим объемом данных и анализа временных рядов. 
• В приложениях, которые хранят и анализируют действия пользователей.

Примеры СУБД: Apache Cassandra, ScyllaDB, HBase.

Графовые базы данных

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

Узлы представляют сущности (например, люди или города), а отношения – связи, в атрибутах которых также может хранится информация (например, о взаимосвязях людей или расстоянии между городами).

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

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

• Эффективны для запросов, связанных с отношениями;
• Совместимы с ACID-транзакциями;
• Эффективны для работы с данными, где требуется применение математических алгоритмов в сочетании с обходом графов.

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

Варианты использования:

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

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

Примеры СУБД: Neo4j, Amazon Neptune.

Как выбрать подходящую базу данных?

Реляционные базы данных создавались для систем с сотнями пользователей, но с развитием веб-приложений потребовалась поддержка десятков тысяч и более. NoSQL-решения появились как ответ на эти новые требования.

На практике NoSQL-базы чаще всего используются для конкретных задач, в то время как реляционные остаются основным хранилищем для структурированных данных.

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

• Документоориентированная БД — для управления профилями пользователей.
• Колоночная БД — для хранения действий пользователей.
• Ключ-значение — для кэширования и управления сеансами.
• Графовая БД — для взаимосвязей (друзья, посты).

Чтобы выбрать подходящую СУБД, необходимо учесть тип данных и назначение системы. Для структурированных данных и транзакций подойдут реляционные базы данных (MySQL, PostgreSQL), а для полуструктурированных данных и специализированных задач — NoSQL-решения.

Также часто используются сочетания разных типов БД NoSQL. Например, возьмем социальную сеть:

• Управление профилями пользователей — Документно-ориентированная БД
• Хранение информации о действиях пользователей — Колоночная БД
• Управление сеансами и кеширование — БД «Ключ-Значение»
• Хранение информации о друзьях, постах, комментариях и лайках — Графовая БД

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

Для структурированных данных и при необходимости выполнения ACID-транзакций лучше использовать реляционные базы данных (например, MySQL, PostgreSQL, Oracle, SQL Server и другие).

Для полуструктурированных или неструктурированных данных лучше подойдут NoSQL решения:

• для кэширования, управления сеансами и прочих случаев, где необходим быстрый доступ по ключу — ключ-значение;
• для хранения документов с вложениями в формате JSON и XML, а также веб-аналитики и приложений электронной коммерции — документоориентированные;
• для логирования — колоночные бд;
• для работы со связями, определения маршрута и т.д. — графовые.