Нереляционные БД (NoSQL) и их

отличия от реляционных БД (SQL).

Александр

QA - специалист
 Введение:
Раньше данные онлайн-сервисов хранили преимущественно в реляционных базах (РБД) со строго
определёнными схемами и связями между таблицами — независимо от количества и структуры данных.
Но такие БД тяжело масштабируются и больше подходят для хранения структурированных записей —
например, информации о заказах в онлайн-магазине или о пользователях.

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

NoSQL (not only SQL, «не только SQL») — это термин, обозначающий технологии управления данными, отличных от SQL.
К NoSQL относятся столбцовые, графовые, документоориентированные системы, а также системы по модели «ключ —
значение».

Разница между реляционными и нереляционными хранилищами заключается в том, как они хранят содержимое.

В реляционных БД данные представлены в виде таблиц с фиксированным количеством столбцов. Обычно таблицы
связаны друг с другом общими полями. Например, в таблице users может быть поле group, хранящее номер группы, в
которой состоит пользователь. Это поле связывает users с таблицей groups, содержащей информацию о группах
пользователей. Такая модель удобна, если мы работаем с однотипными данными.

А вот работать с данными разного формата в реляционных базах данных неудобно — нужно будет подгонять данные под
единый стандарт. Поэтому жёсткая структура SQL не подходит, лучше добавлять сущности только с нужными полями. Такая
возможность есть в MongoDB — одной из популярных NoSQL-СУБД. Она основана на документоориентированном подходе, о
котором мы ещё расскажем подробнее.
Почему появилась модель NoSQL?
Жёсткая структура из примера выше — не единственная проблема реляционных баз данных. Другие
недостатки — медлительность, привязка к единой точке доступа, плохая масштабируемость и проблемы
с обработкой больших объёмов данных. Это обратная сторона стандартов ACID, на которых строятся
реляционные БД:

Атомарность (atomicity) — транзакция либо выполняется полностью, либо не выполняется вообще.

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

Согласованность (consistency) — состояния до и после транзакции должны быть согласованными.

Принцип напоминает закон сохранения массы в физике: ничего не исчезает бесследно и не появляется
из ниоткуда.
Например, когда клиент банка переводит 100 рублей со счёта A на счёт B, баланс счёта A
должен уменьшиться на 100 рублей, а баланс счёта B — увеличиться на ту же сумму.

Согласованность гарантирует, что даже в случае сбоя во время выполнения транзакции

суммарный баланс обоих счетов не изменится. Например, если произошла ошибка после
уменьшения баланса на счёте A, но перед увеличением баланса на счёте B, то база
данных вернётся в состояние, в котором балансы счетов соответствуют бизнес-правилам.
Почему появилась модель NoSQL?
Жёсткая структура из примера выше — не единственная проблема реляционных баз данных. Другие
недостатки — медлительность, привязка к единой точке доступа, плохая масштабируемость и проблемы
с обработкой больших объёмов данных. Это обратная сторона стандартов ACID, на которых строятся
реляционные БД:

Атомарность (atomicity) — транзакция либо выполняется полностью, либо не выполняется вообще.

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

Согласованность (consistency) — состояния до и после транзакции должны быть согласованными.

Принцип напоминает закон сохранения массы в физике: ничего не исчезает бесследно и не появляется
из ниоткуда.
Например, когда клиент банка переводит 100 рублей со счёта A на счёт B, баланс счёта A
должен уменьшиться на 100 рублей, а баланс счёта B — увеличиться на ту же сумму.

Согласованность гарантирует, что даже в случае сбоя во время выполнения транзакции

суммарный баланс обоих счетов не изменится. Например, если произошла ошибка после
уменьшения баланса на счёте A, но перед увеличением баланса на счёте B, то база
данных вернётся в состояние, в котором балансы счетов соответствуют бизнес-правилам.
 Изолированность (isolation) — параллельно выполняющиеся транзакции не имеют доступа к
промежуточным состояниям друг друга и отражают результаты так, как если бы они выполнялись
последовательно.
Представьте ситуацию. Два клиента одновременно решили купить в интернет-магазине один и тот же
продукт, который остался в единственном экземпляре.
Клиент A добавляет продукт в корзину, и система начинает транзакцию для резервирования товара.
Практически одновременно клиент B выбирает тот же продукт и добавляет его в свою корзину.
Если платёж клиента A проходит успешно, система подтверждает покупку, а количество доступных
товаров на сайте меняется (в нашем случае на 0).
Когда клиент Б завершит свою транзакцию, система уже будет понимать, что товар продан, потому
отменит покупку.

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

Стандарты ACID делают РБД надёжной, но медлительной моделью хранения данных, плохо подходящей
для высоконагруженных сервисов.

Это стало ясно по мере распространения интернета. Взрывной рост объёма обрабатываемых данных
заставлял серверы работать на пределе, а программистов — подгонять данные под единый формат.
Компаниям нужно было больше серверов и специалистов, а стоило всё это недешево. Было решено
хранить информацию иначе.
Какие преимущества есть у NoSQL
В конце двухтысячных крупные компании стали использовать нереляционные СУБД, у
которых было несколько существенных преимуществ в сравнении с традиционными
системами:
●
Возможность работать с любыми форматами данных позволяет обойтись одной БД
для всех данных компании. Одну БД дешевле хранить и проще поддерживать.
●
Базы данных NoSQL легко переносят горизонтальное масштабирование — если
информации или запросов становится больше, достаточно добавить больше узлов.
Реляционные базы придётся масштабировать вертикально, то есть переносить на более
мощный сервер. Кроме того, NoSQL легче переносятся в облако.
●
Высокая скорость обработки запросов упрощает быстродействие приложений в целом.
●
Разрабатывать приложения с NoSQL легче. Команды разработчиков могут быстрее
создавать и внедрять новые функции и сервисы.
 Компании, которые сталкиваются с быстрым ростом объёма данных и нагрузки, могут
легко и дёшево решить возникающие проблемы с помощью NoSQL. Эти преимущества
демонстрируют стандарты архитектуры BASE, название которой расшифровывается как
Basically Available, Soft state и Eventually consistent.

Базовая доступность (basically available) означает, что система доступна для чтения и
записи всегда, даже при сбоях или других аномалиях. Цена компромисса — некоторые
запросы могут вернуть промежуточные или частично некорректные результаты.

Гибкая согласованность (soft state) подразумевает, что состояние системы может

меняться со временем для достижения согласованности.

Событийная согласованность (eventually consistent) означает, что согласованность

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

Таким образом, разработчики баз NoSQL отказались от стандартов ACID ради скорости и
простоты масштабирования.
# Таблица «Фильмы» с указанными полями
CREATE TABLE Films ( {
ID INT PRIMARY KEY, # Уникальный идентификатор фильма
"ID": 1,
Название VARCHAR(100), # Название фильма
Год_выпуска INT, # Год выпуска фильма "Название": "Назад в будущее",
Жанр VARCHAR(50) # Жанр фильма "Год_выпуска": 1985,
);
# Таблица "Оценки" с указанными полями
"Жанр": "Научная фантастика",
CREATE TABLE Ratings ( "Оценки": [
ID INT PRIMARY KEY, # Уникальный идентификатор оценки
{
ID_фильма INT, # Внешний ключ на ID фильма
Имя_пользователя VARCHAR(50),# Имя пользователя, который оценил фильм "Имя_пользователя": "user123",
Оценка DECIMAL(3, 1), # Значение оценки (например, 4.5) "Оценка": 4.5,
Комментарий VARCHAR(200) # Комментарий к оценке (опционально)
"Комментарий": "Отличный фильм!"
);
# Вставка данных о фильмах в таблицу «Фильмы» },
INSERT INTO Films (ID, Название, Год_выпуска, Жанр) {
VALUES
"Имя_пользователя": "moviefan456",
(1, 'Назад в будущее', 1985, 'Научная фантастика'),
(2, 'Звёздные войны', 1977, 'Фантастика'), "Оценка": 5.0,
(3, 'Крёстный отец', 1972, 'Драма'); "Комментарий": "Лучший фильм всех времён!"
# Вставка данных об оценках в таблицу «Оценки»
INSERT INTO Ratings (ID, ID_фильма, Имя_пользователя, Оценка, Комментарий)
}
VALUES ]
(1, 1, 'user123', 4.5, 'Отличный фильм!'),
}
(2, 1, 'moviefan456', 5.0, 'Лучший фильм всех времён!');
Если мы захотим добавить данные о наградах фильма, то вот как это будет выглядеть в SQL:

Нам пришлось создать новую таблицу «Награды» и установить связи

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

●
Просто добавляем какие хотим пары «ключ — значение»,
не боясь что-нибудь сломать. Красота!
А теперь представим, что продакт-менеджеры поручили нам добавить новую
фичу — список наград для каждого фильма. В случае с базой данных SQL нам
пришлось бы выполнить следующую последовательность действий:

●
Продумать схему внедрения данных.
●
Создать новую таблицу «Награды».
●
Установить связь с таблицей «Фильмы» с помощью внешнего ключа.
●
Изменить код для вставки данных о наградах в таблицу.
Поскольку РБД требуют жёсткой структуры данных, то нужно будет заранее
продумать схему интеграции. А если база уже прилично разрослась или активно
используется в продакшене, то придётся попотеть: создать резервные копии
данных, прописать и проверить сценарии миграции, обновить сопряжённые
приложения и сервисы.

Изменение структуры в NoSQL делается в два шага:

●
Просто добавим новое поле «Награды» в документы фильмов.
●
Заполним это поле данными о наградах для каждого фильма.
Поэтому нереляционные базы используются в проектах, где структура данных
часто меняется.
 Виды NoSQL-баз данных:
1. Key-Value (Ключ-Значение) базы данных.
Это очень простые по своей идее хранилища. Фактически это очень большие хэш- таблицы, где
каждому ключу поставлено в соответствие значение. Такие базы могут очень быстро
оперировать колоссальными объемами информации, но они имеют серьезные ограничения в
языке запросов.
2. BigTable.
Это база данных разработанная компанией Google для собственных нужд. Эта база
представляет собой большую таблицу с тремя измерениями: колонки, строки и временны'е
метки. Такая архитектура позволяет добиться очень высокой производительности, кроме того,
она хорошо масштабируется на множество компьютеров. Но это не реляционная база, и она не
поддерживает многие возможности реляционных баз.
3. Документо-ориентированные базы данных.
Такие базы немного напоминают Key-Value базы, но в данном случае, база данных знает, что из
себя представляют значения. Обычно, значением является некоторый документ или объект, к
структуре которого можно делать запросы.
4. Базы данных построенные на графах.
Такие базы ориентированы на поддержку сложных взаимосвязей между объектами, и
основываются на теории графов. Структура данных в таких базах представляет собой набор
узлов, связанных между собой ссылками. При этом и узлы и ссылки могут обладать некоторым
количеством атрибутов.
Хранилища типа «ключ — значение».
Самый простой вид технологии NoSQL. Данные хранятся в виде пар «ключ — значение». У каждого фрагмента данных есть
уникальный ключ, по которому получают значение из этого фрагмента.
Такие хранилища похожи на телефонную книгу: имя абонента — это ключ, а номер — значение. Чтобы узнать номер человека,
нужно извлечь значение, соответствующее его ключу, то есть имени:
Ещё такой тип баз данных отлично подходит для автозамены. Слово с опечаткой заменяется на правильно написанное, а
нецензурное выражение — на печатный синоним. Часто хранилища типа «ключ — значение» используют для журналирования
запросов к другим БД.
 Документоориентированные базы данных
●
хранят данные в виде JSON
— или BSON-документов.
Каждый документ
представляет собой
отдельную запись, гибкая
структура документа
позволяет хранить сложные
данные. Вот как выглядит
запись и чтение документа в
MongoDB — популярной
документоориентированной
базе данных:
 Колоночные
Эти базы отличаются от реляционных лишь способом хранения данных на накопителе.

Если реляционная база создаёт для каждой таблицы по файлу, то в колоночной отдельный файл создаётся для каждого столбца
таблицы.

Например, если реляционная таблица выглядит так:

Что это даёт? Представьте, что вам нужны только
названия объектов, а их свойства вас не интересуют.

При выполнении запроса в реляционной таблице

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

Колоночные базы применяются в различных

каталогах и архивах данных, работа с которыми
основана на подобных выборках.

Одна из самых популярных СУБД такого типа —

Apache Cassandra.
 Графовые
В некоторых предметных областях данные удобно представлять в виде графов. Для их хранения лучше всего
подходят графовые базы.
Вершины (или узлы графа) — это объекты (сущности), а рёбра графа — взаимосвязи между ними.
Например, информация о друзьях в социальных сетях просто идеальна для представления в виде графа:

Графовые базы применяют в социальных

сетях, сервисах рекомендаций, системах
выявления мошенничества и им подобных.

Одна из популярнейших графовых СУБД с

открытым кодом и собственным языком
запросов — это Neo4j.
 Консистентность (Consistency)
Все узлы системы видят одни и те
же данные в один и тот же момент
времени. То есть, после успешной
операции записи все последующие
чтения вернут одно и то же
обновлённое значение.

Доступность (Availability)
Каждый запрос к системе получает
ответ (удачный или неудачный) в
разумные сроки. То есть, система
всегда отвечает на запросы, даже
если ответ может быть не самым
актуальным.

Устойчивость к сетевым
разделениям (Partition Tolerance)
Система продолжает работу даже
при частичном отказе узлов или
при потере связи между ними. Это
означает, что независимо от того,
возникают ли ошибки связи между
частями сети, система должна
сохранять работоспособность.
 Сторонниками концепции NoSQL подчёркивается, что она не является
полным отрицанием языка SQL и реляционной модели, проект исходит из
того, что SQL это важный и весьма полезный инструмент, но при этом он
не может считаться универсальным. Одной из проблем, которую
указывают для классических реляционных БД, являются проблемы при
работе с данными очень большого объема и в проектах с высокой
нагрузкой. Основная цель подхода расширить возможности БД там, где
SQL недостаточно гибок, и не вытеснять его там, где он справляется со
своими задачами.
Спасибо за
внимание