llmdocsсправочник разработчика

NoSQL

Материал из llmdocs — справочник разработчика
Портал: Базы данных
NoSQL
Расшифровка«не только SQL» (Not only SQL)
Возрождение термина2009
Типыключ-значение, документные, широкие колонки, графовые
ПримерыRedis, DynamoDB, MongoDB, Cassandra, HBase, Neo4j
Основополагающие работыGoogle Bigtable (2006), Amazon Dynamo (2007)
Модель согласованностичасто BASE и итоговая согласованность

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

История

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

Типы NoSQL-баз

Тип Модель Примеры Типичные задачи
Ключ — значение словарь: ключ → значение Redis, DynamoDB, etcd кэш, сессии, конфигурация
Документные JSON-подобные документы с вложенностью MongoDB, Couchbase, Firestore каталоги, профили, контент
Широкие колонки строки с переменным набором столбцов, распределённые по ключу Cassandra, HBase, ScyllaDB журналы событий, телеметрия, огромные объёмы записи
Графовые вершины и рёбра со свойствами Neo4j, JanusGraph социальные связи, рекомендации, графы знаний

Отдельно стоят векторные базы для эмбеддингов (см. pgvector и векторные БД), базы временных рядов (InfluxDB, TimescaleDB) и поисковые движки (Elasticsearch, OpenSearch), которые тоже иногда относят к NoSQL.

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

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

{
  "_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]

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

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

Многие распределённые NoSQL-системы ради доступности и масштабирования отказывались от строгих ACID-транзакций в пользу модели BASE (Basically Available, Soft state, Eventual consistency): система всегда отвечает, но реплики могут какое-то время расходиться и сходятся со временем (итоговая согласованность).

Компромисс формализует CAP-теорема: при сетевом разделении распределённая система вынуждена выбирать между согласованностью и доступностью.[3] Cassandra и Dynamo выбирают доступность с настраиваемыми кворумами, HBase и etcd — согласованность.

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

  • Горизонтальное масштабирование. Данные изначально распределяются по многим узлам (шардирование встроено), и кластер растёт добавлением серверов.
  • Гибкая схема. Документы одной коллекции могут иметь разную структуру; новые поля добавляются без миграций.
  • Модель под задачу. Агрегат, который читается целиком, хранится вместе — без соединений; связи в графе обходятся быстрее рекурсивных SQL-запросов.
  • Высокая доступность и запись в нескольких дата-центрах.

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

  • Запросы проектируются заранее. В Cassandra таблицы строят под конкретные запросы; новый вид выборки может потребовать новой таблицы и дублирования данных.
  • Целостность в коде. Нет внешних ключей и часто нет транзакций между документами — согласованность обеспечивает приложение (см. Нормализация).
  • Разнородность. Каждая система — свой язык запросов, инструменты и подводные камни.

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

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

См. также

Источники

  1. F. Chang et al. — Bigtable: A Distributed Storage System for Structured Data (OSDI 2006)
  2. G. DeCandia et al. — Dynamo: Amazon's Highly Available Key-value Store (SOSP 2007)
  3. S. Gilbert, N. Lynch — Brewer's conjecture and the feasibility of consistent, available, partition-tolerant web services (2002)
  4. P. Sadalage, M. Fowler — NoSQL Distilled
  5. Apache Cassandra Documentation
  6. Neo4j — Cypher Manual: Introduction
Категории: