Аннотация
Цель статьи — провести всестороннюю техническую оценку и сравнение производительности двух популярных открытых аналитических СУБД (OLAP) — StarRocks и ClickHouse. Оценка строится вокруг типового сценария аналитики в реальном времени, предъявляющего жесткие требования к актуальности обновлений, низкой задержке сложных запросов и стабильности при высокой конкурентной нагрузке. Мы подробно опишем методику тестирования, сравним различия двух продуктов по ключевым возможностям (особенно по обновлениям в реальном времени), производительности запросов, архитектурной сложности и интеграции в экосистему, и в итоге, опираясь на результаты и тренды эволюции архитектуры, сформулируем выводы и рекомендации по выбору.
1. Бизнес‑контекст и ключевые требования
Рассматриваемый сценарий — ключевая корпоративная аналитическая платформа, призванная обеспечивать оперативную поддержку принятия решений для операционных и управленческих команд. Источником данных являются транзакционные системы (OLTP), где изменения происходят часто. Технические требования сводятся к четырем пунктам:
Субсекундная задержка запросов (Sub-second Latency): платформа должна поддерживать сложные аналитические запросы, включая многомерные агрегации, фильтрации и сортировки по миллиардам строк; для подавляющего большинства запросов (p99) время отклика должно укладываться в 1 секунду.
Синхронизация данных в реальном времени (Real-time Data Synchronization): в OLTP‑базе (PostgreSQL) часто выполняются INSERT, UPDATE и DELETE; аналитическая платформа должна практически в реальном времени синхронизировать эти изменения, обеспечивая свежесть данных на уровне секунд, что требует эффективной поддержки UPSERT.
Полнофункциональная поддержка JOIN (Full-featured JOINs): требуются связи между несколькими факт‑ и дим‑таблицами; СУБД должна эффективно обрабатывать JOIN больших таблиц без чрезмерных ограничений (например, без требования помещать правую таблицу целиком в память).
Простота архитектуры и стоимость эксплуатации (Operational Simplicity & TCO): решение должно быть максимально интегрированным, без избыточных внешних компонентов (например, Flink, Kafka), призванных компенсировать ограничения самой СУБД, чтобы снизить TCO и операционную сложность.
2. Технический выбор и схема тестирования
На основе анализа рынка и активности сообществ мы остановились на двух сильных кандидатах: ClickHouse и StarRocks.
ClickHouse: зрелая колоночная СУБД, известная экстремальной скоростью запросов и выдающимися результатами в append‑only сценариях (журналы, событийная аналитика).
StarRocks: СУБД нового поколения на архитектуре MPP (масштабно‑параллельная обработка), ориентированная на реальное время, универсальность аналитики и простоту архитектуры.
Чтобы обеспечить справедливое и объективное сравнение, мы применили следующую методику:
Тестовая среда: в AWS развернуты два кластера с полностью идентичной конфигурацией.
Набор данных: около 1 ТБ деперсонализированных бизнес‑данных в формате Parquet, более 3 млрд строк.
Нагрузка запросов: при помощи инструмента k6 смоделирован большой объем параллельных пользователей; выполнялись типовые аналитические запросы по коротким (3–6 месяцев) и длинным (1–3 года) периодам.
Обновление данных: смоделирован поток изменений из PostgreSQL посредством CDC (Change Data Capture), непрерывно выполняющий высокочастотные UPSERT‑операции в базу данных.
Экспертная оптимизация: мы привлекли официальные команды StarRocks и ClickHouse для настройки производительности, чтобы обе системы работали в своих оптимальных конфигурациях.
Упрощение архитектуры: чтобы сфокусироваться на основных возможностях, мы применили лучшие практики моделирования и построили широкую (денормализованную) таблицу, заранее обработав сложные отношения JOIN; таким образом, тест концентрировался на двух ключевых метриках — обновлениях данных и скорости запросов.
3. Глубокий сравнительный анализ
3.1 Ключевое отличие: обновления в реальном времени (UPSERT)
Актуальность обновлений — критическое узкое место; различия систем в механизмах и результатах здесь существенны.
Подход ClickHouse:
ClickHouse в основном использует движки ReplacingMergeTree или CollapsingMergeTree для имитации операций обновления, что по сути представляет асинхронную модель с конечной согласованностью (eventual consistency).
Механика: при записи новой версии строки старая версия не удаляется сразу, а помечается к удалению; фоновые задачи слияния (merge) периодически выполняются, выполняя дедупликацию и сохраняя последнюю версию.
Практические сложности:
Задержки и дубли: до завершения фонового слияния запрос может видеть и старую, и новую версии строк, что дает неверные результаты; для устранения требуется модификатор FINAL, который принуждает к слиянию на лету и резко замедляет запрос — это несовместимо с низкой задержкой.
Сложность архитектуры: для точной актуализации в реальном времени часто привлекают Flink или другой потоковый движок для предагрегаций/“retraction stream” до загрузки в ClickHouse, что заметно усложняет конвейер данных и повышает стоимость сопровождения.
Подход StarRocks:
StarRocks предоставляет модель первичного ключа (Primary Key Model) с нативной UPSERT‑семантикой, близкой к традиционным РСУБД.
Механика: при записи строки с тем же первичным ключом StarRocks атомарно помечает старую строку удаленной и записывает новую; последующие запросы сразу читают актуальную версию без дополнительной обработки. Внутренний механизм Compaction асинхронно очищает помеченные к удалению данные, не влияя на выполнение пользовательских запросов.
Практические преимущества:
Актуальность и согласованность: обновления вступают в силу мгновенно, результаты запросов корректны и согласованы.
Простота архитектуры: внешние компоненты не требуются — можно напрямую потреблять поток CDC; конвейер PostgreSQL -> CDC -> StarRocks получается коротким и эффективным.
Вывод: по ключевому требованию обновлений в реальном времени нативная поддержка UPSERT в StarRocks на базе модели первичного ключа обеспечивает явное преимущество над асинхронным имитационным подходом ClickHouse — по согласованности данных, производительности запросов и простоте архитектуры.
3.2 Производительность запросов и стабильность при высокой нагрузке
В тестах производительности мы наблюдали характерный эпизод и получили количественные сравнения.
“Аномальная” производительность StarRocks:
В начальном тесте на параллельность у StarRocks наблюдались циклические колебания QPS (Queries Per Second): QPS взлетал до очень высоких значений, затем падал до нуля и через несколько секунд восстанавливался.
Анализ показал, что корневая причина — очень низкая задержка (Latency) одиночного запроса: каждый виртуальный пользователь k6 генерировал за единицу времени значительно больше запросов, чем ожидалось, мгновенно загоняя загрузку CPU кластера до 100%; система на короткое время включала защитные механизмы (например, троттлинг).
После уменьшения числа виртуальных пользователей до уровня реальной пропускной способности кластер стабилизировался и показал очень высокую суммарную пропускную способность. Этот эпизод косвенно подтверждает высокую эффективность обработки одиночных запросов.
Количественные результаты:
Длинные запросы (1–3 года данных): средняя скорость StarRocks примерно на 40% выше, чем у ClickHouse.
Короткие запросы (3–6 месяцев данных): преимущество StarRocks еще заметнее — по среднему времени отклика, p99 и максимальному времени он полностью опережает ClickHouse.
Конкурентная пропускная способность (QPS): после корректировки нагрузки StarRocks при тех же ресурсах выдерживает больше параллельных запросов, особенно в коротких запросах.
Стабильность: за несколько суток непрерывного стресс‑теста кластер StarRocks не зафиксировал ни одного сбоя запроса или ошибки сервиса, тогда как в пике у ClickHouse периодически появлялись ошибки HTTP 5xx.
Анализ: преимущество StarRocks обеспечивается более современным движком запросов, включая:
Архитектуру MPP: разбиение сложного запроса на подзадачи с параллельным исполнением на всех вычислительных узлах для максимального использования ресурсов.
Оптимизатор на основе стоимости (CBO, cost‑based optimizer): построение более качественных планов для сложных запросов, особенно с множественными JOIN.
Векторизованный движок выполнения: повышение эффективности использования CPU на низком уровне вычислений.
3.3 Эволюция архитектуры и экосистемный тренд: Lakehouse
Помимо текущих функционала и производительности мы оценили, насколько продукты поддерживают будущую эволюцию архитектуры данных, особенно популярную концепцию Lakehouse.
Суть Lakehouse: разрушить барьер между хранилищем данных (Data Warehouse) и озером данных (Data Lake), позволяя высокопроизводительному движку запросов напрямую анализировать данные в открытых форматах (Iceberg, Hudi, Delta Lake), хранящиеся в озере (например, S3, HDFS), избегая дублирования и зависимости от поставщика (vendor lock‑in).
Позиционирование ClickHouse:
ClickHouse — очень мощное хранилище данных, но по дизайну это скорее обособленная система для анализа после загрузки данных (изолированное хранилище, data silo). Хотя он и умеет подключаться к внешним источникам, это не его ключевая сильная сторона.
Стратегические преимущества StarRocks:
Сильные возможности внешних таблиц: StarRocks умеет эффективно выполнять запросы к данным в Hive, Hudi, Iceberg, реализуя разделение хранения и вычислений.
Запись обратно в озеро: StarRocks поддерживает прямую запись в таблицы Iceberg. Это позволяет использовать StarRocks как высокопроизводительный движок запросов и вычислений поверх озера данных, а результаты ETL напрямую записывать в открытый формат Iceberg для потребления другими движками (Spark, Flink). Такой подход устраняет изоляцию данных (data silo) и придает архитектуре высокую гибкость.
4. Выводы и рекомендации по выбору
ClickHouse — зрелый, стабильный и высокопроизводительный OLAP‑движок, остающийся эталоном и конкурентоспособным выбором для append‑only сценариев с преобладанием операций записи и без частых обновлений (анализ логов, мониторинг метрик).
StarRocks в рамках данного сценария аналитики в реальном времени продемонстрировал более сильные комплексные качества и технологическую перспективность:
Нативные обновления в реальном времени: модель первичного ключа эффективно решает боль высокочастотного UPSERT и заметно упрощает архитектуру данных.
Лидирующая производительность запросов: при высокой параллельности и сложных запросах производительность и стабильность выше.
Простая архитектура: концепция “All‑in‑One” снижает общую сложность системы и операционные затраты.
Экосистема, ориентированная на будущее: глубокая поддержка Lakehouse, особенно Apache Iceberg, позволяет не только решать текущие задачи, но и соответствовать эволюции архитектуры данных.
Следовательно, для компаний, которым одновременно нужны субсекундные отклики, обработка частых обновлений и стремление к простой, открытой и эволюционирующей современной платформе данных, StarRocks — более привлекательный и технологически сильный выбор.
Автор: Йоав Нордманн (технический тимлид бэкенда и архитектор распределенных систем и данных; энтузиаст новых технологий, обмена знаниями и open source).
Дисклеймер: публикация является переводом.