> ## Content Index
> Fetch the complete content index at: https://www.rozhkov.me/llms.txt
> Use this file to discover other available public pages before exploring further.

# Когда олимпиадники могут. ClickHouse
- URL: https://www.rozhkov.me/clickhouse-is-fast/
- Published: 2021-06-14T06:00:00.000Z
- Updated: 2021-06-14T12:30:46.000Z
- Author: Vova Rozhkov
- Tags: інструменти

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

Проблему довольно долго удавалось игнорировать, но в какой-то момент данных стало уж слишком много чтобы ими мог ворочать маленький 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—высокая скорость работы на гигантских объемах данных. Логично, если в Яндексе приходится ворочать петабайтами, то мои смешные десятки гигабайт будут работать очень быстро.

Недавно я писал пост [про олимпиадные задачи, алгоритмы и зачем они нужны](https://www.rozhkov.me/when-need-to-know-leetcode/). Вот результат, пожалуйста. Сам ClickHouse достигает такой скорости за счет хитрых структур данных и многочисленных оптимизаций.

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

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