Что такое нереляционная база данных NoSQL: типы, характеристики и примеры СУБД

Нереляционная база данных не требует фиксированной схемы и масштабируется горизонтально — добавлением серверных узлов, а не апгрейдом одного. Вместо принципа ACID она опирается на BASE — архитектурный выбор, обеспечивающий высокую доступность ценой ослабления строгой согласованности.

Структурно NoSQL делится на четыре типа: документоориентированные базы данных, хранилища ключ-значение, колоночные и графовые СУБД. В статье разобраны история термина, архитектурные принципы BASE/ACID/CAP-теоремы, примеры популярных СУБД, сравнение с реляционными базами и критерии выбора.

Как появился термин NoSQL: от 1998 года до современного значения

У термина «NoSQL» стихийное происхождение: нет ни общепризнанного определения, ни учреждения, официально закрепившего смысл. Первое появление датируется 1998 годом — итальянский разработчик Карло Строцци назвал так систему, хранившую данные в ASCII-файлах с доступом через shell-скрипты вместо SQL. С современными нереляционными базами данных у неё не было ничего общего, кроме названия.

Современный смысл термин приобрёл после 2009 года. Книга «NoSQL Distilled» (Прамод Садаладж и Мартин Фаулер) стала первой системной попыткой описать разнородные нереляционные системы как единый класс технологий — именно она сформировала понятие, которым индустрия пользуется сегодня. Авторы выделили общие черты: хранение без жёсткой схемы, агрегаты как единица данных, горизонтальное масштабирование и API без стандартного SQL.

Конференция 2009 года: как NoSQL стал именем целого направления

В июне 2009 года в Сан-Франциско разработчик Йохан Оскарссон организовал неформальную встречу для обсуждения открытых нереляционных СУБД — в первую очередь Google BigTable и Amazon Dynamo. Для анонса в Twitter нужен был короткий хэштег: Эрик Эванс из компании RackSpace предложил «#NoSQL». Термин задумывался на один вечер, но разошёлся по сети и закрепился в отрасли.

На встрече обсуждались Voldemort, Apache Cassandra, HBase, Hypertable, CouchDB и MongoDB. Этот список сформировал первое публичное «созвездие» NoSQL-систем — именно тогда разнородные проекты получили общий ярлык.

Расшифровка «Not Only SQL» закрепилась позже: она точнее описывает вектор развития, чем «No SQL». Большинство нереляционных систем не отрицают SQL как идею, а дополняют его там, где реляционная модель неудобна: при гибкой схеме, горизонтальном масштабировании и специфических паттернах доступа. CouchDB, Apache Cassandra и MongoDB выросли именно из этой логики.

Почему реляционных баз данных стало недостаточно: ограничения SQL-модели

Реляционные базы данных — PostgreSQL, MySQL и другие — строятся на жёсткой схеме: перед добавлением данных нужно описать структуру таблицы. Добавление нового поля требует ALTER TABLE — операции, которая в больших таблицах может блокировать систему на часы. Нереляционная БД позволяет добавить атрибут к любому документу немедленно, без миграции схемы.

ACID-принципы реляционных СУБД гарантируют надёжность, но осложняют масштабирование. Жёсткие транзакции плохо параллелятся: при росте нагрузки реляционная БД масштабируется вертикально — более мощный сервер. Это дорого и имеет физический предел.

Ещё одна проблема — разреженные данные. Если у 80% пользователей поле «Вторая фамилия» пустое, реляционная таблица хранит NULL для каждой строки. В NoSQL отсутствующее поле просто отсутствует: никаких издержек хранения.

BASE, ACID и CAP-теорема: архитектурный фундамент NoSQL

ACID расшифровывается как Atomicity (атомарность), Consistency (согласованность), Isolation (изолированность), Durability (долговечность). Классический пример — банковский перевод: деньги должны либо уйти с одного счёта и прийти на другой, либо остаться на месте. Промежуточного состояния быть не должно. ACID гарантирует именно это.

BASE — архитектурный принцип большинства нереляционных баз данных. Расшифровывается как Basically Available (базово доступна), Soft state (гибкое состояние), Eventually consistent (итогово согласована). Система всегда отвечает, но данные на разных узлах могут временно расходиться и приходят в единое состояние через небольшой интервал. Amazon заявляет максимальный разрыв не более одной секунды; Facebook работает на аналогичных принципах. Это осознанный компромисс: строгая согласованность снижается, доступность и пропускная способность растут.

CAP-теорема (Эрик Брюер, 2000) объясняет, почему этот компромисс неизбежен. Распределённая система не может одновременно гарантировать: согласованность (Consistency), доступность (Availability) и устойчивость к разделению сети (Partition tolerance). Система гарантирует лишь два из трёх свойств. Большинство NoSQL-систем выбирают AP — доступность и устойчивость к разделению — жертвуя строгой согласованностью. Реляционные СУБД чаще занимают позицию CA.

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

Ключевые характеристики нереляционных баз данных

Нереляционные базы данных объединяет шесть общих свойств — независимо от типа.

Отсутствие жёсткой схемы (schemaless). Структура данных не фиксируется заранее. Каждый документ или запись может иметь уникальный набор полей. Twitter расширял метаданные твита с нескольких байт до килобайт без каких-либо миграций схемы.

Агрегаты вместо нормализации. Реляционная модель разрезает «заказ с позициями» на три таблицы, связанные JOIN-операциями. NoSQL хранит агрегат целиком в одном объекте — меньше задержка, меньше операций ввода-вывода.

Итоговая согласованность. Строгая согласованность не гарантируется, зато система остаётся доступной при отказе части узлов.

Горизонтальное масштабирование без разделения ресурсов (share-nothing). Каждый узел независим. Данные распределяются между узлами автоматически — шардинг не требует ручной настройки на уровне приложения.

Репликация двух видов. Схема «мастер-реплика» (master-slave): масштабируется чтение, запись — только через мастер. Одноранговая архитектура (peer-to-peer): все узлы равноправны, как в Apache Cassandra. В реляционных БД репликация настраивается вручную и требует отдельной инфраструктуры.

Open-source и 21 век. Практически все NoSQL-системы появились после 2000 года и распространяются с открытым исходным кодом.

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

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

Документоориентированные базы данных — MongoDB, CouchDB, Couchbase

Документоориентированные базы данных хранят данные в виде документов — структур формата JSON или BSON (двоичный JSON). Каждый документ самодостаточен и может иметь уникальный набор полей: нет единой схемы, обязательной для всей коллекции.

MongoDB — лидер сегмента. Пропускная способность — до 245 000 операций чтения в секунду при медианной задержке около 8 мс. Включает агрегационный фреймворк для аналитических запросов, встроенный полнотекстовый поиск и облачную платформу MongoDB Atlas. Язык запросов — MQL (MongoDB Query Language, язык запросов MongoDB).

Преимущество гибкой схемы наглядно: добавить поле «Награды» к профилю пользователя в MongoDB — это один новый ключ в документе. В реляционной БД потребовался бы ALTER TABLE, который при миллионах строк занял бы минуты и потребовал полной миграции данных.

CouchDB хранит данные в JSON и предоставляет HTTP API — запросы отправляются стандартными HTTP-методами GET/POST/DELETE. Couchbase совмещает документную модель с хранилищем ключ-значение и поддерживает язык N1QL, синтаксически близкий к SQL.

Применение: веб-приложения, электронная коммерция, мобильные приложения, системы управления контентом.

Хранилища ключ-значение — Redis и Amazon DynamoDB

Хранилища ключ-значение — простейшая модель NoSQL: уникальный ключ указывает на связанное значение. Аналогия — телефонная книга: ищешь по имени, получаешь номер. Структура минималистична, операции молниеносны.

Redis хранит данные в оперативной памяти и показывает рекордную пропускную способность — до 1 200 000 операций чтения в секунду при задержке около 1,2 мс. Поддерживает разнообразные структуры данных: строки, хэши, списки, множества, отсортированные множества. Основное ограничение — объём данных не должен превышать размер доступной RAM. Расширение Redis Stack добавляет поддержку JSON и полнотекстового поиска.

Amazon DynamoDB — управляемое облачное хранилище в инфраструктуре AWS. Автоматически масштабируется под нагрузку, не требует администрирования серверов, органично интегрируется с другими сервисами Amazon.

Применение: кэширование результатов запросов, хранение пользовательских сессий, рейтинги в реальном времени, очереди задач.

Колоночные базы данных — Apache Cassandra, HBase, ScyllaDB

Колоночные СУБД физически хранят данные по столбцам, а не по строкам. Аналитический запрос «дай все значения поля температура за последний месяц» читает только нужный столбец — без загрузки остальных атрибутов. Это даёт выигрыш при агрегациях и запросах по конкретным свойствам большого набора данных.

Apache Cassandra создана инженерами Facebook для поиска по входящим сообщениям, затем передана в Apache Software Foundation. Архитектура — одноранговая (peer-to-peer): нет мастер-узла, все узлы равноправны, нет единой точки отказа. Пропускная способность записи — 210 000 операций в секунду при задержке около 12 мс. Язык CQL (Cassandra Query Language) внешне похож на SQL.

ScyllaDB переписана на C++ вместо Java (как у Cassandra) и достигает 320 000/290 000 операций чтения и записи в секунду при полной API-совместимости с Cassandra. Переход с Cassandra на ScyllaDB не требует изменений в коде приложения.

HBase построен на основе Apache Hadoop и реализует концепцию Google BigTable — эффективное хранение разреженных данных в огромных таблицах.

Применение: телеметрия устройств интернета вещей (IoT), временны́е ряды, логирование событий, высоконагруженные системы с большими объёмами записи.

Графовые базы данных — Neo4j и ArangoDB

Графовые базы данных хранят данные как граф: узлы (объекты) и рёбра (связи между ними), у каждого — собственные свойства. Обход многоуровневых связей — главная сила этой модели.

Neo4j — лидер графовых СУБД. Язык запросов Cypher позволяет описывать маршруты по графу интуитивно: MATCH (u:User)-[:BOUGHT]->(p:Product). На задачах обхода графа Neo4j показывает задержку 42 мс против 1,2 секунды у MongoDB — разница в 30 раз. Общая пропускная способность — около 85 000 операций в секунду при медианной задержке 18 мс.

Показательный кейс — рекомендательная система маркетплейса. «Пользователи, купившие этот товар, также смотрели…» — запрос к нескольким уровням связей. MongoDB справится, но потребует цепочки вложенных запросов. Neo4j делает обход графа нативно за миллисекунды.

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

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

Сравнение производительности популярных NoSQL СУБД

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

Redis показывает минимальную задержку за счёт хранения данных в памяти. ScyllaDB и Cassandra лидируют по записи и горизонтальному масштабированию. Neo4j эффективен именно на задачах обхода графа — на стандартных операциях чтения и записи преимущество отсутствует.

Полный список нереляционных СУБД: топ-10 для разных задач

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

1. MongoDB — документоориентированная; веб-приложения, каталоги, электронная коммерция. Богатая экосистема, облачный Atlas.
2. Redis — ключ-значение in-memory; кэш, сессии, очереди. Рекордная скорость, ограничен RAM.
3. Apache Cassandra — колоночная; IoT, временны́е ряды, логи. Линейное масштабирование, одноранговая архитектура.
4. Neo4j — графовая; социальные сети, рекомендации, антифрод. Язык Cypher, нативный обход графа.
5. Amazon DynamoDB — ключ-значение, управляемый сервис AWS; высоконагруженные приложения без администрирования.
6. Couchbase — документ + ключ-значение; мобильные приложения, игры. Язык N1QL, синхронизация в офлайн-режиме.
7. Elasticsearch — поисковый движок на основе Apache Lucene; полнотекстовый поиск, стек ELK (Elasticsearch, Logstash, Kibana), векторный поиск для систем искусственного интеллекта. В 2025 году получил нативную поддержку векторных представлений (эмбеддингов) для семантического поиска.
8. ScyllaDB — колоночная, совместимая с Cassandra, написана на C++; высоконагруженные системы с требованием к низкой задержке.
9. ArangoDB — мультимодельная (документ + граф + ключ-значение); смешанные паттерны доступа в одном приложении.
10. InfluxDB — базы данных временны́х рядов; мониторинг, метрики, телеметрия устройств. Встроенные функции агрегации по временны́м окнам.

Тренд 2025 года: мультимодельные системы стирают границы типов. Применение нескольких специализированных хранилищ в одном приложении (polyglot persistence) стало нормой, а не исключением — разные части одного продукта работают с разными базами одновременно.

Когда выбрать NoSQL, а когда остаться на SQL: критерии и сценарии

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

Выбирайте NoSQL, если:

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

Оставайтесь на SQL, если:

• данные строго структурированы и схема долгосрочно стабильна;
• обязательны ACID-транзакции — финансовые операции, учётные системы;
• запросы включают сложные JOIN между многими таблицами;
• команда мала и нет ресурсов для освоения новых инструментов;
• нужен стандартный SQL для интеграции с аналитическими инструментами.

Применение нескольких специализированных хранилищ в одном приложении (polyglot persistence) к 2025 году стало нормой в высоконагруженных продуктах. Три типичных гибридных сценария:

• Каталог товаров → MongoDB (гибкая структура карточки продукта).
• Транзакционные операции → PostgreSQL (строгий ACID).
• Кэш пользовательских сессий → Redis (скорость хранения в памяти).

Эти хранилища работают параллельно: оркестрация ложится на прикладной уровень — микросервисы или шлюз API. Каждая система делает одно, но делает это лучше универсального решения.

Практический совет: начинайте с минимального набора. PostgreSQL справляется с большинством задач на старте. Переходить к специализированной нереляционной базе данных стоит, когда конкретная проблема — скорость, масштаб или гибкость схемы — становится измеримой и задокументированной.

Хотите освоить работу с данными и современными информационными системами? В рамках федерального проекта «Активные меры содействия занятости» можно пройти обучение по направлениям аналитики и IT бесплатно — без отрыва от работы. Посмотрите каталог доступных программ.

Часто задаваемые вопросы

Что такое NoSQL база данных простыми словами?

NoSQL (Not Only SQL) — класс систем хранения данных, отказавшихся от реляционных таблиц. Вместо фиксированной схемы они используют документы, пары ключ-значение, колонки или графы. Главные преимущества — гибкость структуры и горизонтальное масштабирование. Термин появился в 2009 году и объединяет разнородные системы: MongoDB, Redis, Cassandra, Neo4j и другие нереляционные СУБД.

Чем реляционная база данных отличается от нереляционной?

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

Какие базы данных относятся к NoSQL?

К нереляционным базам данных относятся четыре типа: документоориентированные (MongoDB, CouchDB), хранилища ключ-значение (Redis, Amazon DynamoDB), колоночные (Apache Cassandra, ScyllaDB) и графовые (Neo4j, ArangoDB). Дополнительно выделяют базы данных временны́х рядов (InfluxDB) и поисковые системы (Elasticsearch). Каждый тип оптимизирован под свой паттерн доступа к данным.

Что такое eventual consistency в NoSQL?

Итоговая согласованность (eventual consistency) — принцип архитектуры BASE: данные на разных узлах могут временно расходиться, но через некоторое время придут в единое состояние. Amazon заявляет максимальный интервал рассогласования — не более одной секунды. Это компромисс: строгая согласованность снижается, скорость и доступность системы растут.

Что такое BASE и чем отличается от ACID?

ACID (Atomicity, Consistency, Isolation, Durability) — стандарт транзакций реляционных БД: полная надёжность ценой медленного масштабирования. BASE (Basically Available, Soft state, Eventually consistent) — принцип NoSQL: высокая доступность и производительность за счёт ослабления строгой согласованности. CAP-теорема объясняет, почему одновременно гарантировать все три свойства в распределённой системе невозможно.

Какая NoSQL база данных самая быстрая?

По задержке лидирует Redis: хранение в оперативной памяти обеспечивает около 1,2 мс при пропускной способности до 1 200 000 операций в секунду. Основное ограничение — объём данных не должен превышать размер RAM. ScyllaDB лидирует по сочетанию скорости и горизонтального масштабирования среди дисковых решений: 320 000/290 000 операций в секунду при задержке около 4 мс.

Что такое schemaless и зачем это нужно?

Хранение без жёсткой схемы (schemaless) означает, что структура данных не фиксируется заранее. Каждый документ или запись может иметь уникальный набор полей. Это удобно при частом изменении модели и при работе с разреженными данными: отсутствующее поле просто не хранится вместо NULL. Twitter расширял метаданные твита с байт до килобайт без каких-либо изменений общей схемыхранилища.

Можно ли использовать NoSQL и SQL одновременно?

Да — это называется polyglot persistence (применение нескольких хранилищ в одном приложении). Типичный пример: транзакционные данные — PostgreSQL, каталог товаров — MongoDB, кэш сессий — Redis, граф связей — Neo4j. Такой подход к 2025 году стал нормой для высоконагруженных продуктов с разнородными требованиями к хранению данных.

Что такое шардинг и репликация в NoSQL?

Шардинг — автоматическое разделение данных по нескольким узлам; в реляционных БД это делается вручную. Репликация бывает двух видов: схема «мастер-реплика» (масштабируется чтение, запись — только через мастер) и одноранговая архитектура (все узлы равноправны — как в Cassandra). В NoSQL оба механизма управляются самой базой, а не приложением.

Что такое CAP-теорема и как она связана с NoSQL?

CAP-теорема (Эрик Брюер, 2000) утверждает: распределённая система гарантирует лишь 2 из 3 свойств — согласованность (Consistency), доступность (Availability) и устойчивость к разделению сети (Partition tolerance). Большинство NoSQL-систем выбирают AP — доступность и устойчивость к разделению — жертвуя строгой согласованностью. Реляционные СУБД чаще выбирают CA. Именно CAP-теорема объясняет, почему NoSQL работает на BASE, а не на ACID.