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

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

• Состоянии сервера, процессах и окружении.
• Внутренних процессах сервера.
• Параметрах, использованных при сборке бинарного файла 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 использует:

• capability CAP_NET_ADMIN.
• procfs (только в Linux).

procfs

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

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

• OSCPUVirtualTimeMicroseconds
• OSCPUWaitMicroseconds
• OSIOWaitMicroseconds
• OSReadChars
• OSWriteChars
• OSReadBytes
• OSWriteBytes

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

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

┌

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

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

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

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

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

SHOW TABLES FROM system LIKE 'query_log%'

┌

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

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

┌

Важно: эти таблицы по-прежнему локальны для каждого узла.

Чтобы получить полное представление обо всём кластере, можно использовать функцию clusterAllReplicas в сочетании с функцией merge. Функция clusterAllReplicas позволяет выполнять запросы к системным таблицам на всех репликах в кластере "default", объединяя данные отдельных узлов в единый результат. В сочетании с функцией merge это позволяет обращаться ко всем системным данным для конкретной таблицы в кластере.

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

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

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

┌

Из-за версионирования системных таблиц это по-прежнему не отражает все данные в кластере. Если дополнить это функцией 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

┌

• Блог: Системные таблицы и взгляд на внутренние компоненты ClickHouse
• Блог: Ключевые запросы для мониторинга — часть 1 — запросы INSERT
• Блог: Ключевые запросы для мониторинга — часть 2 — запросы SELECT