Аннотация

Цель статьи — провести всестороннюю техническую оценку и сравнение производительности двух популярных открытых аналитических СУБД (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).

Дисклеймер: публикация является переводом.