Средний ~25 мин чтения

Типы NoSQL: колоночные, графовые и поисковые

Урок 4 из 5 в курсе NoSQL базы данных

Типы NoSQL: колоночные, графовые и поисковые

помимо документных БД и Redis существуют колоночные (Cassandra), графовые (Neo4j), поисковые (Elasticsearch) и time-series (InfluxDB) хранилища

Почему это важно: зная все типы NoSQL, можно выбрать правильный инструмент для задачи вместо работы против ограничений неподходящей БД

Главная идея

каждый тип NoSQL оптимизирован для конкретного паттерна доступа к данным; универсальной лучшей БД не существует

Как это выглядит на практике

  1. Wide-column (Cassandra): миллиарды записей событий, пишем часто, читаем по partition key. Cassandra.
  2. Graph (Neo4j): 'друзья моих друзей которые смотрели X' — сложные связи. Neo4j.
  3. Search (Elasticsearch): полнотекстовый поиск по миллионам документов с релевантностью. Elasticsearch.
  4. Time-series (InfluxDB/TimescaleDB): метрики CPU каждые 10 секунд, агрегация по времени. InfluxDB.
  5. Key-value (DynamoDB): миллионы запросов в секунду по одному ключу, предсказуемая latency. DynamoDB.

Что происходит под капотом

  • Cassandra: consistent hashing, partition key → node. Tunable consistency: ONE, QUORUM, ALL.
  • Neo4j: native graph storage; nodes и relationships хранятся с pointer к соседям — traversal за O(1).
  • Elasticsearch: inverted index для полнотекстового поиска; relevance scoring (TF-IDF, BM25).
  • InfluxDB: TSM (Time-Structured Merge Tree) оптимизирован для write-heavy временных рядов.
  • Dynamo-style БД (DynamoDB, Cassandra): eventual consistency по умолчанию; leaderless replication.

Типичные ошибки и заблуждения

  • Ошибка: Elasticsearch — основная БД. ES оптимизирован для поиска, не для транзакций. Используй как дополнение к PostgreSQL.
  • Ошибка: Cassandra подходит для любых NoSQL-задач. Cassandra плохо подходит для случайных UPDATE и сложных запросов; она оптимизирована для append-heavy workloads.
  • Ошибка: Neo4j нужен только для социальных сетей. Граф подходит для любых связанных данных: рекомендации, fraud detection, knowledge graphs.
  • Ошибка: time-series данные можно хранить в PostgreSQL. Можно, но специализированные TSDB на порядок эффективнее для метрик.

Ключевые выводы

  • Cassandra: write-heavy, partition-key-based access, huge scale.
  • Elasticsearch: полнотекстовый поиск + аналитика.
  • Neo4j: traversal по связям — рекомендации, fraud detection.
  • Специализированное хранилище всегда эффективнее общего для своей задачи.

Термины урока

Wide-column store: хранит данные в строках с динамическими столбцами (Cassandra, HBase).
Graph database: хранит данные как узлы и рёбра с атрибутами (Neo4j, Amazon Neptune).
Inverted index: структура поискового движка; термин → список документов.
Time-series database: БД, оптимизированная для временных рядов (InfluxDB, TimescaleDB).
Partition key: ключ, определяющий, на каком узле хранятся данные в distributed БД.

Связь с работой backend-разработчика

Добавляй специализированные БД решая конкретную проблему: нужен полнотекстовый поиск → Elasticsearch; нужны метрики → InfluxDB/Prometheus. Не добавляй 'про запас' — каждая БД = операционная нагрузка.

Мини-разбор реальной ситуации

Команда добавляет полнотекстовый поиск через PostgreSQL LIKE '%query%' — медленно, нет релевантности. Переход на Elasticsearch: индексируем PostgreSQL данные через логическую репликацию, запросы через ES API. Поиск по 10M документов: 5ms, с релевантностью и highlight.

Что запомнить

  • Cassandra — write-heavy append; не для случайных обновлений.
  • Elasticsearch — поиск и аналитика; не основная БД.
  • Каждая дополнительная БД = операционная сложность.

Итог

Знание разных типов NoSQL — это знание инструментов. Правильный инструмент для задачи решает проблему элегантно; неправильный — создаёт новые.