Thank you for your interest! You can check out my previous articles for product comparisons and case studies. However, due to language barriers, some translations may not be perfect - which is exactly why we're launching this recruitment program.
Regarding your questions about pros/cons and comparisons with CH (ClickHouse) and GP (Greenplum), we're actively working on preparing more detailed content on these topics.
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
Спасибо за комментарий! В этой статье мы обсуждаем архитектурные различия, а результаты количественных бенчмарков появятся в следующей публикации. Следите за обновлениями — будет интересно!
Thank you for your interest! You can check out my previous articles for product comparisons and case studies. However, due to language barriers, some translations may not be perfect - which is exactly why we're launching this recruitment program.
Regarding your questions about pros/cons and comparisons with CH (ClickHouse) and GP (Greenplum), we're actively working on preparing more detailed content on these topics.
Your suggestions are much appreciated!
Ah, I see! I'm totally with you on that one, hahaha
Sorry, I don't quite understand your comment, could you explain it in more detail?
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
Спасибо за комментарий! В этой статье мы обсуждаем архитектурные различия, а результаты количественных бенчмарков появятся в следующей публикации. Следите за обновлениями — будет интересно!