Как сравнить ClickHouse с альтернативами по consistency, latency, throughput, cost и operability?

Краткая сводка

-- Условные эталонные запросы для бенчмарка
-- ClickHouse: ~100ms
SELECT toDate(ts), count(), avg(duration_ms)
FROM page_views
WHERE project_id = 42 AND ts >= '2024-01-01'
GROUP BY 1
ORDER BY 1;

Контекст сравнения

При выборе аналитического хранилища обычно сравнивают ClickHouse с BigQuery, Snowflake, Redshift, Apache Druid, Apache Pinot и TimescaleDB. Ниже — структурированное сравнение по пяти критериям.

Consistency (согласованность)

• ClickHouse: eventual consistency в кластерном режиме (ReplicatedMergeTree + ZooKeeper/ClickHouse Keeper). Запись считается успешной, когда данные попали на одну реплику; другие реплики догоняют асинхронно. Чтение с select_sequential_consistency=1 гарантирует строгую консистентность ценой дополнительных round-trip'ов к ZooKeeper.
• BigQuery / Snowflake: strong consistency по умолчанию. После COMMIT данные сразу видны всем читателям. Проще для ACID-сценариев.
• Apache Druid: near-real-time сегменты могут быть видны раньше, чем полностью реплицированы. Аналогично eventual consistency.
• TimescaleDB: PostgreSQL под капотом — полный ACID, strong consistency.

Latency (задержка запросов)

• ClickHouse: лидер для аналитических запросов sub-second при объёмах до триллиона строк на self-hosted кластере. Медианный запрос над миллиардом строк — 50-500 мс.
• BigQuery: serverless, холодный старт вносит 1-5 секунд накладных расходов; BI Engine снижает до сотен мс для кэшированных запросов.
• Snowflake: виртуальные склады масштабируются, но «warming» занимает секунды; конкурентные слоты ограничены размером склада.
• Druid: оптимизирован для sub-second ad-hoc запросов по временным рядам с pre-aggregation (rollup); хуже ClickHouse на сырых данных без rollup.
• TimescaleDB: хорошо на OLTP-объёмах (миллионы строк), заметно медленнее на миллиардах.

Throughput (пропускная способность записи)

• ClickHouse: 500k–2M строк/сек на одном сервере при batch-INSERT; очень высокий throughput за счёт сжатия и колоночного хранения.
• Druid / Pinot: разработаны для streaming-ingest из Kafka; Pinot показывает сопоставимый throughput при real-time сегментах.
• BigQuery / Snowflake: Streaming API BigQuery — до 1M строк/сек, но дороже batch-загрузки; Snowflake Streaming тоже платный.
• TimescaleDB: ограничен PostgreSQL WAL и checkpoint'ами; при гипертаблицах — порядка 100-300k строк/сек.

Cost (стоимость)

• ClickHouse (self-hosted): платите только за инфраструктуру. При больших объёмах — кратно дешевле облачных OLAP. ClickHouse Cloud — pay-per-use, сравнимо с BigQuery.
• BigQuery: $5 за TB отсканированных данных (on-demand) или flat-rate. Неожиданные большие запросы могут создать крупные счета.
• Snowflake: оплата по compute (credits) + storage. При непрерывной нагрузке дороже ClickHouse; при редких ad-hoc запросах — дешевле (склад выключен).
• Druid: self-hosted, требует отдельных Broker/Coordinator/Historical нод — операционно сложнее и дороже ClickHouse по TCO.
• TimescaleDB: Timescale Cloud дёшево для небольших объёмов; при сотнях GB быстро растёт.

Operability (операционная зрелость)

• ClickHouse: богатые встроенные системные таблицы (system.query_log, system.merges, system.replication_queue), Prometheus-экспорт, ClickHouse Keeper. Требует экспертизы в настройке MergeTree, репликации и ZooKeeper.
• BigQuery / Snowflake: fully managed, zero ops. Идеальны для команд без DBA.
• Druid: наиболее сложен в эксплуатации: 5+ типов нод, Zookeeper, отдельное глубокое хранилище (S3). Высокая кривая обучения.
• TimescaleDB: наследует PostgreSQL ecosystem (pg_dump, pgBackRest, Patroni), что упрощает операционную работу для команд с PostgreSQL-опытом.

Подводные камни

• Latency != latency: ClickHouse быстр при прогретом кэше страниц ОС; холодные запросы с диска могут быть медленнее облачных MPP-систем с кэшированием результатов.
• Consistency: eventual по умолчанию может удивить: сразу после INSERT данные могут быть не видны на репликах без явного select_sequential_consistency.
• BigQuery стоимость непредсказуема: один неоптимальный запрос без LIMIT может просканировать петабайт и стоить сотни долларов.
• Druid rollup — не серебряная пуля: pre-aggregation теряет raw данные; ретроспективная аналитика с новыми измерениями требует перезагрузки.
• Snowflake concurrency limit: виртуальный склад одного размера имеет лимит параллельных запросов; при превышении запросы ставятся в очередь.
• ClickHouse операционная сложность: настройка репликации, управление ZooKeeper/Keeper, балансировка шардов требует выделенного DevOps-ресурса.
• TimescaleDB плохо масштабируется горизонтально: Citus extension добавляет шардинг, но это другой продукт со своими ограничениями.

• Сравнивать ClickHouse с альтернативами по одному признаку
• Путать личную привычку с инженерным критерием выбора
• Не учитывать migration cost и vendor/ecosystem lock-in

• Сравнивает ClickHouse по нескольким инженерным осям
• Не путает популярность с пригодностью
• Понимает migration cost и долгосрочную поддержку