1. Когда ClickHouse перестаёт справляться
ClickHouse — блестящий движок для single-table scan и агрегаций: колоночное хранение, векторизированное выполнение, впечатляющая скорость на простых запросах. Созданный в Яндексе, он стал стандартом для лог-аналитики и метрик.
Но когда задачи усложняются — появляются боли, которые заставляют искать альтернативы:
- JOIN-производительность: ClickHouse исторически слаб на multi-table JOIN. До недавнего времени не было полноценного CBO — оптимизатор не умел выбирать стратегию JOIN.
- Real-time updates: ReplacingMergeTree обеспечивает eventual дедупликацию через фоновые merge. Нет настоящего UPSERT, нет partial update — до merge читаешь дубли.
- Дедупликация: ключевое слово FINAL на ReplacingMergeTree убивает производительность чтения, так как запускает merge on-the-fly.
- SQL-полнота: ~50% запросов TPC-DS не выполняются — correlated subqueries, сложные CTE, ряд window functions не поддерживаются.
- Операционная сложность: ручной шардинг через ClickHouse Keeper/ZooKeeper, отсутствие автоматического ребалансинга данных.
2. Архитектура: append-only движок vs unified lakehouse
Ключевое различие — в модели обработки обновлений и управления кластером.
| ClickHouse | Apache Doris |
|---|---|
| MergeTree family — append-only с фоновыми merge | Columnar MPP, FE+BE архитектура с автобалансировкой |
| Ручной шардинг через ClickHouse Keeper / ZooKeeper | MySQL-протокол — JDBC/ODBC подключение без адаптеров |
| Собственный SQL-диалект (не MySQL/PostgreSQL совместимый) | Unique Key (real-time UPSERT) + Aggregate Key + Duplicate Key |
| Нет нативного UPSERT — только ReplacingMergeTree + FINAL | Vectorized engine + CBO + Runtime Filter для JOIN |
| Distributed таблицы требуют ручной настройки | Автоматическое управление шардами и репликами |
Apache Doris изначально проектировался для сценариев, где данные обновляются в реальном времени. Три модели ключей (Unique, Aggregate, Duplicate) позволяют выбрать оптимальную стратегию для каждой таблицы.
3. Производительность: бенчмарки
Данные из публичных бенчмарков VeloDB Engineering и Apache Doris:
| Бенчмарк | ClickHouse | Apache Doris | Источник |
|---|---|---|---|
| TPC-H SF100 | Базовый уровень | 3x быстрее | VeloDB Engineering |
| TPC-DS (99 запросов) | ~50% запросов fail | 99/99 запросов | VeloDB Engineering |
| SSB + 25% updates | Базовый уровень | 5–34x быстрее | VeloDB Engineering |
| ClickBench (single-table) | Сопоставимо | Сопоставимо | ClickBench.com |
| CoffeeBench (real-world) | Базовый уровень | 8x быстрее, 8x дешевле | VeloDB Engineering |
| Write throughput (updates) | ReplacingMergeTree + FINAL | Delete Bitmap — стабильно быстрее | VeloDB Engineering |
4. SQL: стандарт vs диалект
ClickHouse использует собственный SQL-диалект, несовместимый с MySQL и PostgreSQL. Подключение BI-инструментов требует специальных адаптеров или драйверов. Ряд SQL-конструкций не поддерживается: correlated subqueries, часть window functions, сложные CTE.
Apache Doris работает по MySQL-протоколу. Любой BI-инструмент (Grafana, Superset, Tableau, Power BI) подключается через стандартный JDBC/ODBC без адаптеров. Поддерживается полный TPC-DS SQL.
// ПРИМЕР: MULTI-TABLE JOIN + WINDOW FUNCTION SELECT department, employee,
SUM(revenue) AS total,
RANK() OVER (PARTITION BY department ORDER BY SUM(revenue) DESC) AS rnk
FROM sales s
JOIN employees e ON s.emp_id = e.id
WHERE sale_date >= '2026-01-01' GROUP BY department, employee; Этот запрос с JOIN и RANK() OVER работает в Doris из коробки. В ClickHouse correlated subqueries и ряд window functions могут потребовать переписывания или не поддерживаться вовсе.
5. Real-time updates: Delete Bitmap vs ReplacingMergeTree
ClickHouse ReplacingMergeTree: данные дедуплицируются только при фоновом merge. До merge запросы возвращают дубликаты. Ключевое слово FINAL запускает merge при чтении — и убивает производительность. Partial column update невозможен.
Apache Doris Unique Key + Delete Bitmap: обновления видны мгновенно после записи. Partial column update поддерживается. Нет необходимости в FINAL — данные консистентны при каждом чтении.
В бенчмарке SSB с 25% обновлений Apache Doris показал результат в 5–34 раза быстрее ClickHouse — подробнее в статье «34x faster real-time updates».
CDC-интеграция: Flink CDC → Doris работает нативно. В ClickHouse аналогичный pipeline требует Kafka + materialized views + ReplacingMergeTree — значительно сложнее в настройке и поддержке.
6. Стоимость владения (TCO)
Основные факторы при сравнении TCO:
| Лицензии | |
|---|---|
| Лицензии | Оба проекта — Apache License 2.0. Нет лицензионных платежей. |
| Инфраструктура | ClickHouse: ручной шардинг, ClickHouse Keeper, ручной ребалансинг. Doris: автоматическое управление шардами и репликами — меньше ops-работы. |
| Инженеры | ClickHouse требует специфической экспертизы: политики merge, шардинг, FINAL, distributed tables. Doris MySQL-совместим — шире доступный пул специалистов. |
| Хранение | Сжатие сопоставимо (оба колоночные). Но Doris избегает дублирования данных, характерного для ReplacingMergeTree до merge. |
| Экосистема | ClickHouse имеет большое community, но фрагментированный тулинг. Doris подключается к любому MySQL-совместимому инструменту — универсальная BI-экосистема. |
7. Кейсы миграции с ClickHouse
Kwai / Bleem (триллионы строк рекламы)
Унификация ClickHouse + Elasticsearch в единый Apache Doris (платформа Bleem). Результат: почти 1 млрд запросов в день, упрощение архитектуры, снижение операционной сложности.
Enterprise-компании (публичные кейсы)
Множество enterprise-кейсов на doris.apache.org: финтех, ритейл, телеком. Типичный триггер миграции — потребность в JOIN + real-time updates в одной системе.
Подход к миграции
SQL в основном совместим. Основные изменения: маппинг движков таблиц (MergeTree → Duplicate Key, ReplacingMergeTree → Unique Key, AggregatingMergeTree → Aggregate Key) и адаптация шардирования.
8. Когда ClickHouse всё ещё лучше
ClickHouse остаётся отличным выбором в конкретных сценариях:
- Чистые single-table агрегации на append-only данных: логи, метрики, time-series без обновлений.
- Нет потребности в multi-table JOIN или real-time updates.
- Существующий кластер с materialized views, которые уже решают проблему дедупликации.
- Команда с глубокой экспертизой в ClickHouse и без планов консолидации систем.
Но: если нужны JOIN + updates + SQL-полнота → Doris выигрывает.