PostgreSQL과의 차이점#

소개 페이지는 ClickHouse를 개괄적으로 파악하기에 좋습니다.

ClickHouse는 PostgreSQL 같은 전통적인 OLTP(online transaction processing) 데이터베이스와 여러 면에서 다릅니다. 기반 아키텍처가 다소 다르고, 처리 과정이 전통적인 데이터베이스보다 CPU에 훨씬 많이 의존합니다. ClickHouse는 불변성을 핵심 요소로 삼는 로그 중심 데이터베이스입니다. 이런 접근 방식의 장점은 잘 정리되어 있으며, 자세한 내용은 The rise of immutable data stores를 참고합니다. 다만 그만큼 업데이트는 훨씬 어렵습니다. UPDATE/DELETE를 지원하는 작업은 ClickHouse 문서를 참고합니다. 이런 작업은 자주 수행하지 않는 것을 전제로 한다는 점이 눈에 띕니다.

이 차이는 테이블을 설계할 때 중요합니다. 다음 둘 중 하나여야 합니다.

• 업데이트가 필요하지 않습니다(가장 좋은 경우)
• 업데이트가 필요하더라도 쿼리 실행 중에는 수행하지 않습니다.

ACID 호환성#

ClickHouse의 트랜잭션 지원은 조금 다릅니다. 보장 범위는 특정 테이블에 삽입된 데이터 블록 단위까지만 적용됩니다. 자세한 내용은 Transactional (ACID) support 문서를 참고합니다.

여러 테이블에 걸친 트랜잭션 지원은 구체화 뷰에서만 다루어지므로, 한 번의 쓰기에서 여러 건을 삽입하는 방식은 피합니다.

ClickHouse는 분석 쿼리를 최고 수준으로 지원하는 데 크게 치우쳐 있습니다. 집계 같은 작업이 매우 빠르고, 이 역량을 보강하는 기능도 여럿 제공합니다. ClickHouse는 집계의 세부 동작을 다루는 좋은 블로그 글도 제공합니다.

기본 인덱스, 정렬 인덱스, 딕셔너리#

ClickHouse의 인덱스를 이해하려면 "A practical introduction to primary indexes in ClickHouse"를 읽어 보기를 권장합니다.

특히 ClickHouse의 데이터베이스 인덱스 설계가 PostgreSQL 같은 트랜잭션 데이터베이스와 어떻게 다른지 확인합니다.

기본 인덱스 설계는 쿼리 성능에 매우 큰 영향을 주므로 신중하게 정해야 합니다. 전체 데이터 스캔은 시간이 오래 걸릴 수밖에 없으므로 거의 모든 쿼리가 기본 인덱스에 의존해야 합니다.

MergeTree 테이블 엔진(ClickHouse의 기본 테이블 엔진)에서 인덱스가 쿼리 성능에 어떤 영향을 주는지는 primary keys and indexes in queries 문서를 참고합니다.

ClickHouse의 보조 인덱스는 다른 시스템의 보조 인덱스와 다릅니다. 데이터 블록을 건너뛰는 데 쓰이므로 데이터 스키핑 인덱스라고도 합니다. data-skipping indexes 문서를 참고합니다.

ClickHouse는 외부 인덱스로 사용할 수 있는 "딕셔너리"도 제공합니다. 딕셔너리는 메모리에서 로드되며 쿼리 실행 시점에 값을 조회하는 데 사용할 수 있습니다.

데이터 유형과 파티셔닝#

ClickHouse는 SQL 호환 데이터 유형과 함께 다음과 같은 몇 가지 특수 데이터 유형을 제공합니다.

• LowCardinality
• UUID
• Maps
• Nested. 칼럼 안에 테이블을 두는 형태를 흉내 낸다는 점이 특징입니다.

테이블을 설계할 때 가장 먼저 마주하는 핵심 설계 요소는 파티셔닝 키입니다. 파티션은 임의의 식으로 정할 수 있지만 보통은 월, 일, 주 같은 기간을 사용합니다. ClickHouse는 가장 작은 파티션 집합을 사용해 읽는 데이터를 최소화하는 방식을 최대한 적용합니다.

참고 자료:

• Choose a low cardinality partitioning key
• Custom partitioning key.

샤딩과 복제#

샤딩은 데이터를 여러 ClickHouse 노드로 나누어 처리량을 높이고 지연 시간을 줄이는 기능입니다. 샤딩 기능은 로컬 테이블을 기반으로 하는 분산 엔진을 사용합니다. 분산 엔진은 데이터를 저장하지 않는 "가상" 테이블이며, 데이터를 삽입하고 조회하는 인터페이스로 사용합니다.

ClickHouse 문서와 복제 및 샤딩 절을 참고합니다. ClickHouse는 합의를 유지하기 위해 Zookeeper를 사용하거나, ClickHouse Keeper라는 자체 호환 API 컴포넌트를 사용할 수 있습니다.

노드를 구성한 뒤에는 클라이언트에서 노드가 보이지 않게 되며, 쓰기와 읽기 쿼리를 어느 노드로든 보낼 수 있습니다.

대부분의 경우 클러스터는 고정된 수의 노드(샤드)로 시작합니다. 샤드 재분배는 운영 부담이 크고 철저한 테스트가 필요합니다.

복제는 MergeTree 테이블 엔진에서 지원하며, 정의 방법은 문서의 복제 절을 참고합니다. ClickHouse는 쿼럼에 참여하는 노드를 추적하기 위해 분산 조정 컴포넌트(Zookeeper 또는 ClickHouse Keeper)에 의존합니다. 복제는 비동기이며 다중 리더 방식입니다. 삽입은 어느 노드로든 보낼 수 있고, 다른 노드에는 약간의 지연을 두고 반영됩니다. 필요하다면 특정 노드에 고정하는 방식으로 읽기가 가장 최근에 기록된 데이터를 보도록 할 수 있습니다.

구체화 뷰#

ClickHouse를 특징짓는 기능 중 하나가 구체화 뷰입니다. 기능상으로는 ClickHouse의 삽입 트리거에 가깝습니다.

동작 방식을 더 잘 이해하려면 공식 문서의 뷰 절을 읽어 보기를 권장합니다.

문서에서 인용합니다.

ClickHouse의 구체화 뷰는 삽입 트리거에 가깝게 구현되어 있습니다. 뷰 쿼리에 집계가 있으면 새로 삽입된 데이터 배치에만 적용됩니다. 원본 테이블의 기존 데이터에 대한 변경(업데이트, 삭제, 파티션 드롭 등)은 구체화 뷰에 반영되지 않습니다.

안전하고 합리적인 기본값#

ClickHouse 인스턴스는 다음 보안 권장 사항을 따라야 합니다.

사용자#

파일: users.xml, config.xml.

네트워크#

파일: config.xml

스토리지#

로깅#

마스킹 규칙 예시#

<query_masking_rules>
    <rule>
        <name>hide SSN</name>
        <regexp>(^|\D)\d{3}-\d{2}-\d{4}($|\D)</regexp>
        <replace>000-00-0000</replace>
    </rule>
    <rule>
        <name>hide encrypt/decrypt arguments</name>
        <regexp>
           ((?:aes_)?(?:encrypt|decrypt)(?:_mysql)?)\s*\(\s*(?:'(?:\\'|.)+'|.*?)\s*\)
        </regexp>
        <replace>\1(???)</replace>
    </rule>
</query_masking_rules>