Какие существуют типы NoSQL баз данных?

Основная идея

Существует 4 основных типа NoSQL баз данных, каждый оптимизирован для определённых сценариев: Key-Value (простые пары ключ-значение), Document (JSON-документы), Column-family (колоночное хранение) и Graph (узлы и связи).

Ключевые аспекты

Key-Value — самый простой тип: ключ → значение. Примеры: Redis, Memcached, DynamoDB. Используется для кэша, сессий, счётчиков
Document — хранит JSON/BSON документы с вложенной структурой. Примеры: MongoDB, CouchDB, Firestore. Для контента, каталогов, профилей
Column-family — данные сгруппированы по колонкам, не по строкам. Примеры: Cassandra, HBase. Для time-series, аналитики, IoT
Graph — узлы (entities) и рёбра (связи). Примеры: Neo4j, Neptune. Для социальных сетей, рекомендаций, fraud detection

Как выбрать тип

Нужен быстрый доступ по ключу → Key-Value
Структурированные данные с запросами → Document
Временные ряды, аналитика → Column-family
Много связей между сущностями → Graph

Частые ошибки на собеседованиях

Путают Column-family с колоночными OLAP базами (Clickhouse, Vertica) — это разные концепции
Считают, что Document DB не может хранить связи — может, через ссылки (DBRef) или embedding
Не знают, что DynamoDB — гибрид Key-Value и Document
Забывают про полнотекстовый поиск — Elasticsearch тоже Document DB, но специализированная

Введение и проблематика

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

Почему разные типы?

Универсального решения не существует. Разные данные и паттерны доступа требуют разных моделей хранения:

Кэш и сессии → быстрый доступ по ключу
Каталоги и профили → сложные вложенные структуры
Временные ряды → эффективная запись и агрегация
Социальные связи → быстрый обход графа

Базовая теория

4 основных типа NoSQL баз данных

graph TB
    A[NoSQL Database Types] --> B[Key-Value]
    A --> C[Document]
    A --> D[Column-family]
    A --> E[Graph]
 
    B --> B1[Redis]
    B --> B2[Memcached]
    B --> B3[DynamoDB]
 
    C --> C1[MongoDB]
    C --> C2[CouchDB]
    C --> C3[Firestore]
 
    D --> D1[Cassandra]
    D --> D2[HBase]
    D --> D3[ScyllaDB]
 
    E --> E1[Neo4j]
    E --> E2[Neptune]
    E --> E3[ArangoDB]

Подробный разбор каждого типа

Key-Value хранилища

Модель данных: Простейшая — ключ (строка) указывает на значение (blob/строка).

text

"user:123"     → "{name: 'John', age: 30}"
"session:abc"  → "encrypted-session-data"
"counter:page" → "15847"

Особенности:

Минимальная латентность (O(1) операции)
Не понимает структуру значения
Запросы только по точному ключу
Простейшее масштабирование

Примеры баз данных:

БД	Особенности
Redis	In-memory, структуры данных (lists, sets, sorted sets)
Memcached	Распределённый кэш, только строки
DynamoDB	AWS managed, поддержка вторичных индексов
etcd	Конфигурации, service discovery

Типичные use cases:

Кэширование (результаты запросов, HTML)
Сессии пользователей
Rate limiting и счётчики
Очереди сообщений
Pub/Sub (Redis)

// Redis пример
import Redis from 'ioredis';
const redis = new Redis();
 
// Базовые операции
await redis.set('user:123', JSON.stringify({ name: 'John' }));
const user = JSON.parse(await redis.get('user:123'));
 
// TTL — данные автоматически удаляются
await redis.setex('session:abc', 3600, 'token'); // 1 час
 
// Атомарный инкремент
await redis.incr('page:views');

Сравнительная таблица

Характеристика	Key-Value	Document	Column-family	Graph
Модель	key → value	key → JSON	row → columns	nodes + edges
Запросы	По ключу	По полям	По row key + columns	Обход графа
Схема	Нет	Гибкая	Определена	Гибкая
Связи	Нет	Embedding/Reference	Нет	Нативные
Масштабирование	Отличное	Хорошее	Отличное	Сложное
Транзакции	Ограниченные	ACID (MongoDB 4.0+)	Ограниченные	ACID

Пограничные кейсы

⚠️

Column-family ≠ Columnar OLAP! Cassandra (column-family) и ClickHouse (columnar) — разные концепции. Column-family группирует колонки по семействам, columnar хранит каждую колонку отдельно для аналитики.

Некоторые базы являются multi-model: ArangoDB (Document + Graph), CosmosDB (все 4 типа), FaunaDB (Document + Graph).

Гибридные решения

DynamoDB

Key-Value + Document. Поддерживает простые запросы по атрибутам через Secondary Indexes.

Redis + RedisJSON

Key-Value с модулем для работы с JSON полями.

ArangoDB

Полноценная поддержка Document и Graph моделей в одной БД.

Как выбрать тип NoSQL

graph TD
    A[Какие данные?] --> B{Простые key-value?}
    B -->|Да| C[Key-Value: Redis, DynamoDB]
    B -->|Нет| D{Много связей между сущностями?}
    D -->|Да| E[Graph: Neo4j, Neptune]
    D -->|Нет| F{Временные ряды / аналитика?}
    F -->|Да| G[Column-family: Cassandra, ScyllaDB]
    F -->|Нет| H[Document: MongoDB, Firestore]

Вопросы интервьюера

Q: Когда выбрать Column-family вместо Document DB?

Когда основной паттерн — запись временных рядов или данных IoT. Cassandra оптимизирована для write-heavy нагрузок и time-series данных.

Q: Можно ли моделировать граф в Document DB?

Можно через ссылки (references) или embedding, но обход связей будет медленным. Для глубоких связей (friends of friends) Graph DB будет на порядки быстрее.

Q: Почему Redis быстрее MongoDB?

Redis хранит данные in-memory и оптимизирован для простых операций. MongoDB работает с диском и поддерживает сложные запросы, индексы, агрегации.

Q: Что такое wide-column store?

Другое название для Column-family. "Wide" означает, что строка может иметь очень много колонок (миллионы), и разные строки могут иметь разные колонки.

NodeJS Back-end Инженер