Dictionary Source — 어디서 데이터를 가져와 그 조회 테이블을 채우는가
ClickHouse system.mutations 및 Dictionary Source 종류 공식 문서 종합 (웹 리서치, 2026) — ClickHouse 공식 문서(operations/system-tables/mutations, sql-reference/statements/create/dictionary/sources) ClickHouse 공식문서 Dictionary Sources
이 모듈을 다 읽으면
- clickhouse-learn-15에서 다룬 dictGet·레이아웃이 '조회 방식'이었다면, source는 '데이터 원천'이라는 별개의 축임을 설명할 수 있다
- Executable 소스가 다른 소스들과 근본적으로 다른 방식(STDIN/STDOUT)으로 데이터를 주고받는다는 것을 설명할 수 있다
clickhouse-learn-15에서 다룬 Dictionary(FLAT/HASHED/CACHE 레이아웃, LIFETIME 갱신)를 전제로, 그 Dictionary가 애초에 어디서 데이터를 가져오는지를 결정하는 source 종류를 정리한다.
다양한 소스 종류 — 로컬 파일부터 외부 DBMS까지
Dictionary는 로컬 파일(텍스트 또는 실행 파일), HTTP(S) 리소스, 또는 다른 DBMS(MySQL, PostgreSQL, ClickHouse 자체 테이블, MongoDB, Redis, Cassandra, ODBC/JDBC 브리지 등)를 소스로 쓸 수 있다 — clickhouse-learn-15가 '이 데이터를 어떻게 빠르게 조회할지'(레이아웃)를 다뤘다면, source는 '그 데이터를 애초에 어디서 채워 넣을지'를 결정하는 완전히 별개의 축이다. 실무에서 가장 자주 쓰이는 것은 MySQL과 PostgreSQL 테이블이다.
핵심 포인트
- 지원 소스: 로컬 파일/HTTP(S)/MySQL·PostgreSQL·ClickHouse 등 DBMS/MongoDB/Redis/Cassandra/ODBC-JDBC 브리지 등
- clickhouse-learn-15의 레이아웃('어떻게 조회할지')과 source('어디서 채울지')는 서로 독립적인 축 — 실무에서는 MySQL·PostgreSQL이 가장 흔함
Executable 소스 — 외부 프로그램을 STDIN/STDOUT으로 호출한다
Executable 소스는 다른 소스들과 근본적으로 다른 방식으로 동작한다 — DB 커넥션을 맺는 대신, 외부 실행 파일을 하나 호출해 데이터를 주고받는다. 특히 cache/complex_key_cache 레이아웃과 함께 쓸 때는, ClickHouse가 필요한 키들을 그 실행 파일의 STDIN으로 보내 요청하고, 결과를 STDOUT으로 받는 방식이다 — 즉 표준 DB 프로토콜이 아니라 프로세스 파이프를 통신 채널로 쓰는 셈이다. 이 방식은 표준 DBMS 커넥터로 접근 못 하는 임의의 데이터 원천(사내 커스텀 API, 특수 파일 포맷 등)을 Dictionary로 끌어올 때 쓰인다.
핵심 포인트
- Executable 소스: DB 커넥션이 아니라 외부 실행 파일을 호출해 STDIN(키 전달)/STDOUT(결과 수신)으로 통신
- 표준 DBMS 커넥터로 접근 못 하는 임의의 데이터 원천(사내 커스텀 API 등)을 Dictionary로 끌어올 때 사용