# NoSQL

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

Источник: https://llmdocs.ru/wiki/nosql/ · обновлено 2026-11-09 · лицензия CC BY-SA 4.0

- **Расшифровка**: «не только SQL» (Not only SQL)
- **Возрождение термина**: 2009
- **Типы**: ключ-значение, документные, широкие колонки, графовые
- **Примеры**: Redis, DynamoDB, MongoDB, Cassandra, HBase, Neo4j
- **Основополагающие работы**: Google Bigtable (2006), Amazon Dynamo (2007)
- **Модель согласованности**: часто BASE и итоговая согласованность
**NoSQL** — собирательное название баз данных, которые не следуют классической [реляционной модели](https://llmdocs.ru/wiki/relational-database.md) с таблицами, жёсткой схемой и языком [SQL](https://llmdocs.ru/wiki/sql.md). Сейчас термин чаще расшифровывают как «не только SQL» (*Not only SQL*). Под ним объединяют очень разные системы: хранилища «ключ — значение», документные, колоночные и графовые базы. Общее у них — отказ от части возможностей реляционных СУБД ради горизонтального масштабирования, гибкой схемы, высокой доступности или более подходящей модели данных.

## История

Название впервые использовал Карло Строцци в 1998 году для своей облегчённой реляционной базы без SQL-интерфейса. Современное значение термин получил в 2009 году, когда на встрече в Сан-Франциско обсуждали распределённые нереляционные хранилища. Им предшествовали работы интернет-гигантов, столкнувшихся с объёмами, которые не помещались на один сервер: Google описала **Bigtable** (2006),[1] Amazon — **Dynamo** (2007).[2] На их идеях выросли HBase, Cassandra, Riak, DynamoDB. Параллельно появились документная MongoDB (2009) и графовая Neo4j.

## Типы NoSQL-баз

| Тип | Модель | Примеры | Типичные задачи |
|---|---|---|---|
| Ключ — значение | словарь: ключ → значение | [Redis](https://llmdocs.ru/wiki/redis.md), DynamoDB, etcd | кэш, сессии, конфигурация |
| Документные | JSON-подобные документы с вложенностью | [MongoDB](https://llmdocs.ru/wiki/mongodb.md), Couchbase, Firestore | каталоги, профили, контент |
| Широкие колонки | строки с переменным набором столбцов, распределённые по ключу | Cassandra, HBase, ScyllaDB | журналы событий, телеметрия, огромные объёмы записи |
| Графовые | вершины и рёбра со свойствами | Neo4j, JanusGraph | социальные связи, рекомендации, графы знаний |

Отдельно стоят векторные базы для [эмбеддингов](https://llmdocs.ru/wiki/embedding.md) (см. [pgvector и векторные БД](https://llmdocs.ru/wiki/pgvector.md)), базы временных рядов (InfluxDB, TimescaleDB) и поисковые движки (Elasticsearch, OpenSearch), которые тоже иногда относят к NoSQL.

## Примеры моделей

Документ в MongoDB хранит заказ со всеми позициями внутри — то, что в реляционной базе заняло бы несколько таблиц:

```json
{
  "_id": "ord-1001",
  "customer": {"id": 42, "name": "Алиса"},
  "items": [
    {"sku": "BOOK-1", "qty": 1, "price": 900},
    {"sku": "PEN-7", "qty": 3, "price": 50}
  ],
  "status": "paid"
}
```

В графовой базе запрос «друзья друзей, которые купили этот товар» выражается естественно на языке Cypher:[6]

```cypher
MATCH (me:User {id: 42})-[:FRIEND]->()-[:FRIEND]->(fof)-[:BOUGHT]->(p:Product {sku: "BOOK-1"})
RETURN DISTINCT fof.name
```

## Согласованность: ACID, BASE и CAP

Многие распределённые NoSQL-системы ради доступности и масштабирования отказывались от строгих [ACID-транзакций](https://llmdocs.ru/wiki/transaction-acid.md) в пользу модели **BASE** (*Basically Available, Soft state, Eventual consistency*): система всегда отвечает, но реплики могут какое-то время расходиться и сходятся со временем (*итоговая согласованность*).

Компромисс формализует [CAP-теорема](https://llmdocs.ru/wiki/cap-theorem.md): при сетевом разделении распределённая система вынуждена выбирать между согласованностью и доступностью.[3] Cassandra и Dynamo выбирают доступность с настраиваемыми кворумами, HBase и etcd — согласованность.

## Сильные стороны

- **Горизонтальное масштабирование.** Данные изначально распределяются по многим узлам ([шардирование](https://llmdocs.ru/wiki/sharding.md) встроено), и кластер растёт добавлением серверов.
- **Гибкая схема.** Документы одной коллекции могут иметь разную структуру; новые поля добавляются без миграций.
- **Модель под задачу.** Агрегат, который читается целиком, хранится вместе — без соединений; связи в графе обходятся быстрее рекурсивных SQL-запросов.
- **Высокая доступность** и запись в нескольких дата-центрах.

## Слабые стороны

- **Запросы проектируются заранее.** В Cassandra таблицы строят под конкретные запросы; новый вид выборки может потребовать новой таблицы и дублирования данных.
- **Целостность в коде.** Нет внешних ключей и часто нет транзакций между документами — согласованность обеспечивает приложение (см. [Нормализация](https://llmdocs.ru/wiki/normalization.md)).
- **Разнородность.** Каждая система — свой язык запросов, инструменты и подводные камни.

## Сближение миров

Границы размылись. Реляционные СУБД научились хранить документы ([PostgreSQL](https://llmdocs.ru/wiki/postgresql.md) с `jsonb`), векторы и временные ряды; появились распределённые SQL-базы (CockroachDB, YugabyteDB, Google Spanner) с горизонтальным масштабированием и ACID. NoSQL-системы, в свою очередь, добавили транзакции (MongoDB с версии 4.0) и SQL-подобные языки. Мартин Фаулер и Прамод Садаладж описали этот подход как **полиглотное хранение**: каждая часть системы использует подходящее ей хранилище.[4] Для многих проектов разумная отправная точка — PostgreSQL, а специализированные базы добавляются под конкретные нагрузки.

## См. также

- [Redis](https://llmdocs.ru/wiki/redis.md)
- [MongoDB](https://llmdocs.ru/wiki/mongodb.md)
- [CAP-теорема](https://llmdocs.ru/wiki/cap-theorem.md)
- [Реляционная база данных](https://llmdocs.ru/wiki/relational-database.md)
- [Шардирование](https://llmdocs.ru/wiki/sharding.md)

## Источники

1. [F. Chang et al. — Bigtable: A Distributed Storage System for Structured Data (OSDI 2006)](https://research.google/pubs/bigtable-a-distributed-storage-system-for-structured-data/)
2. [G. DeCandia et al. — Dynamo: Amazon's Highly Available Key-value Store (SOSP 2007)](https://www.allthingsdistributed.com/files/amazon-dynamo-sosp2007.pdf)
3. [S. Gilbert, N. Lynch — Brewer's conjecture and the feasibility of consistent, available, partition-tolerant web services (2002)](https://dl.acm.org/doi/10.1145/564585.564601)
4. [P. Sadalage, M. Fowler — NoSQL Distilled](https://martinfowler.com/books/nosql.html)
5. [Apache Cassandra Documentation](https://cassandra.apache.org/doc/latest/)
6. [Neo4j — Cypher Manual: Introduction](https://neo4j.com/docs/cypher-manual/current/introduction/)