HTTP vs Native 인터페이스 — 같은 서버, 두 개의 서로 다른 문
ClickHouse Refreshable Materialized View 및 HTTP/Native 인터페이스 공식 문서 종합 (웹 리서치, 2026) — ClickHouse 공식 문서(concepts/features/materialized-views/refreshable-materialized-view, interfaces/tcp) ClickHouse 공식문서 Native interface (TCP)
이 모듈을 다 읽으면
- HTTP(8123)와 Native(9000) 인터페이스가 각각 어떤 트레이드오프를 갖는지 설명할 수 있다
- clickhouse-client와 Distributed 테이블 엔진이 왜 Native 프로토콜을 쓰는지 설명할 수 있다
ClickHouse 서버 하나가 실제로는 두 가지 서로 다른 통신 채널(HTTP·Native)을 동시에 노출한다는 것을 전제로, 각각의 트레이드오프와 어떤 상황에 어느 쪽이 쓰이는지를 정리한다.
Native(9000) — 낮은 오버헤드, 높은 처리량, 서버 간 통신의 기본값
Native 프로토콜(포트 9000)은 커스텀 이진 포맷이라 텍스트 인코딩 대비 오버헤드가 낮고, 큰 결과 집합에서 처리량이 높다. 설정 가능한 옵션도 더 다양하고, 서버가 진행 상황을 클라이언트로 능동적으로 밀어보내는(server-push) 것도 지원한다. clickhouse-client(표준 커맨드라인 클라이언트)가 이 프로토콜을 쓰고, clickhouse-learn-06에서 다룬 Distributed 테이블 엔진도 서브쿼리를 하위 테이블로 보낼 때 이 Native TCP/IP 프로토콜을 쓴다 — 즉 서버 간(server-to-server) 통신이나 성능이 중요한 상황에서는 Native가 기본값이다.
핵심 포인트
- Native(9000): 이진 포맷이라 오버헤드 낮음, 처리량 높음, 설정 옵션 다양, server-push 진행상황 알림 지원
- clickhouse-client와 clickhouse-learn-06의 Distributed 테이블 엔진(서브쿼리 전달)이 사용 — 서버 간 통신·성능 중요 상황의 기본값
HTTP(8123) — 어디서든 되지만 조금 더 제한적
HTTP 인터페이스(포트 8123)는 어떤 플랫폼·프로그래밍 언어에서도 그냥 HTTP 요청으로 ClickHouse를 쓸 수 있게 해준다 — curl로 쿼리를 보내는 것도 이 포트를 쓴다. Native보다는 기능이 조금 더 제한적이지만, 호환성이 훨씬 좋다는 게 장점이다 — 별도 드라이버·프로토콜 구현 없이 어떤 HTTP 클라이언트로도 바로 접근할 수 있기 때문이다.
핵심 포인트
- HTTP(8123): 어떤 플랫폼·언어에서도 HTTP 요청만으로 접근 가능(curl 등) — Native보다 기능은 제한적이지만 호환성이 훨씬 좋음