Часто можно встретить утверждение, что ClickHouse — это «очень быстрая база данных», способная обрабатывать огромные объёмы информации. Это правда, но с важной оговоркой: ClickHouse подходит не для всех сценариев. Его высокая производительность не всегда является достаточным аргументом, чтобы полностью отказаться от привычных реляционных СУБД.

Если рассмотреть MySQL, то при работе с большими объёмами данных довольно быстро проявляются ограничения. По мере роста таблиц запросы начинают выполняться всё медленнее, а попытки оптимизации — создание индексов, партиционирование, разбиение данных на отдельные таблицы — лишь частично решают проблему. В результате приходится тратить значительное время разработчиков на сложные и не всегда надёжные обходные решения, которые не устраняют корень проблемы.

Практический пример

В компании Хостинг Украина мы столкнулись с задачей поиска аномалий в трафике. Для этого необходимо собирать и анализировать все HTTP-запросы, поступающие на сайты клиентов. В сутки обрабатывается около 1,3 миллиарда запросов, которые поступают с множества серверов.

Чтобы MySQL справлялся с такой нагрузкой, пришлось применять целый набор оптимизаций:

• ограничить срок хранения данных тремя сутками;
• разбить данные на отдельные таблицы, чтобы удалять их целиком, а не выполнять медленный DELETE WHERE date < CURRENT_DATE - INTERVAL 3 DAY;
• сегментировать таблицы для ускорения поиска по IP-адресам;
• агрегировать IPv6-адреса до сети /64, поскольку боты часто меняют IPv6 и отправляют каждый запрос с нового адреса;
• минимизировать количество полей в индексах, так как индексы занимают место и замедляют вставку данных;
• реализовать очередь на вставку данных, так как запросы приходили более чем со ста серверов каждые пять минут.

Даже при всех этих мерах запросы на формирование статистики выполнялись медленно и требовали заметного времени ожидания.

Переход на ClickHouse

После переноса данных в ClickHouse ситуация изменилась кардинально:

• скорость выборок по различным колонкам значительно выросла даже без использования индексов;
• для таблиц было настроено время жизни данных (TTL), и ClickHouse автоматически удаляет устаревшие записи;
• объём занимаемого дискового пространства сократился за счёт эффективного сжатия данных;
• отпала необходимость агрегировать IPv6-адреса в /64, так как ClickHouse поддерживает аналитику по сетям «из коробки»;
• данные теперь вставляются напрямую с каждого сервера, без промежуточных очередей — ClickHouse принимает их быстро и выполняет слияние данных в фоновом режиме.

Для сравнения: хотя MySQL предлагает Archive Storage Engine и InnoDB со сжатием, первый не поддерживает индексы и крайне медленен для аналитики, а второй показывает посредственные результаты при OLAP-нагрузках и больших объёмах данных.

Итоги

Этот пример наглядно показывает, что ClickHouse без труда справляется с нагрузкой в миллиарды записей в сутки. При этом его не стоит рассматривать исключительно как решение «для очень больших данных». ClickHouse отлично подходит для хранения:

• статистики
• логов
• событийных данных
• информации, которую не нужно обновлять или выборочно удалять.

Если статистические запросы в MySQL работают медленно и не поддаются разумной оптимизации — индексы, сегментирование и разделение данных по таблицам перестают помогать — такие данные почти наверняка стоит перенести в ClickHouse.