메인 콘텐츠로 건너뛰기

연결 설정

기본값, DSN 매개변수, 모범 사례, 문제 해결을 포함해 각 옵션을 자세히 확인하려면 구성 참고를 참조하십시오.
연결을 열 때 Options 구조체를 사용해 클라이언트 동작을 제어할 수 있습니다. 사용할 수 있는 설정은 다음과 같습니다.
전체 예시

TLS

하위 수준에서는 모든 클라이언트 연결 메서드(DSN/OpenDB/Open)가 보안 연결을 설정하기 위해 Go tls 패키지를 사용합니다. Options 구조체에 nil이 아닌 tls.Config 포인터가 포함되어 있으면 클라이언트는 TLS를 사용해야 함을 인식합니다.
전체 예시 이 간단한 TLS.Config만으로도 일반적으로 ClickHouse 서버의 보안 네이티브 포트(보통 9440)에 연결하기에 충분합니다. ClickHouse 서버에 유효한 인증서가 없는 경우(인증서가 만료되었거나, 호스트명이 일치하지 않거나, 공개적으로 신뢰되는 루트 인증 기관에서 서명되지 않은 경우) InsecureSkipVerify를 true로 설정할 수는 있지만, 이는 강력히 권장되지 않습니다.
전체 예시 추가 TLS 매개변수가 필요하면 애플리케이션 코드에서 tls.Config 구조체의 원하는 필드를 설정해야 합니다. 여기에는 특정 암호 스위트 지정, 특정 TLS 버전(예: 1.2 또는 1.3) 사용 강제, 내부 CA 인증서 체인 추가, ClickHouse 서버에서 요구하는 경우 클라이언트 인증서(및 개인 키) 추가, 그리고 보다 특수한 보안 구성에 필요한 대부분의 다른 옵션이 포함될 수 있습니다.

인증

username과 password를 지정하려면 연결 정보에 Auth 구조체를 지정합니다.
전체 예시

여러 노드에 연결하기

여러 주소는 Addr 구조체를 통해 지정할 수 있습니다.
전체 예시 사용 가능한 연결 전략은 3가지입니다:
  • ConnOpenInOrder (기본값) - 주소를 정의된 순서대로 사용합니다. 목록 앞부분의 주소로 연결하지 못한 경우에만 뒤의 주소를 사용합니다. 사실상 장애 조치(failover) 전략입니다.
  • ConnOpenRoundRobin - 라운드 로빈 전략으로 각 주소에 부하를 분산합니다.
  • ConnOpenRandom - 주소 목록에서 임의로 노드를 선택합니다.
이는 ConnOpenStrategy 옵션으로 제어할 수 있습니다.
전체 예시

연결 풀링

클라이언트는 연결 풀을 유지하며, 필요에 따라 쿼리 전반에서 이를 재사용합니다. 어느 시점에서든 최대 MaxOpenConns개까지 사용되며, 최대 풀 크기는 MaxIdleConns로 제어됩니다. 클라이언트는 각 쿼리를 실행할 때마다 풀에서 연결을 가져오고, 재사용할 수 있도록 다시 풀에 반환합니다. 연결은 배치(Batch)가 유지되는 동안 사용되며 Send() 시 해제됩니다. 사용자가 MaxOpenConns=1로 설정하지 않는 한, 풀 내에서 동일한 연결이 후속 쿼리에도 사용된다고 보장할 수는 없습니다. 이런 설정이 필요한 경우는 드물지만, 임시 테이블(temporary table)을 사용하는 경우에는 필요할 수 있습니다. 또한 ConnMaxLifetime의 기본값은 1시간입니다. 이로 인해 노드가 cluster를 이탈하면 ClickHouse에 대한 부하가 불균형해질 수 있습니다. 이는 특정 노드를 사용할 수 없게 되면 연결이 다른 노드로 분산되기 때문에 발생할 수 있습니다. 이렇게 분산된 연결은 문제가 있던 노드가 cluster에 다시 합류하더라도 기본적으로 1시간 동안 유지되며 갱신되지 않습니다. workload가 많은 경우에는 이 값을 낮추는 것이 좋습니다. 연결 풀링은 네이티브(TCP) 및 HTTP 프로토콜 모두에서 활성화됩니다.

로깅

클라이언트는 OptionsLogger 필드를 사용해 Go의 표준 log/slog 패키지로 구조화된 로깅을 지원합니다. 기존 DebugDebugf 필드는 사용 중단 예정(deprecated)이지만, 하위 호환성을 위해 계속 동작합니다(우선순위: Debugf > Logger > no-op).
애플리케이션 수준의 컨텍스트를 추가해 로거를 보강할 수도 있습니다:
전체 예시

압축

압축 메서드 지원은 사용 중인 하위 프로토콜에 따라 달라집니다. 네이티브 프로토콜의 경우 클라이언트는 LZ4ZSTD 압축을 지원합니다. 이는 블록 수준에서만 수행됩니다. 연결에 Compression 구성을 포함하면 압축을 활성화할 수 있습니다.
전체 예시 HTTP 전송에서는 gzip, deflate, br와 같은 추가 압축 기법도 사용할 수 있습니다. 자세한 내용은 Database/SQL API - 압축을 참조하십시오.

TCP vs HTTP

전송 방식은 구성 스위치 하나로만 전환되며, 이 가이드의 나머지 내용은 두 방식에 모두 동일하게 적용됩니다. 달라지는 점은 다음과 같습니다: 각 API를 HTTP로 전환하려면:
마지막 수정일 2026년 7월 2일