ClickHouse — с чего начинается инстансClickHouse — where an instance starts
Прежде чем проектировать схему или настраивать кластер, нужен работающий сервер. Три пути установки, структура конфигурации (`config.xml` + `users.xml` + `config.d/`), и на что смотреть при выборе версии — прежде чем переходить к шардированию (следующая глава).Before designing a schema or configuring a cluster, you need a running server. Three installation paths, the config layout (`config.xml` + `users.xml` + `config.d/`), and what to watch for when picking a version — before moving to sharding (the next chapter).
| способmethod | когда выбратьwhen to choose it |
|---|---|
| bare-metal / .deb-.rpm пакетыbare-metal / .deb-.rpm packages | прод-инстансы с прямым доступом к NVMe и полным контролем над файловой системой — ClickHouse особенно чувствителен к дисковому I/O, и лишний слой виртуализации диска (overlay-fs в контейнере) может ощутимо просесть по производительности на тяжёлой записи.production instances with direct NVMe access and full control over the filesystem — ClickHouse is especially sensitive to disk I/O, and an extra disk-virtualization layer (a container's overlay-fs) can visibly hurt performance under heavy writes. |
| Docker | локальная разработка, CI, быстрый прототип схемы — официальный образ `clickhouse/clickhouse-server` поднимается за секунды; для прода допустим только с volume, смонтированным на быстрый диск напрямую (не на сетевую ФС).local development, CI, quick schema prototyping — the official clickhouse/clickhouse-server image starts in seconds; acceptable in production only with a volume mounted directly on fast disk (not a network filesystem). |
| ClickHouse Cloud / managed | когда эксплуатация кластера самостоятельно не оправдана по времени/экспертизе — managed-сервис берёт на себя шардирование, бэкапы и апгрейды ценой отсутствия контроля над низкоуровневым тюнингом и более высокой стоимостью на больших объёмах.when running a cluster yourself isn't worth the time/expertise — the managed service handles sharding, backups, and upgrades, at the cost of no control over low-level tuning and a higher price at scale. |
# bare-metal (Ubuntu/Debian) — официальный репозиторий, не дистрибутивный пакет# bare-metal (Ubuntu/Debian) — the official repo, not the distro package
curl https://clickhouse.com/ | sh
sudo ./clickhouse install
# Docker — для локальной разработки# Docker — for local development
docker run -d --name ch \
-v ch_data:/var/lib/clickhouse \
-p 8123:8123 -p 9000:9000 \
clickhouse/clickhouse-server:24.8`config.xml` — конфигурация сервера (порты, пути к данным, логирование, storage policies); `users.xml` — пользователи, роли, квоты и лимиты профилей. Оба файла на практике не редактируются напрямую — вместо этого используется директория `config.d/` (и `users.d/`), куда кладутся отдельные `.xml`-фрагменты, автоматически подмешиваемые к базовому конфигу при старте. Это тот же принцип "drop-in конфигурация", что у systemd или nginx `conf.d/` — изменения изолированы по файлам, диффы в git читаемы, апгрейд версии не затирает локальные правки в основном файле.config.xml is the server configuration (ports, data paths, logging, storage policies); users.xml holds users, roles, quotas, and profile limits. Neither file is typically edited directly in practice — instead, the config.d/ (and users.d/) directory holds separate .xml fragments automatically merged into the base config at startup. It's the same "drop-in config" principle as systemd or nginx's conf.d/ — changes are isolated per file, git diffs stay readable, and a version upgrade doesn't clobber local edits to the main file.
/etc/clickhouse-server/
├── config.xml // база, обычно не трогается// base, usually untouched
├── users.xml // база пользователей// base users
├── config.d/
│ ├── storage.xml // storage policies, диски// storage policies, disks
│ ├── logging.xml
│ └── remote_servers.xml // топология кластера// cluster topology
└── users.d/
└── app_user.xml // пользователь приложения, квоты// application user, quotasClickHouse выпускает релизы часто (примерно раз в месяц) и помечает часть из них как `lts` (Long-Term Support) — для прода имеет смысл закрепиться на конкретной `lts`-версии и обновляться осознанно, а не гнаться за последним релизом ради новых функций. Мажорные обновления между `lts`-версиями стоит тестировать на staging: изменения в поведении дефолтных настроек (`compatibility`-флаг существует именно для смягчения таких переходов) случаются регулярно.ClickHouse ships releases often (roughly monthly) and marks some as lts (Long-Term Support) — for production it makes sense to pin to a specific lts version and upgrade deliberately, not chase the latest release for new features. Major upgrades between lts versions are worth testing on staging: changes in default-setting behavior happen regularly (the compatibility flag exists specifically to soften such transitions).
Если Docker-volume для `/var/lib/clickhouse` физически лежит на сетевом хранилище или медленном диске (частая ситуация в облачных дефолтах), ClickHouse запустится и будет работать без ошибок, но производительность вставок и слияний кусков (см. архитектуру) окажется на порядок ниже ожидаемой — и это не будет очевидно из логов, только из реальных замеров.If the Docker volume for /var/lib/clickhouse physically sits on network storage or a slow disk (a common cloud default), ClickHouse starts and runs without errors, but insert and part-merge (see architecture) performance ends up an order of magnitude below expectations — and it won't be obvious from the logs, only from actual measurements.
Изменения в самом `config.xml` теряются или конфликтуют при обновлении пакета (пакетный менеджер может предложить заменить файл или создать `.dpkg-new` рядом, оставив старый с вашими правками активным — тихое рассинхронизирование). Все локальные изменения должны идти через `config.d/`/`users.d/`, которые обновление пакета не трогает.Changes to config.xml itself get lost or conflict on a package upgrade (the package manager may offer to replace the file or drop a .dpkg-new next to it while leaving the old one with your edits active — a silent desync). All local changes should go through config.d//users.d/, which a package upgrade doesn't touch.