О быстрых оптимизациях в Clickhouse

Пришел заказчик жаловаться на медленный отчет в суперсете. Говорит, больше 2 минут обновляется любой чих.

Apache Superset, кто не знает, тот пример максимально ленивого BI, который на каждый фильтр, на каждое обновление страницы на каждый график отправляет live-запросы в БД. Но данные висят на Clickhouse, так что 2 минут быть точно не должно.

Начинаю разбираться. Витрина - заказы за все время жизни компании, 550 млн строк, солидно. Но

1) Витрина оформлена через джойны на два справочника. А-ля схема звезда.

2) Пол-ярда записей лежат одной таблицей (!) без партиций, с сортировкой по id заказа (!!)

То есть на каждый апдейт или взятый фильтр, базу отправляется 10-15 запросов, в которых база вынуждена вычитывать 550 млн записей и налету джойнить их 2 раза. 5,5 млрд чтений + 5,5 млрд джойнов на один апдейт страницы одним пользователем! У СУБД нет способа выделить только нужные данные даже если запрос за последние 10 дней.

Делаем честную плоскую витрину, режем на партиции, сортировка по дню. Время от фильтра до отчета падает до меньше 2-5 секунд. Это большая разница. Это разница между возможностью и невозможностью работать с предоставленной информацией в режиме лайв. Например на звонке или встрече.

Мораль. Да какая уж тут мораль - если ввязался в российский бомже-стек аналитики, то придется знать, как работает Superset и какие лучшие практики построения витрин в кликхаусе. Еще и DBT какой рядом иметь, чтобы процесс добавления колонок в плоскую витрину (заказчик попросил еще 2-22 разреза данных) занимал минуты, а не дни.

Еще много там такого выковыривать, на полгода хватит.