PostgreSQL과의 차이점#

소개 페이지는 ClickHouse에 대한 개요를 파악하기에 매우 유용합니다.

ClickHouse는 PostgreSQL과 같은 전통적인 OLTP(온라인 트랜잭션 처리) 데이터베이스와 많은 차이점이 있습니다. 기반 아키텍처가 다소 다르며, 처리 방식이 전통적인 데이터베이스보다 훨씬 더 CPU 집약적입니다. ClickHouse는 불변성(immutability)이 핵심 구성 요소인 로그 중심 데이터베이스입니다. 이러한 접근 방식의 장점은 잘 문서화되어 있습니다. 자세한 내용은 불변 데이터 저장소의 부상을 참조하세요. 그러나 이로 인해 업데이트가 훨씬 어려워집니다. UPDATE/DELETE 지원을 제공하는 작업에 대해서는 ClickHouse 문서를 참조하세요. 이러한 작업은 자주 실행되지 않아야 한다는 점이 주목할 만합니다.

이 점은 테이블을 설계할 때 중요하게 고려해야 합니다. 다음 두 가지 경우 중 하나입니다:

• 업데이트가 필요하지 않음 (최선의 경우)

• 업데이트가 필요한 경우, 쿼리 실행 중에 실행해서는 안 됨

ACID 호환성#

ClickHouse는 트랜잭션 지원에 대해 다소 다른 관점을 가지고 있으며, 특정 테이블에 삽입된 데이터 블록까지만 보장이 적용됩니다. 자세한 내용은 트랜잭션(ACID) 지원 문서를 참조하세요.

여러 테이블에 걸친 트랜잭션 지원은 구체화된 뷰(materialized views)에서만 지원되므로, 단일 쓰기 작업에서 여러 삽입을 수행하는 것은 피해야 합니다.

ClickHouse는 분석 쿼리를 위한 최고 수준의 지원을 제공하는 데 특화되어 있습니다. 집계(aggregation)와 같은 연산은 매우 빠르며, 이러한 기능을 강화하는 여러 가지 특징이 있습니다. ClickHouse에는 집계의 세부 사항을 다루는 유용한 블로그 게시물이 있습니다.

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

ClickHouse에서 인덱스를 이해하려면 “ClickHouse 기본 인덱스의 실용적인 소개”를 읽어보는 것이 강력히 권장됩니다.

특히 ClickHouse의 데이터베이스 인덱스 설계가 PostgreSQL과 같은 트랜잭션 데이터베이스의 인덱스와 어떻게 다른지에 주목하세요.

기본 인덱스 설계는 쿼리 성능에 매우 중요한 역할을 하므로 신중하게 설정해야 합니다. 전체 데이터 스캔은 더 오래 걸리기 때문에, 거의 모든 쿼리가 기본 인덱스에 의존해야 합니다.

MergeTree 테이블 엔진(ClickHouse의 기본 테이블 엔진)에서 인덱스가 쿼리 성능에 미치는 영향을 알아보려면 쿼리의 기본 키 및 인덱스 문서를 읽어보세요.

ClickHouse의 보조 인덱스는 다른 시스템에서 제공되는 것과 다릅니다. 데이터 블록을 건너뛰는 데 사용되므로 데이터 스킵 인덱스(data-skipping indexes)라고도 불립니다. 데이터 스킵 인덱스 문서를 참조하세요.

ClickHouse는 외부 인덱스로 사용할 수 있는 “딕셔너리(Dictionaries)”도 제공합니다. 딕셔너리는 메모리에서 로드되며 쿼리 런타임에 값을 조회하는 데 사용할 수 있습니다.

데이터 타입 및 파티셔닝#

ClickHouse는 SQL 호환 데이터 타입과 다음과 같은 몇 가지 특수 데이터 타입을 제공합니다:

• LowCardinality

• UUID

• Maps

• Nested — 칼럼 내에 테이블을 시뮬레이션하므로 흥미롭습니다.

테이블을 설계할 때 가장 먼저 고려해야 할 핵심 설계 요소는 파티셔닝 키입니다. 파티션은 임의의 표현식일 수 있지만, 일반적으로 월, 일 또는 주와 같은 시간 단위를 사용합니다. ClickHouse는 가장 적은 수의 파티션 집합을 사용하여 읽는 데이터를 최소화하는 최선의 방식을 취합니다.

추천 읽기 자료:

• 낮은 카디널리티 파티셔닝 키 선택

• 사용자 정의 파티셔닝 키

샤딩 및 복제#

샤딩은 처리량을 늘리고 지연 시간을 줄이기 위해 데이터를 여러 ClickHouse 노드에 분산시키는 기능입니다. 샤딩 기능은 로컬 테이블을 기반으로 하는 분산 엔진을 사용합니다. 분산 엔진은 데이터를 저장하지 않는 “가상” 테이블입니다. 데이터를 삽입하고 쿼리하기 위한 인터페이스로 사용됩니다.

ClickHouse 문서와 복제 및 샤딩 섹션을 참조하세요. ClickHouse는 합의를 유지하기 위해 Zookeeper 또는 ClickHouse Keeper라는 컴포넌트를 통한 자체 호환 API를 사용할 수 있습니다.

노드가 설정된 후에는 클라이언트에서 보이지 않게 되며, 쓰기 및 읽기 쿼리 모두 어느 노드에서나 실행할 수 있습니다.

대부분의 경우, 클러스터는 보통 고정된 수의 노드(약 샤드 수)로 시작합니다. 샤드 재조정은 운영 비용이 많이 들며 엄격한 테스트가 필요합니다.

복제는 MergeTree 테이블 엔진에서 지원됩니다. 복제를 정의하는 방법에 대한 자세한 내용은 문서의 복제 섹션을 참조하세요. ClickHouse는 쿼럼에 참여하는 노드를 추적하기 위해 분산 조정 컴포넌트(Zookeeper 또는 ClickHouse Keeper)에 의존합니다. 복제는 비동기적이며 다중 리더 방식입니다. 삽입은 어느 노드에서나 실행할 수 있으며, 약간의 지연 시간이 지나면 다른 노드에서도 나타납니다. 원하는 경우, 특정 노드에 고정(stickiness)하여 읽기 작업이 최신 쓰기 데이터를 반영하도록 할 수 있습니다.

구체화된 뷰#

ClickHouse의 대표적인 기능 중 하나는 구체화된 뷰(materialized views)입니다. 기능적으로는 ClickHouse의 삽입 트리거와 유사합니다.

작동 방식을 더 잘 이해하기 위해 공식 문서의 views 섹션을 읽어보는 것을 권장합니다.

문서를 인용하면:

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>