Redis vs PostgreSQL для counters и state¶

Сравнения · Раздел 02

Тип материала: инженерное сравнение; выводы зависят от требований и условий эксплуатации. Схемы и примеры иллюстративны.

Область: Redis7.4; PostgreSQL17. Численные latency/TPS/cost требуют измерений на сопоставимом workload с одинаковыми гарантиями.

Критерии выбора¶

Критерий	Redis7.4	PostgreSQL17
Workload	Ephemeral/materialized counters, features, cache	Authoritative transactional state и durable audit
Consistency	Atomic command/Lua без rollback/durable consensus	ACID local transaction; isolation, constraints и durable log policy
Latency	Memory access; network, hot key, script/fork stalls	Index/cache/locks/fsync; соединения и batching влияют
Throughput	Независимые keys scale через Cluster; один key serial	Hot row serial; batch/partition design меняет contention
Cost	RAM, replicas, persistence и reconstruction	Storage/WAL/indexes, HA и maintenance
Scalability	Hash slots; multi-key scope ограничен slot	Scale-up/read replicas; application sharding отдельно
Operational complexity	Eviction/TTL, AOF/RDB, failover, warm-up	Locks/vacuum, PITR, fencing и reconciliation

flowchart LR
  Request --> Kind[Required state semantics]
  Kind --> Feature[Rebuildable counter or feature]
  Kind --> Money[Authoritative monetary invariant]
  Feature --> Redis
  Money --> PostgreSQL

Конкретные сценарии¶

Лимит API запросов с допускаемым reset → Redis sliding window. Денежный balance и idempotent debit → PG ledger. Antifraud feature → Redis projection от Kafka/Flink, PostgreSQL/другой durable store хранит финансовое решение при нужной модели.

Ограничения и отказы¶

Atomic INCR не обеспечивает идемпотентность повторов. Redis WAIT не равен synchronous consensus. PG counter тоже может тормозить на одной строке; sharded approximate counter не сохраняет автоматически hard global limit.

Как принять и проверить решение¶

Зафиксировать query mix, data distribution/skew, payload, working set, retention, concurrency, authoritative boundary и допустимую stale-read policy. Проверять steady state и maintenance, lost ACK, node loss, replay и restore. Сопоставлять total cost при одинаковых durability/replication requirements. Не объявлять универсального победителя по одному среднему времени запроса.

Типичные ошибки проектирования¶

Сравнивать default eventual/cache path с durable transactional commit; игнорировать operations/recovery; переносить benchmark другого dataset; выбирать продукт до определения access pattern.

Вопросы на собеседовании¶

Можно ли использовать варианты вместе? Да, если роли, data contracts и способы reconciliation определены. Дополнительная projection добавляет lag, replay и ownership, поэтому её польза должна покрывать эту сложность.

Практические упражнения¶

Для одного сценария выше составьте ADR: invariant, выбранный вариант, отклонённая альтернатива, failure outcomes и план измерений. Не задавайте придуманные TPS/SLA; перечислите входные данные, необходимые для sizing.