Перейти к основному содержимому
Перейти к основному содержимому

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

Введение​

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

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

Пример:

По умолчанию рост таблицы не ограничен. Для контроля размера таблицы можно использовать настройки 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 должны быть согласованными независимо от узла, с которого они запрашиваются:

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

Чтобы всесторонне просмотреть весь кластер, пользователи могут воспользоваться функцией clusterAllReplicas. Эта функция позволяет запрашивать системные таблицы по всем репликам внутри "дефолтного" кластера, объединяя данные, специфичные для узла, в единый результат. Этот подход особенно полезен для мониторинга и отладки операций на уровне всего кластера, обеспечивая пользователей возможностью эффективно анализировать состояние и производительность развертывания ClickHouse Cloud.

примечание

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

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

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

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

Связанный контент​