Обзор системных таблиц

Системные таблицы предоставляют информацию о:

Состоянии сервера, процессах и окружении.
Внутренних процессах сервера.
Опциях, использованных при сборке бинарного файла ClickHouse.

Системные таблицы:

Находятся в базе данных system.
Доступны только для чтения данных.
Не могут быть удалены или изменены, но могут быть отсоединены.

Большинство системных таблиц хранят свои данные в оперативной памяти. Сервер ClickHouse создает такие системные таблицы при запуске.

В отличие от других системных таблиц, системные журнальные таблицы metric_log, query_log, query_thread_log, trace_log, part_log, crash_log, text_log и backup_log обслуживаются движком таблицы MergeTree и по умолчанию хранят свои данные в файловой системе. Если вы удалите таблицу из файловой системы, сервер ClickHouse создаст пустую таблицу заново при следующей записи данных. Если схема системной таблицы изменилась в новом релизе, ClickHouse переименовывает текущую таблицу и создает новую.

Таблицы системных журналов можно настраивать, создавая конфигурационный файл с тем же именем, что и таблица, в каталоге /etc/clickhouse-server/config.d/, или задавая соответствующие элементы в /etc/clickhouse-server/config.xml. Настраиваемые элементы:

database: база данных, к которой относится системная журнальная таблица. Этот параметр сейчас устарел. Все системные журнальные таблицы находятся в базе данных system.
table: таблица для записи данных.
partition_by: выражение PARTITION BY.
ttl: выражение TTL таблицы.
flush_interval_milliseconds: интервал сброса данных на диск.
engine: полное выражение движка (начиная с ENGINE = ) с параметрами. Этот параметр конфликтует с partition_by и ttl. При одновременной установке сервер сгенерирует исключение и завершит работу.

Пример:

<clickhouse>
    <query_log>
        <database>system</database>
        <table>query_log</table>
        <partition_by>toYYYYMM(event_date)</partition_by>
        <ttl>event_date + INTERVAL 30 DAY DELETE</ttl>
        <!--
        <engine>ENGINE = MergeTree PARTITION BY toYYYYMM(event_date) ORDER BY (event_date, event_time) SETTINGS index_granularity = 1024</engine>
        -->
        <flush_interval_milliseconds>7500</flush_interval_milliseconds>
        <max_size_rows>1048576</max_size_rows>
        <reserved_size_rows>8192</reserved_size_rows>
        <buffer_size_rows_flush_threshold>524288</buffer_size_rows_flush_threshold>
        <flush_on_crash>false</flush_on_crash>
    </query_log>
</clickhouse>

По умолчанию рост таблицы не ограничен. Чтобы контролировать размер таблицы, вы можете использовать настройки TTL для удаления устаревших записей логов. Также вы можете использовать механизм партиционирования таблиц движка MergeTree.

Источники системных метрик

Для сбора системных метрик сервер ClickHouse использует:

привилегию CAP_NET_ADMIN.
procfs (только в Linux).

procfs

Если сервер ClickHouse не имеет привилегии CAP_NET_ADMIN, он пытается использовать ProcfsMetricsProvider. ProcfsMetricsProvider позволяет собирать системные метрики на уровне отдельных запросов (по CPU и I/O).

Если procfs поддерживается и включён в системе, сервер ClickHouse собирает следующие метрики:

OSCPUVirtualTimeMicroseconds
OSCPUWaitMicroseconds
OSIOWaitMicroseconds
OSReadChars
OSWriteChars
OSReadBytes
OSWriteBytes

Примечание

OSIOWaitMicroseconds по умолчанию отключена в ядрах Linux, начиная с версии 5.14.x. Вы можете включить её с помощью sudo sysctl kernel.task_delayacct=1 или создав файл .conf в /etc/sysctl.d/ с содержимым kernel.task_delayacct = 1

Системные таблицы в ClickHouse Cloud

В ClickHouse Cloud системные таблицы предоставляют критически важную информацию о состоянии и производительности сервиса, так же, как и в развертываниях с самостоятельным управлением. Некоторые системные таблицы работают на уровне всего кластера, особенно те, которые получают данные с узлов Keeper, управляющих распределёнными метаданными. Эти таблицы отражают совокупное состояние кластера и должны возвращать согласованные данные при выполнении запросов с отдельных узлов. Например, таблица parts должна возвращать согласованные данные независимо от узла, с которого выполняется запрос:

SELECT hostname(), count()
FROM system.parts
WHERE `table` = 'pypi'

┌─hostname()────────────────────┬─count()─┐
│ c-ecru-qn-34-server-vccsrty-0 │      26 │
└───────────────────────────────┴─────────┘

1 row in set. Elapsed: 0.005 sec.

SELECT
 hostname(),
    count()
FROM system.parts
WHERE `table` = 'pypi'

┌─hostname()────────────────────┬─count()─┐
│ c-ecru-qn-34-server-w59bfco-0 │      26 │
└───────────────────────────────┴─────────┘

1 row in set. Elapsed: 0.004 sec.

Напротив, другие системные таблицы являются специфичными для узла, например, хранятся в памяти или сохраняют свои данные с использованием движка таблиц MergeTree. Это характерно для данных, таких как журналы (логи) и метрики. Такое постоянное хранение обеспечивает доступность исторических данных для анализа. Однако эти специфичные для узла таблицы по своей сути уникальны для каждого отдельного узла.

В общем случае при определении того, является ли системная таблица специфичной для узла, можно руководствоваться следующими правилами:

Системные таблицы с суффиксом _log.
Системные таблицы, предоставляющие метрики, например metrics, asynchronous_metrics, events.
Системные таблицы, отражающие выполняющиеся процессы, например processes, merges.

Кроме того, новые версии системных таблиц могут создаваться в результате обновлений или изменений их схемы. Эти версии именуются с использованием числового суффикса.

Например, рассмотрим таблицы system.query_log, которые содержат строку для каждого запроса, выполненного на узле:

SHOW TABLES FROM system LIKE 'query_log%'

┌─name─────────┐
│ query_log    │
│ query_log_1  │
│ query_log_10 │
│ query_log_2  │
│ query_log_3  │
│ query_log_4  │
│ query_log_5  │
│ query_log_6  │
│ query_log_7  │
│ query_log_8  │
│ query_log_9  │
└──────────────┘

11 строк в наборе. Затрачено: 0.004 сек.

Выполнение запросов к нескольким версиям

Мы можем выполнять запросы к этим таблицам, используя функцию merge. Например, запрос ниже определяет последний запрос, отправленный на целевой узел, в каждой таблице query_log:

SELECT
    _table,
    max(event_time) AS most_recent
FROM merge('system', '^query_log')
GROUP BY _table
ORDER BY most_recent DESC

┌─_table───────┬─────────most_recent─┐
│ query_log    │ 2025-04-13 10:59:29 │
│ query_log_1  │ 2025-04-09 12:34:46 │
│ query_log_2  │ 2025-04-09 12:33:45 │
│ query_log_3  │ 2025-04-07 17:10:34 │
│ query_log_5  │ 2025-03-24 09:39:39 │
│ query_log_4  │ 2025-03-24 09:38:58 │
│ query_log_6  │ 2025-03-19 16:07:41 │
│ query_log_7  │ 2025-03-18 17:01:07 │
│ query_log_8  │ 2025-03-18 14:36:07 │
│ query_log_10 │ 2025-03-18 14:01:33 │
│ query_log_9  │ 2025-03-18 14:01:32 │
└──────────────┴─────────────────────┘

11 строк в наборе. Прошло: 0.373 сек. Обработано 6.44 миллиона строк, 25.77 МБ (17.29 миллиона строк/с, 69.17 МБ/с). Пиковое потребление памяти: 28.45 МиБ.


:::note[Не полагайтесь на числовой суффикс для упорядочивания]
Хотя числовой суффикс в таблицах может указывать на порядок данных, на него никогда не следует полагаться. По этой причине всегда используйте табличную функцию merge в сочетании с фильтром по дате при работе с конкретными диапазонами дат.
:::

Важно отметить, что эти таблицы по-прежнему являются **локальными для каждого узла**.

### Запросы к нескольким узлам                          \{#querying-across-nodes}

Для комплексного просмотра всего кластера пользователи могут использовать функцию [`clusterAllReplicas`](/sql-reference/table-functions/cluster) в сочетании с функцией `merge`. Функция `clusterAllReplicas` позволяет выполнять запросы к системным таблицам на всех репликах в кластере «default», объединяя данные отдельных узлов в единый результат. В сочетании с функцией `merge` это можно использовать для получения всех системных данных для конкретной таблицы в кластере. 

Этот подход особенно ценен для мониторинга и отладки операций на уровне кластера, позволяя пользователям эффективно анализировать работоспособность и производительность развертывания ClickHouse Cloud.

:::note
ClickHouse Cloud предоставляет кластеры с несколькими репликами для обеспечения избыточности и отказоустойчивости. Это обеспечивает такие возможности, как динамическое автомасштабирование и обновления без простоя. В определенный момент времени новые узлы могут находиться в процессе добавления в кластер или удаления из кластера. Чтобы пропустить эти узлы, добавьте `SETTINGS skip_unavailable_shards = 1` к запросам, использующим `clusterAllReplicas`, как показано ниже.
:::

Например, рассмотрим разницу при запросе к таблице `query_log` — часто необходимой для анализа.

```sql
SELECT
    hostname() AS host,
    count()
FROM system.query_log
WHERE (event_time >= '2025-04-01 00:00:00') AND (event_time <= '2025-04-12 00:00:00')
GROUP BY host

┌─host──────────────────────────┬─count()─┐
│ c-ecru-qn-34-server-s5bnysl-0 │  650543 │
└───────────────────────────────┴─────────┘

1 row in set. Elapsed: 0.010 sec. Processed 17.87 thousand rows, 71.51 KB (1.75 million rows/s., 7.01 MB/s.)

SELECT
    hostname() AS host,
    count()
FROM clusterAllReplicas('default', system.query_log)
WHERE (event_time >= '2025-04-01 00:00:00') AND (event_time <= '2025-04-12 00:00:00')
GROUP BY host SETTINGS skip_unavailable_shards = 1

┌─host──────────────────────────┬─count()─┐
│ c-ecru-qn-34-server-s5bnysl-0 │  650543 │
│ c-ecru-qn-34-server-6em4y4t-0 │  656029 │
│ c-ecru-qn-34-server-iejrkg0-0 │  641155 │
└───────────────────────────────┴─────────┘

3 rows in set. Elapsed: 0.026 sec. Processed 1.97 million rows, 7.88 MB (75.51 million rows/s., 302.05 MB/s.)

Запросы по узлам и версиям

Из‑за версионности системных таблиц это по‑прежнему не отражает все данные в кластере. Если совместить приведённое выше с функцией merge, мы получим точный результат для нашего диапазона дат:

SELECT
    hostname() AS host,
    count()
FROM clusterAllReplicas('default', merge('system', '^query_log'))
WHERE (event_time >= '2025-04-01 00:00:00') AND (event_time <= '2025-04-12 00:00:00')
GROUP BY host SETTINGS skip_unavailable_shards = 1

┌─host──────────────────────────┬─count()─┐
│ c-ecru-qn-34-server-s5bnysl-0 │ 3008000 │
│ c-ecru-qn-34-server-6em4y4t-0 │ 3659443 │
│ c-ecru-qn-34-server-iejrkg0-0 │ 1078287 │
└───────────────────────────────┴─────────┘

3 строки в наборе. Прошло: 0.462 сек. Обработано 7.94 млн строк, 31.75 MB (17.17 млн строк/с, 68.67 MB/s.)