Стоит ли добавлять базу ClickHouse для ускорения отчетов
Что проверяют
Не тащите ли вы новую технологию первым решением и понимаете ли разницу между транзакционной и аналитической нагрузкой. Вопрос про инженерную зрелость: умеете ли считать не только выигрыш, но и стоимость эксплуатации второй базы.
Как отвечать
Начните с вопросов, а не с ответа: сколько строк участвует в отчёте, какие это запросы, где именно уходит время, сколько отчётов строится за час, какая задержка данных допустима. Без замера решать нечего.
Дальше двигайтесь по возрастанию цены: план запроса и переписанный SQL, подходящие индексы, предрассчитанные агрегаты или материализованные представления, отдельная реплика под чтение, партиционирование по датам. Очень часто на этом всё и заканчивается.
ClickHouse оправдан, когда узкое место именно в сканировании десятков и сотен миллионов строк с агрегацией по нескольким колонкам: колоночное хранение, сжатие и векторизованное выполнение дают там другой порядок времени. Честно назовите цену: вторая база, поток репликации и его отставание, ещё одна точка отказа, свой диалект, слабые соединения больших таблиц, отсутствие привычных транзакций, асинхронные мутации вместо простого UPDATE, отдельный драйвер и тесты в приложении.
Где спотыкаются
Отвечают согласием без диагностики. Отчёт нередко тормозит из-за одного отсутствующего индекса, запроса в цикле или выборки всех колонок, и переезд на другую базу этого не чинит.
Ждут от аналитической базы поведения обычной. Точечные обновления, удаление по условию и гарантия уникальности ключа устроены там иначе, схема пишется под конкретные запросы, а движок с дедупликацией схлопывает дубликаты не в момент вставки.
Забывают про доставку данных. Без надёжного и наблюдаемого потока цифры в быстрых отчётах начинают расходиться с основной базой, и доверие к ним теряется быстрее, чем росла скорость.