Когда олимпиадники могут. ClickHouse

На одном из самых старых проектов которые я разрабатываю начала тупить отчетность. Как только я поставил клиенту BI (напоминаю, это было самое быстрое и самое эффективное решение задачи которое я когда-либо делал), то аналитики сразу начали городить кучу дашбордов и отчетов. В основном все работало бодро, но некоторые запросы изрядно тупили.

Проблему довольно долго удавалось игнорировать, но в какой-то момент данных стало уж слишком много чтобы ими мог ворочать маленький MySQL сервер (4Гб памяти). Основную трудность составляли группировки по low cardinality колонкам. Представьте что у вас есть таблица с событиями где есть куча полей одно из которых может иметь всего три значения. Если вы хотите группировать выборку по этому полю, но кроме того еще и по куче других полей, то база не может подобрать подходящий индекс, берет какой попало и если данных достаточно много, то все это превращается в full scan.

В моем случае на таблице из всего лишь 6M записей такие запросы становились просто неподъемными. Внимательный читатель с навыками DBA предложил бы сделать композитные индексы, но мне пришлось бы делать их 20 штук, потому что кроме low-cardinality поля есть еще и другие по которым тоже нужно делать фильтрацию. Сложность вращения OLAP кубов это известная проблема RDBMS и не решается она в общем случае никак. Даже банальный select count(*) from table со временем начнет тупить на смехотворных 10M записей. Вам надо или делать дополнительные таблицы, или грузить всю таблицу в память, то есть добавлять железа, или ограничивать выборку по первичному ключу или еще как-то изощряться. Железо я в силу разных причин добавить сейчас не могу, костыли в виде дополнительных таблиц уже есть, городить что-то еще не хотелось.

В этот момент кто-то вспомнил про ClickHouse. То ли я, то ли аналитики клиента, уже не помню. Договорились сделать PoC. Подняли самый простой сервер, я сделал экспорт данных из mysql в csv и вгрузил в ClickHouse чтобы понять как оно вообще будет работать.

Первым моим удивлением была скорость вгруза. 3M записей заехали буквально за несколько секунд. Я вначале даже подумал что не нажал где-то кнопку, и пошел перепроверять. Однако все данные были на месте.

Вторым удивлением оказалась скорость выборок. Запросы которые mysql не мог переварить, отрабатывали за доли секунд. Оно конечно логично, ведь это колоночная база сделанная как раз для группировок по куче колонок, но такой скорости на сервере с 2 Гб памяти я не ожидал.

Третье—полная поддержка SQL синтаксиса. Нам практически не понадобилось переписывать запросы дашбордов, просто поменяли датасорс в Metabase и всё заработало. Очень круто когда решение интегрировано со всем с чем можно.

Главная идея ClickHouse—высокая скорость работы на гигантских объемах данных. Логично, если в Яндексе приходится ворочать петабайтами, то мои смешные десятки гигабайт будут работать очень быстро.

Недавно я писал пост про олимпиадные задачи, алгоритмы и зачем они нужны. Вот результат, пожалуйста. Сам ClickHouse достигает такой скорости за счет хитрых структур данных и многочисленных оптимизаций.

Конечно же не все прошло так гладко как я стелю. Об этом в следующей части.

Используете ClickHouse? Делитесь своим опытом в комментах! 👇


Понравился материал? Подписывайся на мой телеграм канал: https://t.me/full_of_hatred