시스템 테이블 개요

시스템 테이블 개요 (System tables overview)

시스템 테이블은 서버 상태, 프로세스, 환경, 서버의 내부 프로세스, 그리고 ClickHouse 바이너리가 빌드될 때 사용된 옵션 등에 대한 정보를 제공해요. 모든 시스템 테이블은 system 데이터베이스에 있으며 읽기 전용으로만 사용할 수 있어요. 대부분의 시스템 테이블은 데이터를 RAM에 저장하고, ClickHouse 서버가 시작될 때 생성돼요.

출처: 문서

본문

시스템 테이블은 다음에 대한 정보를 제공해요:

서버 상태, 프로세스, 환경.
서버의 내부 프로세스.
ClickHouse 바이너리가 빌드될 때 사용된 옵션.

시스템 테이블은:

system 데이터베이스에 위치해요.
데이터를 읽기 위해서만 사용할 수 있어요.
drop 하거나 alter 할 수 없고, 분리(detach)할 수만 있어요.

대부분의 시스템 테이블은 데이터를 RAM에 저장해요. 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: 데이터를 디스크로 flush하는 간격이에요.
engine: 파라미터가 있는 전체 엔진 표현식(ENGINE = 로 시작)을 제공해요. 이 옵션은 partition_by 및 ttl 과 충돌해요. 함께 설정하면 서버는 예외를 발생시키고 종료해요.

예:


    system
    query_log
    toYYYYMM(event_date)
    event_date + INTERVAL 30 DAY DELETE
    ENGINE = MergeTree PARTITION BY toYYYYMM(event_date) ORDER BY (event_date, event_time) SETTINGS index_granularity = 1024
    -->
    7500
    1048576
    8192
    524288
    false

기본적으로 테이블 성장에는 제한이 없어요. 테이블 크기를 제어하려면 TTL 설정을 사용하여 오래된 로그 레코드를 제거할 수 있어요. 또한 MergeTree 엔진 테이블의 파티셔닝 기능을 사용할 수 있어요.

시스템 메트릭의 소스

시스템 메트릭을 수집하기 위해 ClickHouse 서버는 다음을 사용해요:

CAP_NET_ADMIN capability.
procfs (Linux에서만).

procfs ClickHouse 서버에 CAP_NET_ADMIN capability가 없으면 ProcfsMetricsProvider 로 대체하려고 해요. ProcfsMetricsProvider 는 쿼리별 시스템 메트릭(CPU 및 I/O)을 수집할 수 있게 해줘요. procfs가 시스템에서 지원되고 활성화되어 있으면 ClickHouse 서버는 다음 메트릭을 수집해요:

OSCPUVirtualTimeMicroseconds
OSCPUWaitMicroseconds
OSIOWaitMicroseconds
OSReadChars
OSWriteChars
OSReadBytes
OSWriteBytes

OSIOWaitMicroseconds 는 5.14.x 버전부터 Linux 커널에서 기본적으로 비활성화돼요. 이것은 sudo sysctl kernel.task_delayacct=1 을 사용하거나 /etc/sysctl.d/ 에 kernel.task_delayacct = 1 이 있는 .conf 파일을 만들어 활성화할 수 있어요.

ClickHouse Cloud의 시스템 테이블

ClickHouse Cloud에서 시스템 테이블은 자체 관리(self-managed) 배포에서와 마찬가지로 서비스의 상태와 성능에 대한 중요한 통찰을 제공해요. 일부 시스템 테이블은 클러스터 수준에서 작동하는데, 특히 분산 메타데이터를 관리하는 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.

반대로 다른 시스템 테이블은 노드별(node-specific)이에요. 예를 들어 인메모리이거나 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 rows in set. Elapsed: 0.004 sec.

여러 버전 조회

이러한 테이블을 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 rows in set. Elapsed: 0.373 sec. Processed 6.44 million rows, 25.77 MB (17.29 million rows/s., 69.17 MB/s.)
Peak memory usage: 28.45 MiB.

순서를 위해 숫자 접미사에 의존하지 마세요 테이블의 숫자 접미사가 데이터의 순서를 암시할 수 있지만 절대 의존해서는 안 돼요. 이런 이유로 특정 날짜 범위를 대상으로 할 때는 항상 merge 테이블 함수를 날짜 필터와 함께 사용해요. 중요한 점은 이러한 테이블이 여전히 각 노드에 로컬이라는 거예요.

노드 간 조회

전체 클러스터를 포괄적으로 보려면 clusterAllReplicas 함수를 merge 함수와 함께 활용할 수 있어요. clusterAllReplicas 함수는 “default” 클러스터의 모든 복제본에서 시스템 테이블을 조회해 노드별 데이터를 통합된 결과로 합쳐 줘요. merge 함수와 결합하면 클러스터의 특정 테이블에 대한 모든 시스템 데이터를 대상으로 하는 데 사용할 수 있어요. 이 접근 방식은 클러스터 전체 작업을 모니터링하고 디버깅하는 데 특히 유용하며, 사용자가 ClickHouse Cloud 배포의 상태와 성능을 효과적으로 분석할 수 있게 해줘요. ClickHouse Cloud는 이중화와 장애 조치를 위해 여러 복제본의 클러스터를 제공해요. 이것은 동적 자동 확장과 무중단 업그레이드 같은 기능을 가능하게 해요. 특정 시점에 새 노드가 클러스터에 추가되거나 클러스터에서 제거되는 과정에 있을 수 있어요. 이러한 노드를 건너뛰려면 아래와 같이 clusterAllReplicas 를 사용하는 쿼리에 SETTINGS skip_unavailable_shards = 1 을 추가해요. 예를 들어 분석에 종종 필수적인 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-01 00:00:00') AND (event_time

노드 및 버전 간 조회

시스템 테이블 버전 관리 때문에 위의 결과는 여전히 클러스터의 전체 데이터를 나타내지 않아요. 위와 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

시스템 테이블 개요