Your suggestion is very helpful! Thank you for providing the English original. The version I translated is an article published in the Chinese community, and its authors are two developers from NAVER in Korea.
Спасибо за подробный и по существу критичный комментарий.
Это перевод/перенос материала с Medium, написанного data‑архитектором израильской компании, которая как раз решала задачу near real‑time аналитики (OLTP → CDC → OLAP, p99 < 1s, высокая конкуррентность, минимальная архитектурная «обвязка»).
Вы абсолютно правы, что с точки зрения строгого бенчмарка тут не хватает многих вещей:
Структура данных и настройки ClickHouse. Для честного сравнения действительно важно явно показать PARTITION BY, ORDER BY, индексы, projection’ы и т.д. В оригинальной статье автор лишь пишет, что обе команды (StarRocks и ClickHouse) помогали тюнинговать свои кластера, но подробных DDL он не приводит — вероятно, из‑за сочетания NDA и формата статьи (ориентированной скорее на архитектурные выводы, чем на полный технический отчёт).
Набор запросов. Тут тоже согласен: без конкретных SQL и объяснения паттернов (сколько join’ов, какие агрегации, какая селективность и т.п.) сложно судить, насколько результаты обобщаемы. В данном случае автор явно оптимизировал и тестировал именно те запросы, которые критичны для их платформы — а не широкую «универсальную» нагрузку.
Объёмы и сценарии данных. Для некоторых продакшн‑кейсов ClickHouse ваши примеры (0.5 ТБ/день логов, очень широкие и частично заполненные таблицы и т.д.) действительно гораздо более репрезентативны. Здесь же упор был не на экстремальные объёмы, а на сочетание:
частых UPSERT’ов из OLTP;
требований к согласованности данных;
sub‑second latency на многомерных аналитических запросах.
Матрица по типам данных и фичам. Это уже отдельный, большой пласт работы. Оригинальный автор сфокусировался на сравнении UPSERT‑семантики, производительности запросов и интеграции с Lakehouse/ICEBERG, но не делал «каталог возможностей» обеих СУБД. Согласен, что такому обзору было бы полезно существовать отдельно от конкретного кейса.
Thank you! This is a constantly updated project, in addition to Iceberg, it also supports multiple data lake formats in the graph, please check out the details and join the discussion group.https://t.me/+xmOVhseXPdI4Y2E9
I may not understand your question very well due to language reasons. However, it can be explained: there is a description version in the article, you can check, it is v3.3 :) If you need further discussion, you can contact me by email or telegram for detailed communication
Спасибо за комментарий! В этой статье мы обсуждаем архитектурные различия, а результаты количественных бенчмарков появятся в следующей публикации. Следите за обновлениями — будет интересно!
Your suggestion is very helpful! Thank you for providing the English original. The version I translated is an article published in the Chinese community, and its authors are two developers from NAVER in Korea.
Very helpful, I will learn more about it!
[1] Поддержка нескольких выражений: https://github.com/StarRocks/starrocks/pull/60035
Спасибо за подробный и по существу критичный комментарий.
Это перевод/перенос материала с Medium, написанного data‑архитектором израильской компании, которая как раз решала задачу near real‑time аналитики (OLTP → CDC → OLAP, p99 < 1s, высокая конкуррентность, минимальная архитектурная «обвязка»).
Вы абсолютно правы, что с точки зрения строгого бенчмарка тут не хватает многих вещей:
Структура данных и настройки ClickHouse.
Для честного сравнения действительно важно явно показать
PARTITION BY,ORDER BY, индексы, projection’ы и т.д. В оригинальной статье автор лишь пишет, что обе команды (StarRocks и ClickHouse) помогали тюнинговать свои кластера, но подробных DDL он не приводит — вероятно, из‑за сочетания NDA и формата статьи (ориентированной скорее на архитектурные выводы, чем на полный технический отчёт).Набор запросов.
Тут тоже согласен: без конкретных SQL и объяснения паттернов (сколько join’ов, какие агрегации, какая селективность и т.п.) сложно судить, насколько результаты обобщаемы. В данном случае автор явно оптимизировал и тестировал именно те запросы, которые критичны для их платформы — а не широкую «универсальную» нагрузку.
Объёмы и сценарии данных.
Для некоторых продакшн‑кейсов ClickHouse ваши примеры (0.5 ТБ/день логов, очень широкие и частично заполненные таблицы и т.д.) действительно гораздо более репрезентативны. Здесь же упор был не на экстремальные объёмы, а на сочетание:
частых UPSERT’ов из OLTP;
требований к согласованности данных;
sub‑second latency на многомерных аналитических запросах.
Матрица по типам данных и фичам.
Это уже отдельный, большой пласт работы. Оригинальный автор сфокусировался на сравнении UPSERT‑семантики, производительности запросов и интеграции с Lakehouse/ICEBERG, но не делал «каталог возможностей» обеих СУБД. Согласен, что такому обзору было бы полезно существовать отдельно от конкретного кейса.
:)
Thank you! This is a constantly updated project, in addition to Iceberg, it also supports multiple data lake formats in the graph, please check out the details and join the discussion group.https://t.me/+xmOVhseXPdI4Y2E9
I may not understand your question very well due to language reasons. However, it can be explained: there is a description version in the article, you can check, it is v3.3 :)
If you need further discussion, you can contact me by email or telegram for detailed communication
Спасибо за комментарий! В этой статье мы обсуждаем архитектурные различия, а результаты количественных бенчмарков появятся в следующей публикации. Следите за обновлениями — будет интересно!