Comments 6
OOM на 10kk строк..? Не пробовали просто вынести аналитические запросы на stage-базу и настроить репликацию, чтобы не шатать прод? Вообще, olap – это не про то чтобы получать большой объём многомерных данных пусть даже за какой-то период, а про то чтобы быстро получать чаще всего агрегированные данные (преимущественно — предрасчитанные) по различным срезам.
Я не против ClickHouse, но по ощущениям статья написана только ради упоминания продуктов Яндекса.
Интересный кейс решения реальной задачи, особенно интересно посмотреть на схему движения данных от начала до Datalens. Критикующие просто могли не знать, каково это подключать базу данных напрямую к инструменту бизнес-аналитики. На моем опыте, могу с уверенностью сказать, что при кк базах, потребность в памяти со 100% вероятностью превысит все возможности серверов MySQL и Postgres. Поэтому, применение clickhouse , наверное, единственный метод преодоления этих ограничений.
Критикующие просто могли не знать, каково это подключать базу данных напрямую к инструменту бизнес-аналитики.
Тогда может дело в инструменте бизнес-аналитики? У нас одна из БД на 150кк в основной таблице, не считая джойнов (MySQL кстати). Сбоку BI решение, которое по расписанию каждые 5 минут забирает через ETL (тоже кстати визуальный конструктор) обновления в данных и складывает в свой DWH на Postgresql. По мониторингу всплесков по нагрузке на основную базу нет, даже stage не потребовался
Да, Clickhouse интересная штука, но стоило ли городить огород с Datalens...только чтобы потом гордиться сложностью схемы движения данных?
Спор о границах BI решения: только визуализация или весь ETL был, есть и будет.
В статье не отразили важную подробность - клиент всю инфру держит на яндекс облаке и менеджмент сервисах. Так что ClickHouse и DataLense оптимально вписались в стек. 0 затрат да Devops и поддержку инфры в проекте, это приятный бонус.
10кк это уже в денормализованной таблице. В изначальной базе существенно больше.
На первоначальном объеме промежуточный stage на Postresql действительно бы сработал, но при повышении нагрузки + большое количество пользователей, которые обращаются с тяжелыми запросами могут Postresql и положить.
Вроде и обычного постргрес или любой другой базы, не продовой хватило бы на 10 млн строк. Ну ещё индексы добавить.
Кликхаус тут только усложняет поиск специалистов на поддержку.
А еще у clickhouse есть словари для часто используемых данных, чтобы быстро joinить. Но нужно больше оперативной памяти.
Из боли клиентов — в новый продукт: как мы пересобрали аналитику на Clickhouse