Адміністрування ClickHouse: встановлення, налаштування, оптимізація

ClickHouse ставлять, коли PostgreSQL або MySQL перестає справлятися з аналітичними запитами. Типовий сценарій: таблиця подій на 500 мільйонів рядків, запит SELECT date, COUNT(*) FROM events WHERE user_id = ? GROUP BY date працює 30 секунд. У ClickHouse той самий запит — менше секунди. Але ClickHouse — не заміна OLTP-базам. Він не любить оновлення окремих рядків, транзакції та висококонкурентний точковий запис. Ми допомогли десяткам проєктів перейти на ClickHouse і знаємо, як уникнути типових помилок при адмініструванні ClickHouse: встановленні, налаштуванні, оптимізації. Отримайте консультацію по вашому проєкту — ми підберемо оптимальну конфігурацію.

Як ми налаштовуємо ClickHouse під ваше навантаження?

Ми починаємо з аудиту: обсяг даних, типи запитів, частота запису, вимоги до SLA. На основі цього підбираємо топологію — standalone, кластер з шардуванням або реплікацією. Встановлюємо сервер з оптимальними параметрами конфігурації, налаштовуємо storage policies для tiered-зберігання, створюємо користувачів з мінімальними правами та вмикаємо моніторинг через system.query_log і Prometheus. Усе робиться під ключ — від інсталяції до документації.

Встановлення та базова структура конфігурації

ClickHouse зберігає конфігурацію в кількох файлах:

• /etc/clickhouse-server/config.xml — основний конфіг
• /etc/clickhouse-server/users.xml — користувачі та права
• /etc/clickhouse-server/config.d/ — override-файли (переважні для кастомізації)
• /etc/clickhouse-server/users.d/ — те саме для користувачів

Найкраща практика — не чіпати основні файли, а створювати override в config.d/:

<!-- /etc/clickhouse-server/config.d/custom.xml -->
<clickhouse>
  <logger>
    <level>information</level>
    <log>/var/log/clickhouse-server/clickhouse-server.log</log>
    <errorlog>/var/log/clickhouse-server/clickhouse-server.err.log</errorlog>
    <size>1000M</size>
    <count>5</count>
  </logger>
  <max_connections>4096</max_connections>
  <listen_host>0.0.0.0</listen_host>
  <http_port>8123</http_port>
  <tcp_port>9000</tcp_port>
  <interserver_http_port>9009</interserver_http_port>
  <path>/var/lib/clickhouse/</path>
  <tmp_path>/var/lib/clickhouse/tmp/</tmp_path>
  <mark_cache_size>5368709120</mark_cache_size>
  <uncompressed_cache_size>8589934592</uncompressed_cache_size>
</clickhouse>

Ключові параметри продуктивності

mark_cache_size — кеш індексних позначок MergeTree. Кожен файл даних у MergeTree має .mrk файл з позиціями гранул. Кеш позначок утримує їх у пам'яті та прискорює читання. 5 GB — розумний старт для сервера з 32 GB RAM.

uncompressed_cache_size — кеш розжатих даних. ClickHouse зберігає дані стиснутими (LZ4 за замовчуванням). При повторних запитах до одних і тих самих даних кеш економить CPU на декомпресію. 8 GB розумно, але для аналітичних запитів з великим різноманіттям даних цей кеш менш ефективний, ніж для OLTP.

max_threads у контексті запиту — скільки CPU-потоків може використовувати один запит:

<!-- users.d/default-settings.xml -->
<clickhouse>
  <profiles>
    <default>
      <max_threads>8</max_threads>
      <max_memory_usage>10000000000</max_memory_usage>
      <max_bytes_before_external_group_by>5000000000</max_bytes_before_external_group_by>
    </default>
  </profiles>
</clickhouse>

max_memory_usage — ліміт пам'яті на один запит. При перевищенні ClickHouse падає з помилкою Memory limit exceeded. Для важких аналітичних запитів потрібно підняти або використовувати max_bytes_before_external_group_by — це дозволяє GROUP BY на диску при нестачі пам'яті.

Порівняння кешів:

Дискова підсистема та tiered storage

ClickHouse активно читає з диска — стиснуті дані по частинах (гранули). SSD критичний для хорошої продуктивності. На HDD можна працювати, але агрегації по великих таблицях будуть повільними.

Як налаштувати storage policies?

Для розділення гарячих і холодних даних використовуємо storage policies:

<!-- config.d/storage.xml -->
<clickhouse>
  <storage_configuration>
    <disks>
      <hot>
        <path>/data/hot/</path>
      </hot>
      <cold>
        <path>/data/cold/</path>
      </cold>
    </disks>
    <policies>
      <tiered>
        <volumes>
          <hot_volume>
            <disk>hot</disk>
            <max_data_part_size_bytes>1073741824</max_data_part_size_bytes>
          </hot_volume>
          <cold_volume>
            <disk>cold</disk>
          </cold_volume>
        </volumes>
        <move_factor>0.2</move_factor>
      </tiered>
    </policies>
  </storage_configuration>
</clickhouse>

Частини даних старші за певний час автоматично переміщуються з NVMe на повільніший (і дешевший) диск. Це економить до 60% витрат на сховище.

Моніторинг через системні таблиці

ClickHouse багатий на внутрішню статистику:

-- Поточні запити SELECT query_id, user, elapsed, read_rows, memory_usage, query FROM system.processes ORDER BY elapsed DESC;
-- Повільні запити (last 24h)
SELECT normalized_query_hash, count() AS cnt, avg(query_duration_ms) AS avg_ms, max(query_duration_ms) AS max_ms, any(query) AS sample_query FROM system.query_log WHERE event_time > now() - INTERVAL 24 HOUR AND type = 'QueryFinish' GROUP BY normalized_query_hash ORDER BY avg_ms DESC LIMIT 20;
-- Розмір таблиць
SELECT database, table, formatReadableSize(sum(bytes_on_disk)) AS disk_size, sum(rows) AS total_rows FROM system.parts WHERE active GROUP BY database, table ORDER BY sum(bytes_on_disk) DESC;

system.query_log — золото для оптимізації. Містить повну статистику кожного запиту: час, прочитані рядки, використану пам'ять, план виконання.

Чому ClickHouse швидший за PostgreSQL для аналітики?

У колонковій СУБД дані зберігаються по стовпцях, тому для агрегацій читається лише потрібний стовпець, а не весь рядок. Плюс ClickHouse використовує SIMD-інструкції, стиснення LZ4/ZSTD та векторизовані обчислення. У наших тестах ClickHouse виконує SELECT SUM(amount) FROM transactions WHERE date > '2024-01-01' у 50–100 разів краще, ніж PostgreSQL на тій самій таблиці в 1 млрд рядків — скорочення часу виконання запиту на 90–99%. Згідно з офіційною документацією ClickHouse, колонкове зберігання та векторизовані обчислення забезпечують таке прискорення.

Безпека ClickHouse після встановлення

Одна з частих помилок — залишити користувача default без пароля. ClickHouse не має аутентифікації за замовчуванням, тому будь-хто може підключитися до HTTP-інтерфейсу та виконувати запити. Щоб це виправити, виконайте чотири кроки:

1. Встановіть пароль для користувача default, використовуючи SHA256-хеш, і пропишіть його в users.d/users.xml.
2. Обмежте мережевий доступ, вказавши дозволені IP-адреси в тому самому файлі.
3. Закрийте interserver_http_port файрволом — він використовується для реплікації і не потребує аутентифікації.
4. Увімкніть HTTPS для HTTP-інтерфейсу.

Приклад конфігурації:

<!-- users.d/users.xml -->
<clickhouse>
  <users>
    <default>
      <password_sha256_hex>hash-of-your-password</password_sha256_hex>
      <networks>
        <ip>::1</ip>
        <ip>127.0.0.1</ip>
        <ip>10.0.0.0/8</ip>
      </networks>
    </default>
  </users>
</clickhouse>

Ці заходи запобігають несанкціонованому доступу.

Що входить у роботу з адміністрування ClickHouse?

Ми надаємо повний цикл послуг. Наша команда має 5+ років досвіду та 50+ успішних проєктів з ClickHouse. Ми гарантуємо якісне налаштування та підтримку. Наші сертифіковані інженери мають багаторічний досвід в адмініструванні ClickHouse.

• Встановлення та налаштування — підбір конфігурації під ваше навантаження, налаштування сховища (tiered storage), створення користувачів і прав.
• Оптимізація — налаштування кешів, партиціонування, вибір двигуна таблиць (MergeTree, ReplacingMergeTree, SummingMergeTree), профілювання запитів.
• Моніторинг та alerting — інтеграція з Prometheus, налаштування дашбордів у Grafana, алерти на повільні запити та аномалії.
• Безпека — налаштування паролів, обмеження мережевого доступу, ввімкнення HTTPS.
• Документація — схема конфігурації, інструкції з експлуатації, runbook для типових інцидентів.
• Підтримка — після введення в експлуатацію відповідаємо на питання, допомагаємо з доробками.

Оцінимо ваш проєкт — напишіть нам, ми підберемо конфігурацію та приступимо протягом 1-2 днів. Досвід нашої команди — понад 5 років адміністрування ClickHouse, понад 50 успішних проєктів. Зв'яжіться з нами для консультації.