NoSQL — общее название для группы систем управления базами данных, которые не ограничиваются классической реляционной моделью с таблицами, строками, столбцами и SQL-запросами. К NoSQL относят документоориентированные, key-value, графовые, колоночные и другие специализированные базы данных.
NoSQL-системы появились как ответ на задачи, где традиционная реляционная модель оказывалась неудобной: огромные объемы данных, высокая скорость записи, распределенная инфраструктура, гибкая структура документов или большое количество связей определенного типа.
Например, каталог товаров может храниться в документной базе, Cache — в key-value хранилище, а социальный граф пользователей — в графовой СУБД.
Что такое NoSQL простыми словами
NoSQL можно представить как набор альтернативных способов хранить данные, кроме привычных SQL-таблиц.
В реляционной базе информация обычно распределяется по таблицам и связывается через ключи. В NoSQL данные могут храниться документами, парами ключ-значение, графами или широкими наборами колонок.
NoSQL — это не одна конкретная технология, а семейство разных подходов к хранению данных.
Что означает NoSQL
Термин NoSQL часто интерпретируют как Not Only SQL — не только SQL.
Смысл заключается не в полном отказе от SQL как языка, а в использовании моделей данных, отличных от классической реляционной.
Некоторые современные NoSQL-системы могут даже предоставлять SQL-подобные языки запросов, оставаясь при этом нереляционными по внутренней модели.
Зачем нужны NoSQL базы данных
NoSQL используют, когда особенности данных или нагрузки плохо соответствуют обычной реляционной схеме.
- гибкая структура документов;
- очень высокая скорость чтения или записи;
- распределение данных между большим количеством узлов;
- хранение key-value данных;
- большие графы связей;
- временные и кэшируемые данные;
- событийные потоки;
- масштабирование больших наборов информации.
Основные виды NoSQL
NoSQL объединяет несколько принципиально разных типов баз.
| Тип | Модель | Пример задачи |
|---|---|---|
| Document Database | Документы | Каталог товаров |
| Key-Value | Ключ и значение | Cache и сессии |
| Wide-Column | Широкие наборы колонок | Большие распределенные данные |
| Graph Database | Узлы и связи | Социальные связи и рекомендации |
Документоориентированные базы
Document Database хранит данные в виде самостоятельных документов.
Документ может содержать строки, числа, массивы и вложенные объекты.
{
"name": "Ноутбук",
"price": 90000,
"specifications": {
"ram": 16,
"screen": 15.6
}
}Такой подход удобен, если объекты имеют сложную или меняющуюся структуру.
MongoDB как пример NoSQL
MongoDB относится к документоориентированным NoSQL-СУБД.
Она хранит документы в Collections и использует BSON-представление данных.
MongoDB часто применяют для каталогов, CMS, Backend и других систем, где данные естественно представлены вложенными объектами.
Key-Value базы
Key-Value модель строится вокруг пары ключ-значение.
session:abc123 = user_125
Клиент знает ключ и быстро получает соответствующее значение.
Такие системы особенно эффективны для Cache, сессий, временных токенов и счетчиков.
Redis как пример NoSQL
Redis относят к NoSQL и часто используют как высокопроизводительное key-value хранилище в памяти.
Помимо обычных значений Redis поддерживает Lists, Sets, Hashes, Sorted Sets и Streams.
На практике он часто работает рядом с основной SQL-базой как Cache или инфраструктурный компонент.
Wide-Column базы
Wide-Column Database хранит данные в распределенной модели, ориентированной на большие наборы строк и колонок.
Такие системы проектируются для масштабирования по множеству серверов и высоких объемов операций.
Их модель отличается как от обычных SQL-таблиц, так и от Document Database.
Когда используют Wide-Column
Такая модель может быть полезна для огромных потоков событий, телеметрии, временных данных и систем с заранее известными шаблонами доступа.
Основной принцип — Schema проектируется под конкретные Queries, а не только вокруг сущностей бизнеса.
Graph Database
Графовая база хранит Nodes и Relationships между ними.
Она удобна, когда основная ценность данных заключается именно в связях.
Например, социальная сеть может хранить пользователей как Nodes, а дружбу — как Relationships.
Когда нужна графовая база
Graph Database хорошо подходит для анализа социальных сетей, Fraud Detection, маршрутов, зависимостей и Recommendation Systems.
В SQL те же связи можно представить через таблицы, но сложные многошаговые обходы графа иногда естественнее выражаются специализированной моделью.
NoSQL и SQL
NoSQL часто противопоставляют SQL, но корректнее сравнивать конкретные модели баз данных.
| SQL-системы | NoSQL-системы |
|---|---|
| Обычно реляционная модель | Документы, key-value, графы и другие модели |
| Таблицы и связи | Структура зависит от типа базы |
| SQL-запросы | Собственные API или языки запросов |
| JOIN широко используется | Часто применяются другие способы моделирования связей |
| Schema обычно формализована | Schema может быть гибче |
NoSQL не означает отсутствие Schema
Одно из распространенных заблуждений — считать NoSQL полностью бессхемными базами.
Даже если СУБД позволяет сохранять документы разной структуры, приложение все равно должно понимать набор полей, типы и бизнес-правила.
Без этого данные быстро становятся непоследовательными.
Гибкая Schema не означает отсутствие проектирования данных.
Flexible Schema
Гибкая схема позволяет объектам иметь различающиеся поля.
Например, каталог содержит ноутбуки, одежду и мебель.
Каждая категория имеет собственные характеристики, поэтому документная NoSQL-база может быть удобнее огромной таблицы с сотнями редко используемых столбцов.
Denormalization
NoSQL-системы часто используют денормализацию — намеренное дублирование части информации.
Например, имя клиента можно сохранить внутри документа заказа, чтобы не выполнять отдельный запрос.
Это ускоряет чтение, но создает задачу синхронизации данных.
Нормализация и NoSQL
В классической SQL-модели данные часто нормализуют, разделяя сущности между таблицами.
В NoSQL данные чаще проектируют вокруг того, как приложение их читает и записывает.
Если информация постоянно используется вместе, ее иногда выгоднее хранить вместе.
NoSQL и JOIN
Во многих NoSQL-моделях JOIN либо отсутствует, либо не является центральной частью архитектуры.
Связанные данные могут быть вложены в один документ или запрашиваться отдельно.
Это уменьшает стоимость некоторых чтений, но требует заранее понимать основные Patterns доступа.
Query-first моделирование
Для ряда NoSQL-систем Schema проектируют прежде всего под реальные запросы приложения.
Сначала команда определяет, какие данные будут читаться вместе и с какой частотой, а затем выбирает структуру хранения.
Это отличается от подхода, когда сначала строится универсальная нормализованная модель, а запросы появляются позже.
NoSQL и масштабирование
Многие NoSQL-системы проектируются с учетом горизонтального масштабирования.
Вместо постоянного увеличения мощности одного сервера данные распределяются между несколькими узлами.
Однако сама принадлежность к NoSQL не означает автоматическую бесконечную масштабируемость.
Вертикальное масштабирование
Vertical Scaling означает увеличение ресурсов одного сервера: CPU, RAM и дисков.
Это относительно простой способ увеличить производительность.
Но у одного узла существует физический предел, поэтому крупным системам может понадобиться горизонтальное масштабирование.
Горизонтальное масштабирование
Horizontal Scaling означает добавление дополнительных серверов.
Данные и нагрузка распределяются между ними.
NoSQL-продукты часто имеют встроенные механизмы для такой архитектуры, хотя управление распределенной системой все равно остается сложной задачей.
Sharding
Sharding разделяет Dataset между несколькими узлами.
Каждый сервер хранит только часть данных.
Например, записи пользователей могут распределяться по диапазонам идентификаторов или другому ключу.
Shard Key
Shard Key определяет способ распределения данных.
Неудачный выбор может привести к Hotspot, когда большая часть операций попадает на один сервер.
Поэтому Sharding требует понимания реальной нагрузки и Queries.
Replication
Replication создает дополнительные копии данных на других узлах.
Это повышает доступность и помогает переживать отказ отдельного сервера.
Репликация может также использоваться для распределения части чтений.
Replication и Backup
Репликация не является резервным копированием.
Если приложение ошибочно удалило документ, удаление может распространиться по репликам.
Для восстановления после логической ошибки нужны отдельные Backup.
CAP theorem
При обсуждении распределенных NoSQL-систем часто упоминают CAP theorem.
В упрощенном виде она показывает, что при сетевом разделении распределенная система вынуждена делать выбор между сохранением доступности операций и строгой согласованностью результата.
Реальные системы предоставляют более сложные модели и настройки, поэтому CAP не следует использовать как единственный критерий выбора базы.
Consistency
Consistency описывает требования к тому, насколько одинаковое и актуальное состояние данных видят разные клиенты и узлы.
Для банковского баланса требования могут быть строгими, а для счетчика просмотров небольшая задержка обновления иногда допустима.
Eventual Consistency
Eventual Consistency означает, что после прекращения новых изменений копии данных со временем сходятся к одинаковому состоянию.
В течение некоторого периода разные клиенты могут увидеть отличающиеся значения.
Такой подход подходит не для всех бизнес-операций.
Strong Consistency
Strong Consistency предполагает более строгие требования к видимости новых данных.
Это упрощает некоторые бизнес-сценарии, но в распределенной инфраструктуре может увеличивать задержку или снижать доступность при сетевых проблемах.
BASE
Для описания некоторых распределенных систем используют концепцию BASE как противопоставление строгой транзакционной модели.
Она акцентирует внимание на доступности и постепенном достижении согласованности.
Но современные NoSQL-СУБД могут предоставлять и полноценные транзакционные механизмы, поэтому деление SQL равно ACID, NoSQL равно BASE слишком упрощено.
Транзакции в NoSQL
NoSQL не означает отсутствие транзакций.
Некоторые системы поддерживают атомарность отдельных документов или ключей, другие — транзакции между несколькими объектами.
Конкретные гарантии необходимо смотреть у выбранной СУБД.
Почему модель транзакций важна
Если бизнес-операция должна одновременно изменить несколько объектов, необходимо понимать поведение базы при сбое между изменениями.
Для финансовых и учетных систем это особенно критично.
Выбирать NoSQL только ради скорости, не анализируя транзакционные требования, рискованно.
NoSQL и Backend
Backend взаимодействует с NoSQL-базой через Driver, SDK или специализированный API.
Например, сервис каталога получает HTTP Request, формирует Query к MongoDB и возвращает JSON Frontend.
Другой Backend может использовать Redis для Cache.
NoSQL и Frontend
Frontend обычно не подключается напрямую к внутренней базе данных.
Браузер работает через Backend API, который выполняет авторизацию, валидацию и ограничивает доступ к данным.
Это правило одинаково важно как для SQL, так и для NoSQL систем.
NoSQL и API
Внешний API не обязан повторять внутреннюю модель NoSQL.
Например, MongoDB Document содержит 30 полей, а API возвращает пользователю только пять.
Так Backend отделяет публичный контракт от структуры хранения.
NoSQL и JSON
Document Databases часто используют модель, похожую на JSON.
Это удобно для API-разработки, поскольку данные Frontend и Backend имеют похожую структуру.
Однако внутреннее представление конкретной СУБД может быть бинарным или иметь дополнительные типы.
NoSQL и микросервисы
В Microservices Architecture каждый сервис может выбирать подходящую модель хранения.
Catalog Service использует MongoDB, Session Service — Redis, а Billing Service — PostgreSQL.
Такой подход называется Polyglot Persistence.
Polyglot Persistence
Polyglot Persistence предполагает использование нескольких типов баз данных в одной системе.
Преимущество — каждый сервис получает подходящий инструмент.
Недостаток — команде приходится поддерживать больше технологий, Backup-процедур, метрик и навыков эксплуатации.
NoSQL и Big Data
NoSQL часто применяется в системах с большими объемами данных, но Big Data и NoSQL не являются синонимами.
Большие данные могут обрабатываться и SQL-платформами.
NoSQL выбирают, когда конкретная модель хранения или распределения лучше соответствует задаче.
NoSQL и Data Lake
Data Lake хранит большие объемы сырых данных, а NoSQL Database обычно предоставляет более структурированный слой для оперативных запросов.
Они могут использоваться совместно в одной Data Platform.
NoSQL и Data Warehouse
Data Warehouse ориентирован на аналитику и часто использует табличную SQL-модель.
NoSQL чаще обслуживает оперативные приложения или специализированные типы данных.
Данные из NoSQL могут регулярно загружаться в Warehouse через Data Pipeline.
NoSQL и OLTP
Некоторые NoSQL-системы хорошо подходят для OLTP-подобных сценариев с огромным количеством коротких операций.
Например, key-value хранилище может обрабатывать большое количество запросов по конкретному ключу.
Но требования к транзакциям и согласованности должны соответствовать возможностям выбранной базы.
NoSQL и аналитика
Некоторые NoSQL продукты позволяют выполнять агрегации и аналитические Queries.
Но если основной сценарий — сложные ad hoc отчеты с большим количеством JOIN и группировок, специализированный Data Warehouse может быть удобнее.
NoSQL и Cache
Key-value NoSQL-хранилища часто используются как Cache.
Redis позволяет временно сохранять результат медленного SQL или API-запроса и быстро возвращать его повторным пользователям.
Так NoSQL становится дополнительным слоем, а не основной Database.
NoSQL и поисковые системы
Некоторые поисковые платформы имеют нереляционную модель хранения и ориентированы на полнотекстовый поиск.
Но поисковый индекс обычно решает другую задачу, чем основная операционная база.
Приложение может хранить исходные товары в MongoDB или PostgreSQL, а их поисковое представление — в отдельной Search Engine.
NoSQL и Time Series
Временные ряды имеют специфическую структуру: огромное количество измерений, связанных со временем.
Для них существуют специализированные базы, часть которых также относят к нереляционным системам.
Они оптимизируют хранение, агрегацию и удаление старых временных данных.
NoSQL и IoT
IoT-системы могут генерировать огромные потоки сообщений от устройств.
NoSQL применяется, когда нужно быстро принимать события, распределять их между узлами и хранить данные с гибкой структурой.
Конкретный тип базы зависит от характера телеметрии и запросов.
NoSQL и Event-driven Architecture
Событийные системы создают большой поток независимых сообщений.
NoSQL может хранить состояние потребителей, события, агрегаты или временные данные.
При этом Message Broker и Database решают разные задачи и не должны автоматически заменять друг друга.
NoSQL и Docker
NoSQL-базы удобно запускать в Docker для development.
Например, MongoDB или Redis можно добавить в Docker Compose рядом с Backend.
Для production Stateful Services необходимо отдельно продумать Volume, Backup и отказоустойчивость.
NoSQL и Kubernetes
NoSQL Database может работать в Kubernetes, но база является Stateful workload.
Запуск нескольких pod сам по себе не создает корректный кластер.
Необходимо учитывать хранение данных, Replication, Sharding, восстановление и сетевую идентичность узлов.
NoSQL в облаке
Облачные платформы предлагают Managed NoSQL Databases, которые уменьшают объем ручного администрирования.
Провайдер может управлять частью инфраструктуры, резервированием и масштабированием.
Но команда приложения остается ответственной за модель данных, Queries и правильное использование сервиса.
Backup NoSQL
NoSQL-системам необходим Backup так же, как SQL-базам.
Replication защищает от отказа узла, но не обязательно от ошибочного удаления или повреждения логики приложения.
Резервные копии нужно регулярно проверять восстановлением.
RPO и RTO
RPO определяет допустимую потерю последних данных, а RTO — максимальное время восстановления.
Эти параметры должны определять архитектуру Backup, Replication и Disaster Recovery.
NoSQL и Observability
Для production необходимо отслеживать не только CPU и память, но и показатели конкретной модели базы.
Это могут быть Query Latency, Cache Hit Ratio, Replication Lag, количество операций, размер Dataset и распределение нагрузки по shards.
Без метрик сложно понять, действительно ли NoSQL решает исходную проблему.
Основные метрики NoSQL
| Метрика | Что показывает |
|---|---|
| Query Latency | Время выполнения запросов |
| Operations Rate | Интенсивность чтения и записи |
| Replication Lag | Отставание копий данных |
| Memory Usage | Использование оперативной памяти |
| Disk I/O | Нагрузку на диски |
| Shard Distribution | Равномерность распределения данных |
NoSQL и Prometheus
Большинство инфраструктурных NoSQL-систем можно интегрировать с Prometheus через соответствующие exporters или встроенные интерфейсы метрик.
Grafana затем показывает состояние кластера на дашбордах.
NoSQL и OpenTelemetry
Backend может включать Database Calls в Distributed Trace.
Так инженер видит, сколько времени конкретный Request тратит на MongoDB, Redis или другое хранилище.
Это помогает находить реальные узкие места.
Безопасность NoSQL
NoSQL-база не должна считаться безопасной только потому, что не использует SQL.
- ограничивать сетевой доступ;
- использовать аутентификацию;
- выдавать минимальные права;
- шифровать соединения;
- валидировать пользовательский ввод;
- обновлять сервер и драйверы;
- контролировать административный доступ;
- создавать резервные копии.
NoSQL Injection
Отсутствие SQL не устраняет Injection-класс уязвимостей.
Если Backend передает пользовательский объект напрямую в Database Query, злоумышленник может попытаться изменить условия фильтрации или использовать неожиданные операторы.
Входные данные необходимо валидировать и преобразовывать в заранее определенную структуру Query.
Почему базу нельзя открывать Frontend
Внешний пользователь не должен напрямую обращаться к внутренней Database.
Backend выступает контролируемым слоем: проверяет права, ограничивает поля и применяет бизнес-логику.
Это относится к MongoDB, Redis и другим NoSQL-системам так же, как к SQL.
Преимущества NoSQL
- несколько моделей хранения под разные задачи;
- гибкая Schema в документных системах;
- эффективный key-value доступ;
- удобная работа с графами;
- возможность горизонтального масштабирования;
- высокая скорость для специализированных Queries;
- удобство распределенных архитектур.
Недостатки NoSQL
- нет единой модели и единого языка для всех продуктов;
- часто требуется проектировать данные под Queries;
- гибкая Schema может привести к хаосу;
- сложные связи иногда удобнее в SQL;
- распределенность усложняет согласованность;
- Sharding и Replication требуют экспертизы;
- часто приходится поддерживать несколько разных технологий.
Типичные ошибки при выборе NoSQL
- Выбирать NoSQL только потому, что проект считается высоконагруженным.
- Считать NoSQL автоматически быстрее SQL.
- Не анализировать транзакционные требования.
- Игнорировать Schema и типы данных.
- Копировать реляционную модель один в один.
- Включать Sharding до появления реальной необходимости.
- Считать Replication заменой Backup.
- Не учитывать сложность эксплуатации нескольких СУБД.
- Не проверять доступные Queries до проектирования Schema.
- Не измерять производительность на реальной нагрузке.
Как выбрать NoSQL базу
Шаг 1. Определить модель данных
Нужно понять, являются ли данные документами, key-value парами, графом или другой структурой.
Шаг 2. Описать основные Queries
Важно заранее знать, какие операции будут выполняться чаще всего.
Шаг 3. Определить требования к транзакциям
Нужно понимать, какие изменения должны быть атомарными.
Шаг 4. Оценить объем и нагрузку
Следует определить размер Dataset, скорость записи и количество чтений.
Шаг 5. Продумать согласованность
Необходимо решить, допустимо ли временно видеть немного устаревшие данные.
Шаг 6. Продумать Backup и Replication
Нужно заранее определить RPO и RTO.
Шаг 7. Проверить компетенции команды
Сложная распределенная база без соответствующей эксплуатации может создать больше рисков, чем пользы.
Практический пример
Компания разрабатывает маркетплейс и использует несколько типов данных.
Заказы и платежи имеют строгие связи и транзакции, поэтому хранятся в PostgreSQL.
Каталог товаров имеет тысячи различных характеристик и размещается в MongoDB.
Популярные карточки кэшируются в Redis, чтобы уменьшить нагрузку.
Система рекомендаций использует отдельную модель данных для анализа связей между пользователями и товарами.
Каждый сервис получает хранилище, соответствующее его задачам.
При этом компания отдельно настраивает Backup, мониторинг и права для каждой Database.
Так NoSQL не заменяет SQL полностью, а становится частью Polyglot Persistence архитектуры.
NoSQL для бизнеса
NoSQL помогает компаниям создавать приложения, где данные не вписываются естественно в классические таблицы или где необходим специализированный способ масштабирования.
Документные базы ускоряют разработку гибких каталогов, Redis снижает latency, графовые системы помогают работать со сложными связями.
Но увеличение количества типов хранилищ повышает стоимость эксплуатации.
Поэтому для бизнеса важно выбирать NoSQL не ради технологической моды, а ради конкретного измеримого преимущества.
Когда стоит использовать NoSQL
- данные имеют гибкую документную структуру;
- нужно быстро получать значения по ключу;
- основной объект — сложный граф связей;
- требуется масштабирование больших распределенных Dataset;
- есть очень высокий поток однотипных операций;
- реляционная модель создает искусственную сложность;
- система использует Polyglot Persistence.
Когда SQL может быть лучше
Если приложение состоит из множества четко связанных сущностей, требует сложных JOIN, строгих ограничений и частых многотабличных транзакций, реляционная база часто оказывается проще.
SQL также удобен для ad hoc аналитики и универсальных запросов по связанным данным.
NoSQL не следует воспринимать как более современную замену SQL. Это другой набор инструментов.
Связанные термины
| Термин | Связь с NoSQL |
|---|---|
| MongoDB | Документоориентированная NoSQL СУБД |
| Redis | Key-value NoSQL хранилище |
| Document Database | Один из основных типов NoSQL |
| Key-Value | Модель хранения по ключу |
| Graph Database | Хранит узлы и связи |
| Wide-Column | Модель распределенного хранения данных |
| Sharding | Распределяет Dataset между узлами |
| Replication | Создает дополнительные копии данных |
| SQL | Основной язык классических реляционных систем |
| CAP theorem | Связана с компромиссами распределенных систем |
| Eventual Consistency | Модель согласованности части распределенных NoSQL |
| Polyglot Persistence | Использование разных баз для разных задач |
Краткий итог
NoSQL — это семейство нереляционных систем управления базами данных, включающее Document Database, Key-Value, Graph Database, Wide-Column и другие модели. Разные NoSQL-продукты решают принципиально разные задачи, поэтому сравнивать их только как одну альтернативу SQL некорректно.
Главные преимущества NoSQL проявляются в специализированных сценариях: гибкие документы, быстрый доступ по ключу, сложные графовые связи и распределение огромных Dataset. При этом гибкость требует более тщательного проектирования Schema, Queries, согласованности и масштабирования.
NoSQL не заменяет реляционные базы во всех проектах. На практике SQL и NoSQL часто работают вместе: PostgreSQL хранит транзакционные данные, MongoDB — документы, Redis — Cache. Правильный выбор определяется моделью данных, нагрузкой, требованиями к транзакциям и компетенциями команды.
