Глубокое сравнение StarRocks и ClickHouse в задачах аналитики в реальном времени и соображения по выбору

[@thethee]

Перевод не читал, сразу в оригинал пошел. Результаты были бы интересные, если бы не несколько пунктов:

1) Нет указания структуры данных - кликхауз надо уметь приготовить. Партиции, сортировки, индексы - все это влияет как на индивидуальную задержку, так и на пропускную способность.

2) Нет указания запросов, возможно тестировались только нужные конкретному заказчику в специфичном случае, а не широкий диапазон различных.

3) Данных М А Л О. Терик данных за несколько лет это даже не смешно. Хотя бы несколько сценариев надо:

а) пол терабайта в день и колонок этак 100 из которых 30 заполнены в разное время - реалистичный сценарий получения и нормализации каких нибудь логов из различных источников / различного назначения.

б) 5-10 колонок но все всегда заполнены

Обязательно нужно использовать все доступные типы данных в СУБД для адекватной проверки и показать таблицу сравнения, хотя бы что есть, а чего нет.

Автор оригинала просто мускулами поиграл, а не предоставил сравнительный отчет, мол вот цифры какие классные. При этом детали не раскрывает, а жаль

[@PhoenixLi]

Спасибо за подробный и по существу критичный комментарий.

Это перевод/перенос материала с Medium, написанного data‑архитектором израильской компании, которая как раз решала задачу near real‑time аналитики (OLTP → CDC → OLAP, p99 < 1s, высокая конкуррентность, минимальная архитектурная «обвязка»).

Вы абсолютно правы, что с точки зрения строгого бенчмарка тут не хватает многих вещей:

1. Структура данных и настройки ClickHouse.
   Для честного сравнения действительно важно явно показать PARTITION BY, ORDER BY, индексы, projection’ы и т.д. В оригинальной статье автор лишь пишет, что обе команды (StarRocks и ClickHouse) помогали тюнинговать свои кластера, но подробных DDL он не приводит — вероятно, из‑за сочетания NDA и формата статьи (ориентированной скорее на архитектурные выводы, чем на полный технический отчёт).

2. Набор запросов.
   Тут тоже согласен: без конкретных SQL и объяснения паттернов (сколько join’ов, какие агрегации, какая селективность и т.п.) сложно судить, насколько результаты обобщаемы. В данном случае автор явно оптимизировал и тестировал именно те запросы, которые критичны для их платформы — а не широкую «универсальную» нагрузку.

3. Объёмы и сценарии данных.
   Для некоторых продакшн‑кейсов ClickHouse ваши примеры (0.5 ТБ/день логов, очень широкие и частично заполненные таблицы и т.д.) действительно гораздо более репрезентативны. Здесь же упор был не на экстремальные объёмы, а на сочетание:

   • частых UPSERT’ов из OLTP;

   • требований к согласованности данных;

   • sub‑second latency на многомерных аналитических запросах.

4. Матрица по типам данных и фичам.
   Это уже отдельный, большой пласт работы. Оригинальный автор сфокусировался на сравнении UPSERT‑семантики, производительности запросов и интеграции с Lakehouse/ICEBERG, но не делал «каталог возможностей» обеих СУБД. Согласен, что такому обзору было бы полезно существовать отдельно от конкретного кейса.

:)

[@thethee]

Поражаюсь насколько народ ленив чтобы не то чтобы ответить самому, даже не прочитать, сразу скидывая в ближайшую LLM с просьбой пообщаться в комментариях.

Я сразу написал что перевод не читал и пошел в источник. Так что мой комментарий сразу относился не к переводу и его качеству, а к качеству первоисточника, нет смысла ещё раз сообщать что это всего лишь перевод и повторно перечислять то что я уже написал, но другими словами.

Принесите в диалог что-то новое, если хотите пообщаться. А нечего сказать, так лучше ничего не ответить. Комментарии к статье вполне могут существовать без ответа мейнтейнера.

:)

[@BackDoorMan]

Браво! Кажется мы имеем дело с целенаправленным маркетингом, приправленным сверху LLM.

На Хабре по запросу ClickHouse 1000 публикаций и огромное комьюнити, StarRocks всего 34 публикации, подавляющее большинство от одного автора.

Некий StarRocks, без внятного описания методики тестирования, уверенно теснит ClickHouse. При этом на db-engines он выше 150 места никогда в рейтинге не поднимался, это за пять то лет существования. Я, конечно, не исключаю, что в отдельных случаях он будет быстрее и полезнее клика. Хочется знать в каких случаях, а не читать туманное "показал себя лучше"

[@oneti]

Полностью поддерживаю BackDoorMan -  Кажется мы имеем дело с целенаправленным маркетингом