Хватит тащить ClickHouse в каждый проект где 30 млн строк

[kube6]

Накипело. Третий проект подряд на консалтинге, и везде одно и то же: данных 20-50 млн строк, аналитика для внутренней админки, и стоит кластер ClickHouse на 4 ноды. Зачем?? Постгрес с парой нормальных индексов и материализованной вьюхой прожует это не заметив.

Зато теперь у команды: мутации, которые висят часами, джойны, которые надо переписывать под особенности CH, отдельный Keeper, и ни один человек в команде не понимает, как это все работает. На вопрос зачем брали ответ один, ну это же для аналитики.

ClickHouse гениальная штука НА СВОИХ ОБЪЕМАХ. Миллиарды строк, потоковая вставка, тяжелые агрегаты. На 30 млн строк это стрельба из гаубицы по воробьям, только гаубицу еще и обслуживать надо.

[delphin]

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

[async2025]

видел стартап, 3 разработчика, кликхаус кластер на 6 нод, данных суммарно 180 гигов. на вопрос зачем ответили, что так было в статье на хабре

[rdnckavn]

очередной пост хватит использовать X. в прошлом месяце было хватит тащить кафку, до этого хватит микросервисов. что дальше по списку?

[leochir]

объем строк вообще не главный критерий, главное профиль запросов. group by по 30 колонкам с произвольными фильтрами уже на 10 млн строк в постгресе больно, индексы под все комбинации не построишь. а CH такое ест холодным. так что бывает, что и 10 млн это повод

[vemina]

+1, у нас выкинули CH, аналитику перевели на постгрес с pg_duckdb, полет нормальный

[Sdgator]

а для логов что посоветуете, кликхаус или эластик? у нас гигов 50 в день

[ivan21]

выше про профиль запросов справедливо, чистый объем не единственный критерий, признаю. но в моих трех кейсах запросы были уровня sum по двум колонкам с фильтром по дате. про логи: 50 гигов в день это как раз случай, когда CH уместен, еще Loki посмотрите