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

ClickHouse ставят, когда PostgreSQL или MySQL перестаёт справляться с аналитическими запросами. Типичный сценарий: таблица событий на 500 миллионов строк, запрос SELECT date, COUNT(*) FROM events WHERE user_id = ? GROUP BY date работает 30 секунд. В ClickHouse тот же запрос — меньше секунды. Но ClickHouse — не замена OLTP-базам. Он не любит обновления отдельных строк, транзакции и высококонкурентную точечную запись. Мы помогли десяткам проектов перейти на 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 > '2023-01-01' в 50–100 раз быстрее, чем PostgreSQL на той же таблице в 1 млрд строк. Согласно официальной документации 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?

Мы предоставляем полный цикл услуг:

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

Оценим ваш проект — напишите нам, мы подберём конфигурацию и приступим в течение 1-2 дней. Опыт нашей команды — более 5 лет администрирования ClickHouse, свыше 50 успешных проектов. Свяжитесь с нами для консультации.