Решения по хранилищам данных

NOTE

Статус: Target design. Документ описывает целевую архитектуру. Сервисы, модули и контракты, упомянутые ниже, могут ещё не существовать в backend/. Правила маркировки — в 50-processes/documentation-standard.md.

Сводная таблица по используемым хранилищам и их ролям. Каждое решение подкреплено ADR.

Матрица “что где”

ДанныеИсточник истиныRead-оптимизацияИстория / Аналитика
Canonical productPostgreSQL (event_store + projection)Elasticsearch (search index)PostgreSQL event_store
Supplier offer (current)PostgreSQLElasticsearch (facets)ClickHouse
ManufacturerPostgreSQL (event_store + projection)Redis cachePostgreSQL event_store
Characteristic catalogPostgreSQLRedis cache
Price (current)PostgreSQLRedis cacheClickHouse (history)
Stock (current)PostgreSQLRedis cacheClickHouse (history)
Raw payloadS3 / MinIO— (archive)
Media (images, cert.)S3 / MinIO (+ CDN)CDN
Event logPostgreSQL event_store → Kafka (distribution)ClickHouse (для long-range analytics)
Price rulesPostgreSQLIn-memory cache per servicePostgreSQL
Identity profilesPostgreSQLIn-memory cachePostgreSQL
SessionsRedisRedis
Rate limiter stateRedisRedis
Learned cache (AI, aliases)PostgreSQLRedis

Почему какие

PostgreSQL — primary

  • ACID, богатая реляционная модель, JSONB для плоских характеристик, pg_trgm для fuzzy внутри PG, отличная операционная зрелость.
  • См. ADR-0004.

Kafka — event bus

  • Durable, partitioned log, compacted topics для snapshot-стримов, хорошая интеграция с CH, зрелый экосистемный tooling.
  • См. ADR-0002.
  • Команда имеет опыт, богатые аналайзеры, dense_vector для embedding, faceted-фильтрация, explainability из коробки.
  • См. ADR-0006.

ClickHouse — analytics & history

  • Колоночная, идеальна для append-only истории цен/остатков, Kafka engine для ingestion, время ответа на агрегационные запросы.

Redis — cache / rate limit / locks

  • In-memory, token bucket для rate limiter, pub/sub для инвалидации, distributed lock через Redlock.

S3 / MinIO — raw + media

  • Дёшево для больших объёмов, immutable-by-convention, S3 API стандарт, лёгкая замена на облачный при миграции.

Что не используется

  • MongoDB — JSONB в PG покрывает кейсы гибкой схемы. Нет reasons иметь отдельную document store. См. ADR-0005.
  • OpenSearch — выбран Elasticsearch из-за экспертизы команды. См. ADR-0006.
  • NATS — выбран Kafka (event sourcing + compacted). См. ADR-0002.
  • TimescaleDB — ClickHouse покрывает time-series; экспертизы в Timescale нет.

Размеры и retention (оценки)

StoreОжидаемый объём на год 1Retention
PostgreSQL primary~200 GBбессрочно
PostgreSQL event_store~500 GB1 год active + archive
Elasticsearch~300 GBlive index, reindex on demand
ClickHouse~2 TB2+ года, затем downsample
S3 raw payloads~5 TB90 дней hot, 1 год warm (TBD)
S3 media~500 GBбессрочно (CDN)
Redis~20 GBevictable