ClickHouse — колоночная СУБД для аналитических запросов: подсчёт событий, разбор логов, агрегация метрик за длительные периоды. В каталоге ZevsHost нет отдельной статьи про неё, хотя вопрос «куда девать логи и события, чтобы не нагружать основную MySQL-базу» встречается часто. Разберём, когда ClickHouse оправдан рядом с MySQL на одном VDS и чего от него не стоит ждать.
Когда ClickHouse нужен, а когда MySQL достаточно
ClickHouse выигрывает там, где нужно просканировать миллионы строк и посчитать агрегат — сумму, количество уникальных посетителей за месяц, разбивку по часам. Колоночное хранение читает только нужные столбцы, а не всю строку целиком, поэтому такие запросы на порядки быстрее, чем на обычной строковой таблице InnoDB с тем же объёмом данных.
Если сайту хватает выборки «последние 50 заказов клиента» или «карточка товара по id», ClickHouse не нужен — для точечных выборок по первичному ключу и для записей с частыми точечными обновлениями MySQL остаётся правильным выбором; разницу между реляционными СУБД подробнее разбирает статья MySQL или PostgreSQL: как выбрать СУБД.
Как ClickHouse хранит данные
Таблицы в ClickHouse создают с движком семейства MergeTree — именно он отвечает за сортировку данных по ключу и фоновое слияние мелких кусков в крупные.
CREATE TABLE events
(
event_date Date,
event_time DateTime,
user_id UInt64,
event_type String
)
ENGINE = MergeTree()
ORDER BY (event_date, user_id);Данные физически лежат отсортированными по ключу ORDER BY, а не по порядку вставки, поэтому выборка по диапазону дат читает только нужные куски с диска, а не всю таблицу.
Как перенести данные из MySQL
Прямой перенос построчными INSERT из PHP-скрипта работает, но создаёт в ClickHouse множество мелких кусков данных, которые потом фоново сливаются и нагружают диск сильнее, чем сама вставка.
- Вставлять данные партиями: одной вставкой отправлять от 1 000 до 100 000 строк — чем крупнее партия, тем меньше кусков должен слить фон слияния, а конкретное число зависит от размера строки и частоты вставок.
- Использовать табличный движок MySQL или словарь с источником MySQL для чтения справочников без дублирования данных на обеих сторонах.
- Для потока событий — накапливать события в файле или в очереди и импортировать пакетами по расписанию, а не писать в ClickHouse из каждого запроса пользователя напрямую.
- Для обновления и удаления строк использовать мутации (ALTER TABLE ... UPDATE/DELETE) и помнить, что они выполняются асинхронно в фоне, а не мгновенно, как UPDATE в InnoDB.
- Отключить вставку по одной строке из веб-приложения на проде — даже редкие прямые INSERT из обработчика запроса создают нагрузку, непропорциональную объёму данных.
ClickHouse не заменяет транзакционную базу — для неё нет многотабличных транзакций и внешних ключей, которые есть в MySQL и в PostgreSQL; принципы выбора реляционной СУБД под транзакционную нагрузку описаны в статье про настройку PostgreSQL на VPS.
Ресурсы, которые понадобятся на VDS
ClickHouse активно использует оперативную память для кэша несжатых блоков и для промежуточных структур при агрегации, а также постоянно пишет на диск при фоновом слиянии кусков — на медленном сетевом диске это создаёт заметную нагрузку по I/O даже без запросов пользователей.
| Параметр | InnoDB (MySQL) | MergeTree (ClickHouse) |
|---|---|---|
| Хранение строк | По строкам, вся строка целиком | По столбцам, отдельно каждый столбец |
| Сильная сторона | Точечные выборки и частые изменения строк | Агрегаты по миллионам строк |
| Обновление строки | Мгновенное, в рамках транзакции | Асинхронная мутация, без транзакций |
| Нагрузка на диск | Случайные чтения и записи | Последовательные чтения, фоновые слияния |
Сколько памяти и дискового пространства нужно под ClickHouse на конкретном VDS, зависит от объёма исторических данных и от того, сколько столбцов участвует в типичном запросе — для контроля свободного места и нагрузки на диск подходит обычный мониторинг ресурсов VDS, настроенный на отдельный раздел под базу.
Как следить за ClickHouse на сервере
Сама СУБД пишет собственный лог в системные таблицы — system.query_log хранит текст и время выполнения каждого запроса, а system.merges показывает, какие куски сливаются фоном прямо сейчас.
Если фоновые слияния не успевают за потоком вставок, число кусков в таблице растёт, а новые запросы на чтение замедляются — это первый признак того, что размер партии вставки нужно увеличить или перенести ClickHouse на диск с более высокой скоростью записи.
Частые вопросы
Можно ли поставить ClickHouse и MySQL на один VDS?
Да, при достаточном объёме оперативной памяти для обоих процессов это обычная практика: MySQL обслуживает транзакционную нагрузку сайта, а ClickHouse — аналитику и логи, подключённые отдельным процессом чтения. Важно развести их по разным дискам или хотя бы разделам, если дисковая нагрузка от слияний в ClickHouse мешает MySQL.
Подходит ли ClickHouse для хранения заказов интернет-магазина?
Нет, для заказов нужны транзакции, внешние ключи и мгновенные точечные обновления статуса — это задача MySQL или PostgreSQL. ClickHouse годится для витрины аналитики по тем же заказам: сколько заказов в час, средний чек по категориям, но не для самой записи, которая должна остаться в реляционной базе.
Нужен ли ClickHouse, если логов и событий немного?
Если объём логов измеряется тысячами записей в сутки, обычная таблица InnoDB с правильными индексами справится без проблем, а разворачивать отдельную аналитическую СУБД смысла нет — ClickHouse оправдан, когда счёт идёт на миллионы строк и агрегатные запросы к InnoDB начинают выполняться заметно дольше точечных.