ClickHouse — быстрая колоночная СУБД для аналитики, и в Kubernetes она чувствует себя нормально. Но «нормально» получается только если понимать, где именно stateful-нагрузка конфликтует с моделью Kubernetes и какие настройки на самом деле решают: топология шардов и реплик, кворум Keeper, тип дисков, ORDER BY, размер вставок и лимиты памяти.
Эта серия — собранные вместе практики промышленной эксплуатации ClickHouse в Kubernetes. Без «поднимите Helm-чарт и радуйтесь»: каждая часть объясняет, что произойдёт под нагрузкой и что чинить, когда пойдёт не так.
Практика с больших инсталляций (по материалам блога ClickHouse):
Для тех, кто уже умеет в Kubernetes и хочет завести ClickHouse так, чтобы через полгода он не превратился в набор ручных костылей. Базовое знакомство с SQL и kubectl подразумевается; специфика ClickHouse объясняется по ходу.
Материал опирается на официальную документацию ClickHouse и оператора Altinity (Apache-2.0). Все примеры — мои; проверяйте версии и настройки под свою инсталляцию, API операторов меняется.
MergeTree, куски и слияния, шарды против реплик, роль Keeper. Где stateful-природа ClickHouse конфликтует с моделью Kubernetes и почему вертикальное масштабирование стоит исчерпать до шардирования.
С 2025 года у ClickHouse есть первопартийный оператор с CRD ClickHouseCluster и KeeperCluster. Разбираем его, сравниваем с проверенным оператором Altinity и выбираем, что брать под новый и под существующий кластер.
Keeper — фундамент репликации: если он лёг, кластер уходит в read-only. Сколько нужно узлов, почему их число нечётное, какие ресурсы и диск давать и почему Keeper нельзя селить вместе с ClickHouse.
Локальные NVMe против сетевых томов, расширение PVC без простоя, политики хранения и вынос холодных данных в S3 через TTL. Плюс кэш для объектного хранилища и типичные ошибки с reclaim policy.
ORDER BY по возрастанию кардинальности, разумное партиционирование, экономные типы и кодеки сжатия, TTL и выбор движка. Решения этого уровня влияют на скорость сильнее любого тюнинга сервера.
Почему мелкие вставки убивают ClickHouse, какой размер батча брать, как работает async_insert и его настройки, куда вставлять при шардировании и как устроена дедупликация.
Почему CPU-лимиты вредят аналитической нагрузке, как согласовать лимиты памяти пода с внутренними лимитами ClickHouse, зачем нужны профили и квоты и что делать с тяжёлыми запросами.
Какие системные таблицы читать при разборе инцидента, какие метрики отдавать в Prometheus и какой минимальный набор алертов реально предсказывает отказ, а не создаёт шум.
Встроенный BACKUP/RESTORE и clickhouse-backup, как работает FREEZE с жёсткими ссылками, инкрементальные копии в S3, что делать с Keeper и почему непроверенное восстановление не считается бэкапом.
Пользователи и права без superuser по умолчанию, изоляция сети и TLS, безопасные обновления с PDB, миграции схемы через ON CLUSTER и сводка анти-паттернов, которые дороже всего обходятся в проде.
Три итерации архитектуры приёма телеметрии в ClickHouse на 50 млн событий/с: почему падает связка agent→gateway, чем плох WAL на диске и как устроен перелив в S3 через failover-коннектор с отдельным catchup-коллектором.
Почему в ClickHouse отказались от OTel-конвейера ради прямого переноса данных между базами: 37 млн логов/с на 70 ядрах против 2 млн на 800. Разбираем идею широких событий и динамические схемы через Merge.
431 ПиБ и 1.59 квадриллиона строк на 33 геошардах в AWS, Azure и GCP. Разбираем геошардинг, async inserts с 24-кратным батчингом, суточные партиции и трёхуровневую иерархию Distributed-таблиц.
Введите ключевые слова для поиска статей