Comments 10
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ить. Но нужно больше оперативной памяти.
Приятная статья, забрал себе на вооружение. Когда можно запустить аналитику с минимальными вложениями по разработке, это очень круто.
Очень близкая боль метание между OLTP и OLAP, и по моему опыту если данных достаточно за вчера и мы не говорим о сложной Oracle (RMS) based системе, то пользователям, не аналитикам, а именно C-Level, достаточно решений типа Metabase на базе OLTP. Зависит от того, какими агрегатами мы оперируем, на сколько сложные срезы и зависимости нужно анализировать.
С OLAP можно настраивать непрерывный процесс сбора данных пакетами, если для каких то целей требуются актуальные данные. Но обычно таких запросов у аналитиков не много.
Могут быть аналитические запросы у клиентов, которые можно запускать только на read реплике, но случаев, когда мы их уводили в OLAP я не припомню.
Интересный кейс! Особенно про то, как OLTP-база перестала справляться с аналитикой — знакомая боль. ClickHouse, конечно, мощно выручил, но интересно, почему именно его выбрали? Не пробовали просто колоночные индексы в Postgres сделать или что-то вроде TimescaleDB?
И да, респект за подход с батчами и промежуточными таблицами — сразу видно, что ребята не стали лепить костыли на горячую, а нормально продумали миграцию.
Вопрос: клиенты сразу почувствовали разницу, или пришлось ещё дорабатывать интерфейсы для удобства? В любом случае, история годная — особенно для стартапов, которые пока держат аналитику на основном PostgreSQL и не верят, что однажды он захлебнётся :)
Большое спасибо за оценку :)
Честно, ну не верю я в Postgres в качестве высоконагруженной аналитической базы. Возможно это от неумения его готовить, но все же.
Выбор на ClickHouse пал из-за наличия его в management service формате в яндекс облаке, где клиент хостил свой прод. Отсутствие костов на devops были важной частью проекта.
Конечными пользователями были были не сотрудники Teachbase, а их клиенты, которые обучали в LMS своих сотрудников.
Так, что для них это был переход с экселя на дашборды в даталенсе и они были просто счастливы! Дашборды еще встроили в их личные кабинеты и счастье было вообще полным.
Из боли клиентов — в новый продукт: как мы пересобрали аналитику на Clickhouse