메인 콘텐츠로 건너뛰기
검토를 위해 제출하기 전에 ClickHouse의 두 가지 배포 모드와, ClickHouse의 타입 시스템을 의미 있는 규모로 충분히 검증할 수 있는 데이터셋을 모두 대상으로 통합을 검증하십시오. 이 페이지에서는 초기 수준에서 “테스트됨”이 무엇을 의미하는지 정의합니다. 정식 검증은 더 높은 파트너십 등급으로 나아가는 파트너를 위한 별도의 절차입니다. 수집 및 활용 경로는 통합 빌드하기를, 결과 게시 방법은 통합 문서화하기를 참조하십시오.

테스트 매트릭스

두 배포 모드를 모두 포함하십시오. 대부분의 고객은 둘 중 하나만 사용하며, 일부 영역에서는 동작이 다릅니다(인증, 네트워킹, 사용 가능한 기능).
  • ClickHouse Cloud: 무료 체험에 가입하십시오. 개발 tier는 신용카드 없이 사용할 수 있습니다
  • 자체 호스팅(오픈 소스): GitHub releases에서 최신 안정 릴리스를 사용하십시오. 설치 가이드는 Docker로 로컬 인스턴스를 가장 빠르게 준비하는 방법입니다
두 환경 모두에서 테스트하고, 통합 페이지에 기능 차이를 문서화하십시오.

무엇을 테스트해야 하는가

기능적 정확성. 통합에서 제공하는 모든 코드 경로를 점검하십시오. 수집, 쿼리, 스키마 디스커버리, 오류 처리, 재연결을 모두 테스트해야 합니다. 제품이 최종 사용자에게 SQL을 노출한다면, UI가 생성한 쿼리가 왕복 과정에서 문제없이 처리되는지 확인하십시오. 타입 시스템 범위. ClickHouse는 배열, 튜플, 맵, JSON, nested, LowCardinality, Decimal, Date 및 DateTime 변형, UUID, IPv4 및 IPv6, enum, 집계 함수 타입을 지원합니다. 통합에서는 중첩 배열, 깊게 중첩된 튜플, JSON 컬럼에서 문제가 자주 발생합니다. 클라이언트 라이브러리와 UI는 이를 안정적으로 처리해야 하며, 최소한 조용히 잘리거나 잘못 렌더링되는 대신 이해하기 쉬운 오류를 반환해야 합니다. 규모. 고객이 실제로 실행할 결과 집합 크기와 행 수를 기준으로 테스트하십시오. 사용자 대상 BI에서는 보통 수억~수십억 행 규모의 테이블과, 단일 집계 결과부터 수만 행에 이르는 결과 집합을 의미합니다. 범위를 제한하지 않은 읽기(SELECT *)는 멈춰서는 안 되며, 예측 가능하게 실패하거나 페이지네이션되어야 합니다. 인증. TLS가 활성화된 연결을 최소 1개 이상 검증하십시오. 인증 구성을 제공한다면 문서화한 모든 모드를 테스트하십시오(TLS를 통한 username 및 password, mTLS, SSL 클라이언트 인증서). 연결 수명 주기. 연결 끊김, 서버 재시작, 느린 쿼리 상황에서 동작이 합리적인지 확인하십시오. 에스컬레이션 사례 상당수는 쿼리 의미론보다 연결 처리 문제에서 비롯됩니다. 전체 목록은 예시 데이터셋 섹션에서 확인할 수 있습니다. 다음 4개의 데이터셋은 대부분의 통합 테스트 요구를 충족합니다:
  • GitHub 이벤트: 중첩된 이벤트 payload를 포함한 31억 개의 행. 배열, 튜플, 중첩 타입 테스트에 가장 적합합니다
  • NYC 택시 데이터: 널리 알려진 스키마를 갖춘 수십억 개의 행. 처리량 및 읽기 경로 테스트에 적합합니다
  • Stack Overflow: JOIN이 많은 BI 시나리오에 적합한 다중 테이블 관계형 데이터
  • Hacker News: 2,800만 개의 행으로 구성되어 있으며 빠르게 로드할 수 있어 반복 작업에 유용합니다
초대규모 검증에는 WikiStat(~5,000억 개의 레코드)를 사용하십시오.

테스트에서 수집할 항목

통합을 검토용으로 제출할 때는 다음 내용을 공유하십시오:
  • 테스트한 ClickHouse 버전(Cloud 및 오픈 소스)
  • 데이터셋과 대략적인 규모(행 수, 디스크 사용량)
  • 통합이 처리하는 타입과 처리하지 않는 타입(문서의 Known limits 섹션으로 사용됩니다)
  • 동작이 달라지는 결과 집합 임계값처럼, 미리 알려둘 필요가 있는 성능 특성
짧은 테스트 보고서는 검토 과정을 줄여 줍니다. 문단 하나와 표 하나면 충분합니다.
마지막 수정일 2026년 6월 10일