Глава 22 · Веб-разработка с Python

NoSQL: основные виды нереляционных баз данных

NoSQL объединяет несколько нереляционных моделей хранения: ключ-значение, документы, ширококолоночные хранилища и графы.

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

NoSQL — «не только SQL», а не «никогда не SQL»

Термин NoSQL часто трактуют как Not Only SQL — «не только SQL». Это не название одного языка и не единый стандарт: под NoSQL объединяют несколько разных семейств СУБД. Многие нереляционные системы всё равно поддерживают SQL-подобные или собственные языки запросов — название описывает отход от классической реляционной модели таблиц, а не полный отказ от идеи структурированных запросов.

Реляционные базы (разделы 22.21-22.24) хранят данные в таблицах с заранее заданной структурой. Иногда такая структура неудобна — например, если форма записей сильно отличается от документа к документу, нужна очень быстрая работа по ключу, или данные естественно представляются как узлы и связи. Ниже — четыре основных семейства NoSQL-СУБД, у каждого своя модель данных.

Ключ — значение

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

Пример: Redis — сервер структур данных, в котором каждый объект имеет ключ; Redis поддерживает строки, списки, множества, хеши, потоки и другие структуры данных.

primer_redis.txt

SET session:42 '{{"user_id": 42, "expires": "2026-08-24"}}'
GET session:42

Типичное применение: кеш, счётчики, хранение сессий/состояния, очереди и потоки данных — часто как дополнение к основной базе, а не её замена.

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

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

Пример: MongoDB хранит документы в формате BSON, который по структуре близок к JSON.

primer_dokument.json

{{
  "name": "Механическая клавиатура",
  "price": 8900,
  "characteristics": {{"switches": "red", "layout": "ru"}}
}}

Удобны, когда форма записей может меняться от документа к документу.

Ширококолоночные базы данных

Данные организуются вокруг ключей разделов (partition keys) и строк с набором столбцов. Такая модель рассчитана на распределённое хранение больших объёмов данных и заранее продуманные шаблоны запросов.

Пример: Apache Cassandra — распределённая ширококолоночная СУБД, доступная через собственный язык запросов CQL.

primer_wide_column.txt

Партиция: device_id = 42
Строки внутри партиции упорядочены по date

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

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

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

Пример: Neo4j — графовая СУБД, где запросы явно оперируют узлами и связями.

primer_graf.txt

(Ада)-[:ДРУГ]->(Борис)-[:ДРУГ]->(Вера)

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

Специализированные системы хранения и поиска

Отдельно стоят системы полнотекстового поиска, векторные и временные базы данных — их не относят к четырём каноническим семействам выше. Эти категории могут пересекаться друг с другом и с уже перечисленными моделями, а некоторые продукты сочетают несколько моделей в одной СУБД (multi-model).

Общие особенности NoSQL-систем

У многих NoSQL-СУБД схема данных более гибкая, чем в реляционной модели, — это не значит, что схема отсутствует полностью. Многие NoSQL-СУБД проектируются с расчётом на распределённую работу и горизонтальное масштабирование, но конкретные гарантии (согласованность, поддержка транзакций, устойчивость к сбоям) зависят от продукта и его настройки. Производительность зависит от модели данных, конкретной СУБД и типа запросов — не существует правила «NoSQL всегда быстрее».

Критерий	Реляционная СУБД	NoSQL-системы
Модель данных	Таблицы, строки, столбцы	Зависит от типа: документы, ключ-значение, wide-column, граф
Схема	Обычно определяется явно	Часто более гибкая; зависит от конкретной СУБД
Связи	Внешние ключи, JOIN и другие реляционные операции	Реализуются по-разному: ссылки, вложенные документы, графовые связи и другое
Язык запросов	SQL и его диалекты	Собственные языки запросов, команды или API; некоторые поддерживают SQL-подобные интерфейсы
Транзакции	Зависят от СУБД, обычно развитая поддержка транзакций	Зависят от конкретной СУБД; многие современные системы также поддерживают транзакции
Масштабирование	Возможны вертикальные и распределённые архитектуры	Многие системы изначально проектируются для распределённой работы
Когда выбирать	Когда реляционная модель хорошо соответствует данным и запросам	Когда конкретная нереляционная модель лучше соответствует данным и нагрузке

Что выбрать

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

Для простого приложения достаточно одной подходящей СУБД

Крупные реальные системы нередко используют не одну технологию хранения, но учебный проект стоит начинать с самой простой подходящей. Для обычного CRUD-приложения вроде списка задач не нужны одновременно PostgreSQL, MongoDB, Redis и векторная база — это добавит сложности эксплуатации без реальной выгоды. Итоговый проект этой главы (раздел 22.35) обходится одной таблицей в SQLite.

Официальная документация: MongoDB, Redis, Apache Cassandra, Neo4j.

← Назад

PostgreSQL, MySQL/MariaDB и SQLite: основные различия

ORM: работа с базой данных через объекты Python