Стоковый ClickHouse занял 12 ГБ диска при 543 КБ данных: сколько на самом деле ест self-hosted observability

[aru89]

Смешались в кучу кони люди... автор, ты про что пишешь-то про клик или пг??? я про упоминание shared_buffers effective_cache_size max_parallel_workers в одном абзаце с кликовыми параметрами.

Ну и чтобы тебе mark_cache_size ООМ вызвал это надо сперва налить табличек с общим числом строк превышающим примерно так десятки лярдов. max_server_memory_usage тебе надо проставить, да и вообще вопрос на миллион зачем тебе кликхаус с 1ГБ памяти???

[otezvikentiy]

По порядку.

Про коней и людей - в стенде две базы: PostgreSQL под мету и ClickHouse под телеметрию, тюнился весь оверлей сразу, поэтому в списке из восьми настроек оказались обе. Но согласен, стоило подписать: shared_buffers, effective_cache_size и max_parallel_workers - это постгрес, остальное - клик.

Про mark_cache_size - справедливо. На таком объёме данных кэш засечек заполниться до гигабайт не мог, так что основной вклад в минус 66% памяти скорее дали урезанные фоновые пулы (128 -> 8 тредов) и отключённые системные логи с их буферами. В статье это с оговоркой "судя по всему", но вклад по компонентам я не изолировал - тут вы правы, перепроверю.

max_server_memory_usage - принято, добавлю в оверлей явно. В контейнере он и так считается как 0.9 от cgroup-лимита, но явная цифра честнее.

А "зачем клик с 1 ГБ" - так это и есть тема статьи. Self-hosted observability для маленьких проектов: телеметрия колоночная, агрегации по трейсам и метрикам на постгресе дороже. Вопрос на миллион скорее в том, почему дефолты клика рассчитаны на большое железо.

[aru89]

Кликхаус зародился в конторе которой надо было миллионы метрик в секунду куда-то загружать и потом ещё это (желательно параллельно) читать. Т.е. для переваривания больших объемов он и был создан, и это 99% кейсов его использования, от того и такие минималки в офф доках.

ИМХО На 1гб можно даже SQLite обойтись если ACID не нужен, мускуль с движком MyISAM тоже прост как два пальца. Ещё DuckDB хвалят, но я не щупал.

[otezvikentiy]

Про происхождение согласен, минималки в доках ровно оттуда. Но мне нужен был именно сервер с непрерывным инжестом, TTL и сжатием из коробки.

SQLite и MyISAM не взял из-за профиля нагрузки: постоянный поток мелких вставок от нескольких приложений плюс агрегации по широким диапазонам. SQLite - один писатель на базу, MyISAM - блокировки на таблицу и битые таблицы после падения. DuckDB хвалят заслуженно, но она встраиваемая: OLAP внутри процесса, а не сервис, куда шлют телеметрию извне - пришлось бы городить свой слой инжеста поверх.

Ну и прагматика: один и тот же движок работает и на VPS с 1 ГБ, и дальше при росте, без миграции. Ценой этого и стали 12 ГБ на дефолтах, про что и статья.