PostgreSQL vs ClickHouse¶
Тип материала: инженерное сравнение; выводы зависят от требований и условий эксплуатации. Схемы и примеры иллюстративны.
Область: PostgreSQL17; ClickHouse25.8. Численные latency/TPS/cost требуют измерений на сопоставимом workload с одинаковыми гарантиями.
Критерии выбора¶
| Критерий | PostgreSQL17 | ClickHouse25.8 |
|---|---|---|
| Workload | Короткие transactions, point/range reads, constraints | Column scans, GROUP BY, append-heavy analytics |
| Consistency | ACID одной базы; isolation и locks; unique constraints | MergeTree semantics; нет общей OLTP unique/multi-table гарантии |
| Latency | Point latency зависит от index/cache/locks | Batch scans и pruning; свежесть ingestion/query-time dedup отдельно |
| Throughput | Write bottleneck: WAL, indexes, locks, hot row | Ingest bottleneck: parts/merges, shard skew и memory aggregation |
| Cost | Rows/indexes/WAL/replicas и active working set | Compression экономит scan/storage; replicas/merges/FINAL стоят ресурсов |
| Scalability | Scale-up/read replicas; sharding требует отдельного решения | Shards+replicas встроенными engine paths; distributed queries имеют overhead |
| Operational complexity | Vacuum, locks, PITR и replication slots | Parts/merges, Keeper, dedup, MVs, backup и lag |
flowchart LR
Commands --> PG[PostgreSQL transaction]
PG --> Outbox[Committed outbox]
Outbox --> Kafka
Kafka --> CH[ClickHouse read model]Конкретные сценарии¶
Wallet debit с двумя проводками → PostgreSQL при подходящей local boundary. Daily betting turnover по миллионам immutable events → ClickHouse после корректного version/dedup контракта. Совместная схема → PG outbox/CDC → Kafka → CH, где финансовый факт и аналитическая видимость наблюдаются раздельно.
Ограничения и отказы¶
Не переносить сумму по raw CH rows в settlement без выбора последней версии; не направлять бесконечные scans на wallet primary. Потеря ответа commit и Kafka replay требуют idempotency на разных уровнях.
Как принять и проверить решение¶
Зафиксировать 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.