Как установить и настроить ClickHouse на VPS

MAATRIX

ClickHouse на VPS — это колоночная аналитическая СУБД, которая считает агрегаты по миллиардам строк за доли секунды. Её берут под логи, метрики, веб-аналитику, события и любые задачи, где нужно быстро агрегировать огромные объёмы данных. ClickHouse не заменяет обычную транзакционную базу, а дополняет её: он заточен под чтение и агрегацию, а не под частые точечные обновления. Ниже — рабочий путь от чистого сервера до настроенного ClickHouse: установка из официального репозитория, создание пользователей, сетевой доступ, настройка памяти и первая таблица.

Сколько ресурсов нужно ClickHouse

ClickHouse любит ресурсы, но эффективно ими распоряжается. Для старта и небольших объёмов подойдёт VPS с 2–4 ГБ RAM, но по-настоящему он раскрывается на 8 ГБ и больше — память нужна под кэши и буферы агрегации. Диск важен не меньше памяти: колоночное хранение отлично сжимает данные (нередко в 5–10 раз), но под сырые логи и события всё равно нужен объём, поэтому берите тариф с запасом по SSD.

Локацию выбирайте по источнику данных и потребителям отчётов. Если ClickHouse собирает логи с российских серверов и аналитику смотрит российская команда — логичен RU-сервер с минимальным пингом. Если данные приходят из зарубежной инфраструктуры — US или UK ближе к источникам. Поскольку в ClickHouse часто льют большие объёмы, держите его в одной сети с источниками данных, чтобы не гонять трафик через полмира.

Примеры даны для Ubuntu 24.04 LTS, работаем под пользователем с sudo. ClickHouse требователен, поэтому селить его на один VPS с нагруженной транзакционной базой не стоит — дайте ему отдельный сервер или как минимум изолированные ресурсы.

Установка из официального репозитория

ClickHouse развивается быстро, поэтому ставить его лучше из официального репозитория, а не из системного — так вы получите свежую версию и оперативные обновления:

sudo apt install -y apt-transport-https ca-certificates curl gnupg
curl -fsSL 'https://packages.clickhouse.com/rpm/lts/repodata/repomd.xml.key' | \
  sudo gpg --dearmor -o /usr/share/keyrings/clickhouse-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/clickhouse-keyring.gpg] \
  https://packages.clickhouse.com/deb stable main" | \
  sudo tee /etc/apt/sources.list.d/clickhouse.list
sudo apt update
sudo apt install -y clickhouse-server clickhouse-client

Во время установки инсталлятор предложит задать пароль для пользователя default — задайте его сразу, не оставляйте пустым. Запустите сервер и проверьте подключение:

sudo systemctl enable --now clickhouse-server
clickhouse-client --password

Если открылась консоль с приглашением — сервер работает. Конфиги лежат в /etc/clickhouse-server, данные — в /var/lib/clickhouse, логи — в /var/log/clickhouse-server. Основной HTTP-интерфейс висит на порту 8123, нативный протокол — на 9000.

Стоит запомнить логику конфигурации, потому что она непривычна для тех, кто пришёл из мира MySQL. Основной файл config.xml трогать напрямую не рекомендуется: свои изменения кладут отдельными файлами в каталоги config.d/ и users.d/, и ClickHouse накладывает их поверх базового конфига. Это удобно при обновлениях — ваши правки не затираются новой версией пакета. И ещё одна важная деталь: ClickHouse очень строг к синтаксису XML. Одна незакрытая скобка или лишний символ — и сервер не стартует, а причину придётся искать в clickhouse-server.err.log. Поэтому после каждой правки конфига проверяйте запуск и держите изменения маленькими.

Пользователи и пароли

Пользователь default с полным доступом — это удобно для старта, но небезопасно для продакшена. Заведите отдельного пользователя под приложение и, при необходимости, пользователя только для чтения под аналитиков. В новых версиях это делается прямо через SQL:

CREATE USER analyst IDENTIFIED BY 'слоЖный_Пароль_2026';
GRANT SELECT ON logs.* TO analyst;

Такой подход даёт гибкое разграничение: приложение-писатель получает права на вставку в свои таблицы, аналитик — только чтение конкретной базы. Классический способ через XML-файлы в /etc/clickhouse-server/users.d/ тоже работает и удобен для инфраструктуры как код, но для большинства случаев SQL-управление пользователями проще и нагляднее. Главное правило то же, что и везде: не используйте всесильного default в приложениях, заведите роли под конкретные задачи и ограничьте их права.

Настройка сетевого доступа

По умолчанию ClickHouse слушает только localhost. Если сервер и потребители данных на одной машине — оставьте так. Для доступа с других серверов откройте прослушивание нужного адреса в конфиге:

sudo nano /etc/clickhouse-server/config.xml

<listen_host>10.0.0.5</listen_host>

После правки перезапустите сервер и обязательно закройте порты 8123 и 9000 фаерволом для всех, кроме доверенных адресов:

sudo systemctl restart clickhouse-server
sudo ufw allow from 10.0.0.0/24 to any port 8123 proto tcp
sudo ufw allow from 10.0.0.0/24 to any port 9000 proto tcp

Никогда не открывайте ClickHouse в интернет без фаервола — незащищённый аналитический сервер с вашими данными становится лёгкой мишенью. Идеальный вариант доступа снаружи — приватная сеть или SSH-туннель между серверами, тогда порты вообще не смотрят в публичный интернет. Если аналитики подключаются извне, ставьте перед ClickHouse обратный прокси с HTTPS и авторизацией, а не выставляйте его порты напрямую.

Ограничение памяти и профили

ClickHouse способен на один тяжёлый запрос занять всю память сервера. Чтобы один отчёт не уронил весь сервис, задайте лимиты в профиле по умолчанию. Настройки задаются в users.xml или через профили:

<max_memory_usage>4000000000</max_memory_usage>
<max_execution_time>60</max_execution_time>

max_memory_usage ограничивает память на один запрос — поставьте его ниже общего объёма RAM, оставив запас системе. max_execution_time прерывает слишком долгие запросы, защищая от случайных декартовых произведений и забытых фильтров. Эти лимиты не мешают нормальной работе, но спасают сервер от одного неудачного запроса, который иначе съел бы всё. Для разных ролей заводят разные профили: аналитику с интерактивными запросами дают более жёсткие лимиты, фоновым ETL-задачам — более мягкие.

Первая база и таблица

ClickHouse хранит данные в таблицах с движком, и для аналитики почти всегда используют семейство MergeTree. Создадим базу и таблицу под логи:

CREATE DATABASE logs;
CREATE TABLE logs.events
(
    event_date Date,
    event_time DateTime,
    user_id UInt64,
    event_type String,
    url String
)
ENGINE = MergeTree()
PARTITION BY toYYYYMM(event_date)
ORDER BY (event_date, user_id);

Ключевые решения здесь — PARTITION BY (разбиение по месяцам упрощает удаление старых данных целыми кусками) и ORDER BY (определяет физический порядок и то, какие запросы будут быстрыми). Правильный ключ сортировки — половина производительности ClickHouse: ставьте в начало столбцы, по которым чаще всего фильтруете. Проверить, что вставка и чтение работают, можно сразу: вставьте несколько строк через INSERT INTO logs.events VALUES (...) и выполните простой SELECT count() FROM logs.events. Если счётчик растёт — таблица готова принимать данные.

Здесь же стоит сразу заложить привычку вставлять данные пачками. ClickHouse рассчитан на массовую загрузку: одна вставка на тысячи строк работает отлично, а тысяча вставок по строке создаёт лавину мелких кусков и приводит к ошибке Too many parts. Если данные приходят потоком по одному событию, буферизуйте их в приложении и сбрасывайте пачками раз в секунду-две. Эта привычка, заложенная с первой таблицы, избавит вас от самой частой эксплуатационной проблемы ClickHouse. Чтобы всё это работало на реальных объёмах, нужен VPS с достаточной памятью и быстрым диском. В MAATRIX можно арендовать сервер под ClickHouse в России, США или Великобритании и оплатить картой РФ, по СБП, криптой или токеном MAAT — иностранная карта не нужна.

Частые вопросы