Внедрение ClickHouse: аналитика, которая не кладёт прод
Проектирование, внедрение и поддержка ClickHouse - колоночной СУБД для отчётов и дашбордов на больших объёмах.
Классическая картина: аналитика подключена напрямую к боевой базе. Отчёт за квартал считается двадцать минут, всё это время пользователи жалуются на тормоза, а тяжёлые выгрузки приходится переносить на ночь. Строчная СУБД устроена под транзакции - читать по ней миллионы строк ради одной суммы неэффективно по самой природе хранения.
ClickHouse хранит данные по колонкам и сжимает их. Запрос читает только те колонки, которые нужны, - отсюда разница в скорости на порядки и возможность считать агрегаты на лету, а не готовить их заранее.
Когда он вам нужен
Отчёты и дашборды тянут данные из боевой базы и тормозят пользователей. Аналитическую нагрузку нужно унести в отдельную систему.
BI работает поверх строчной СУБД и упирается в неё. Витрины в ClickHouse отдают тот же отчёт за секунды.
События, логи, показания приборов, история продаж за годы. Хранить это в учётной системе дорого, а считать по нему - долго.
Отчётность за вчера уже не устраивает. Поток изменений через CDC и Kafka даёт аналитику с задержкой в минуты.
Что делаем
- Схема хранения, первичный ключ и порядок сортировки под реальные запросы
- Секционирование, время жизни данных, политики хранения
- Выбор движков таблиц и агрегирующих представлений
- Оценка железа под ваши объёмы и нагрузку
- Развёртывание в вашем контуре, один узел или кластер с репликацией
- Загрузка данных из учётных систем: пакетно или потоком через Kafka
- Витрины под отчётность, подключение BI
- Разграничение доступа, квоты и ограничения на тяжёлые запросы
- Мониторинг слияний, очередей репликации и дискового пространства
- Разбор медленных запросов и перестройка схемы, когда нагрузка изменилась
- Обновления версий и проверка восстановления из копий
- Работы в рамках абонентского обслуживания
Если данных немного и аналитика никому не мешает - отдельная система только добавит работы по эксплуатации. Если нужны транзакции, точечные обновления и жёсткая целостность - это задача для PostgreSQL или MS SQL, и мы скажем об этом прямо, а не станем продавать модную СУБД под неподходящую задачу.
Стоимость
Пилот на 2-3 источника с первой витриной и подключением BI - 1-2 месяца работ, смета после обследования. Разовые задачи и работы до 2-3 недель - по часам, 4 200 или 6 500 ₽/час. Если ClickHouse становится частью полноценного хранилища - см. построение DWH.
Частые вопросы
ClickHouse заменит нам PostgreSQL?
Нет, и не должен. ClickHouse - колоночная аналитическая СУБД: он считает агрегаты по миллиардам строк за секунды, но плохо приспособлен к транзакциям, точечным обновлениям и внешним ключам. Учётная система остаётся на PostgreSQL или MS SQL, а ClickHouse забирает аналитическую нагрузку. Это разные инструменты, а не замена одного другим.
У нас всего пара миллионов строк. ClickHouse нужен?
Скорее всего нет. На таких объёмах правильно настроенный PostgreSQL с индексами под аналитику справляется, а ClickHouse добавит отдельную систему, которую нужно эксплуатировать. Смысл появляется, когда аналитические запросы начинают мешать работе пользователей или когда объёмы растут до десятков и сотен миллионов строк.
Как данные попадут в ClickHouse?
По расписанию или потоком. Периодическая загрузка из учётных систем через ETL-процессы, поток изменений через CDC и Kafka, если аналитика должна отставать от реальности на минуты, а не на сутки. Выбор зависит от того, насколько свежие данные действительно нужны бизнесу.
Что ломается в ClickHouse чаще всего?
Неудачный первичный ключ и порядок сортировки - переделать потом дорого; слишком частые мелкие вставки, от которых сервер захлёбывается слиянием кусков; попытка использовать его как OLTP-базу с постоянными обновлениями строк; и мутации, которые запускают, не понимая, что это перезапись данных, а не UPDATE. Всё это лечится на этапе проектирования.
Нужен ли кластер или хватит одного сервера?
Одного сервера хватает дольше, чем принято думать: ClickHouse на приличном железе обрабатывает объёмы, под которые в других СУБД собирают кластер. Кластер с репликацией нужен, когда важна отказоустойчивость или когда данные перестали помещаться на один узел. Начинать разумно с одного узла и заранее заложить возможность роста.
Расскажите о задаче - мы предложим подходящий формат.