PostgreSQL vs Cassandra / ScyllaDB¶
Тип материала: инженерное сравнение; выводы зависят от требований и условий эксплуатации. Схемы и примеры иллюстративны.
Область: PostgreSQL17; Cassandra5.0 / ScyllaDB2025.1. Численные latency/TPS/cost требуют измерений на сопоставимом workload с одинаковыми гарантиями.
Критерии выбора¶
| Критерий | PostgreSQL17 | Cassandra5.0 / ScyllaDB2025.1 |
|---|---|---|
| Workload | Relational queries и multi-row local invariants | Query-driven partition-key access и event history |
| Consistency | Transaction isolation, unique/FK/exclusion constraints | Tunable CL; timestamp resolution; ограниченный LWT scope и version support |
| Latency | Index lookup + transaction overhead | Known-partition reads; fan-out и compaction влияют на tail |
| Throughput | Hot-row serialization, WAL/index cost | Distributed independent partitions; hot partition не исчезает |
| Cost | Primary/replica, indexes, WAL и operations | RF, compaction/repair/headroom, denormalized tables и fan-out |
| Scalability | Write sharding не встроен в обычный PG | Распределение partitions; topology/rebalance требует capacity |
| Operational complexity | Vacuum/PITR/locks | Repair/tombstones/compaction/token or tablet placement |
flowchart LR
Workload --> Invariant[Multi-row monetary invariant]
Invariant --> PG[Local SQL transaction]
Workload --> Event[Independent keyed events]
Event --> Wide[Partitioned wide-column store]Конкретные сценарии¶
Cross-account transfer → PG при одном transaction scope. High-volume per-player event history с bounded buckets → Cassandra/ScyllaDB. Global lookup по arbitrary predicate → отдельная модель/index/analytics, а не ALLOW FILTERING на event store.
Ограничения и отказы¶
LOCAL_QUORUM не заменяет SERIALIZABLE; RF не backup. Для ScyllaDB2025.1 LWT в tablets keyspaces не поддерживается. PG partitioning не даёт того же placement, что Cassandra partitions.
Как принять и проверить решение¶
Зафиксировать 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.