Developer

Выбор хранилища под задачу: polyglot persistence

↑ 6.1 Масштабирование и надёжность данных · ← Предыдущая

Желательно~4 мин чтенияУровень: senior

Зачем это на собесе

Итоговый архитектурный навык: подобрать хранилища под сценарии и связать их без потери согласованности.

Принцип

Нет универсальной БД. Каждое хранилище оптимизировано под свой шаблон доступа. Polyglot persistence: использовать несколько хранилищ, но ограничивать их число — каждое добавляет стоимость эксплуатации (бэкапы, мониторинг, обновления, компетенции).

Матрица выбора

ЗадачаХранилищеПочему
Транзакции, заказы, финансы, справочникиPostgreSQL (или MySQL, SQL Server)ACID, связи, зрелость
Кэш, сессии, лимиты, блокировки, лидербордыRedisпамять, структуры, задержки < 1 мс
Аналитика, события, отчёты, логи, метрикиClickHouseколоночное хранение, быстрые агрегации
Полнотекстовый поиск, фасеты, релевантностьElasticsearch / OpenSearch / Meilisearchинвертированный индекс, морфология
Файлы, медиа, бэкапы, data lakeS3 / MinIOдёшево, неограниченно, CDN
Документы с гибкой схемойMongoDB или PostgreSQL jsonbагрегаты «всё в одном»
Очереди и событияKafka / RabbitMQ / Redis Streamsпорядок, реплей, backpressure
Граф связей, рекомендацииNeo4j / рекурсивные CTEобход связей
Временные ряды, метрики мониторингаTimescaleDB / VictoriaMetrics / Prometheusкомпрессия, ретенция, агрегации по времени
ГеоданныеPostGISпространственные индексы
Глобально распределённые транзакцииCockroachDB / Spanner / YugabyteDBSQL + горизонтальная масштабируемость
Векторный поиск (эмбеддинги)pgvector, Qdrant, MilvusANN-индексы

Вопросы для выбора

  1. Модель данных: реляционная, документная, ключ–значение, граф, временной ряд?
  2. Шаблоны доступа: точечные чтения, диапазоны, агрегаты, полнотекстовый, запись потоком?
  3. Объём и рост: ГБ, ТБ, ПБ; скорость записи и чтения (RPS)?
  4. Консистентность: нужен ли ACID, допустимо ли eventual consistency?
  5. Задержка: sub-ms, десятки мс, секунды?
  6. Доступность и DR: RPO/RTO, регионы?
  7. Безопасность и соответствие: шифрование, аудит, резидентность данных, GDPR?
  8. Команда и эксплуатация: опыт, управляемый сервис или self-hosted, стоимость?
  9. Жизненный цикл: ретенция, архивация, удаление по запросу?

Паттерны интеграции

  • Единый источник истины (system of record): обычно транзакционная БД; остальные хранилища — производные (кэш, поиск, аналитика), которые можно пересобрать;
  • CDC / Outbox для синхронизации (см. предыдущую тему) вместо двойной записи;
  • CQRS: запись в нормализованную БД, чтение из оптимизированных представлений (Redis, Elasticsearch, ClickHouse);
  • Event sourcing: журнал событий как источник истины, проекции в разные хранилища;
  • Cache-aside и инвалидация по событиям;
  • Saga / outbox для согласованности между сервисами и хранилищами;
  • Идемпотентные потребители и возможность переиндексации/реплея.

Пример: интернет-магазин

PostgreSQL        — заказы, платежи, клиенты (источник истины)
Redis             — корзина, сессии, лимиты, кэш каталога
Elasticsearch     — поиск по каталогу (индекс строится из PostgreSQL через CDC)
ClickHouse        — события просмотров и аналитика продаж
MinIO/S3          — изображения товаров, счета (PDF)
Kafka             — события доменa и CDC

Поток: заказ создан → транзакция в PostgreSQL + запись outbox → Debezium → Kafka → потребители обновляют поиск, аналитику, отправляют уведомления.

Анти-паттерны

  • «модная» БД без обоснования (MongoDB вместо PostgreSQL для чисто реляционных данных);
  • несколько источников истины для одной сущности;
  • «синхронизация скриптом раз в сутки» там, где нужна согласованность;
  • использование Redis как основной БД без понимания persistence;
  • аналитика прямо на OLTP-БД под нагрузкой;
  • хранение файлов в БД;
  • взрыв числа технологий в небольшой команде.

Эволюция

Начинайте с PostgreSQL (+ jsonb, полнотекстовый поиск, pg_trgm, pgvector, расширения), добавляйте хранилища по измеренной необходимости: кэш при росте чтения, ClickHouse при тяжёлой аналитике, поиск при сложной релевантности, объектное хранилище для файлов.

Вопросы с ответами

Вид графа

Обратные ссылки