• PostgreSQL과의 차이점
• ACID 호환성
• 기본 인덱스, 정렬 인덱스 및 사전
• 데이터 유형 및 파티셔닝
• 샤딩 및 복제
• 머터리얼된 뷰
• 안전하고 합리적인 기본 설정
  • 사용자
  • 네트워크
  • 리포지터리
  • 로깅
    • 예시 마스킹 규칙

ClickHouse 사용 및 테이블 디자인 소개

PostgreSQL과의 차이점

이 페이지는 ClickHouse 개요를 잘 소개합니다.

ClickHouse는 PostgreSQL과 같은 전통적인 OLTP(온라인 트랜잭션 처리) 데이터베이스와 많이 다릅니다. 기본 아키텍처가 약간 다르고, 처리가 전통적인 데이터베이스보다 훨씬 더 CPU 중심입니다. ClickHouse는 불변성이 핵심 요소인 로그 중심 데이터베이스입니다. 이러한 방식의 장점은 잘 문서화되어 있지만, 업데이트를 훨씬 어렵게 만듭니다. UPDATE/DELETE 지원을 제공하는 작업은 ClickHouse 문서에서 확인할 수 있습니다. 이러한 작업은 비자주적이어야 한다는 점에 유의해야 합니다.

이 차이는 테이블을 디자인하는 동안 중요합니다. 다음 중 하나일 수 있습니다:

• 업데이트가 필요하지 않음(최상의 경우)
• 필요한 경우에도 쿼리 실행 중에 실행되지 않습니다.

ACID 호환성

ClickHouse는 트랜잭션 지원에 대한 조금 다른 개요가 있으며, 여기서 보증은 특정 테이블에 삽입된 데이터 블록까지만 적용됩니다. 상세 내용은 트랜잭션(ACID) 지원 문서를 참조하세요.

단일 쓰기에서 여러 삽입을 피해야 하며, 여러 테이블 간의 트랜잭션 지원은 머터리얼라이즈된 뷰에서만 지원됩니다.

ClickHouse는 분석 쿼리에 최고의 지원을 제공하기 위해 많은 노력을 기울이고 있습니다. 집계와 같은 작업은 매우 빠르며, 이러한 기능을 강화하는 몇 가지 기능이 있습니다. ClickHouse에는 집계에 대한 자세한 내용을 다룬 좋은 블로그 포스트가 있습니다.

기본 인덱스, 정렬 인덱스 및 사전

ClickHouse에서 인덱스에 대한 이해를 얻기 위해 “ClickHouse의 기본 인덱스에 대한 실용적인 소개”를 읽는 것이 매우 권장됩니다.

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

주요 인덱스 디자인은 쿼리 성능에 매우 중요한 역할을 하며 신중히 명시되어야 합니다. 대부분의 쿼리는 전체 데이터 스캔이 더 오래 걸리기 때문에 주요 인덱스에 의존해야 합니다.

MergeTree 테이블 엔진(ClickHouse의 기본 테이블 엔진)에서 인덱스가 쿼리 성능에 어떻게 영향을 주는지에 대한 자세한 내용은 쿼리에서 기본 키 및 인덱스를 확인하는 문서를 읽으세요.

ClickHouse의 보조 인덱스는 다른 시스템에서 제공되는 것과 다릅니다. 데이터 스킵 인덱스라고도 불리며, 데이터 블록을 건너뛸 때 사용됩니다. 데이터 스킵 인덱스에 대한 문서를 참조하세요.

또한 ClickHouse는 사전을 제공하며, 이는 외부 인덱스로 사용될 수 있습니다. 사전은 메모리에서 로드되어 쿼리 실행 중에 값 조회에 사용할 수 있습니다.

데이터 유형 및 파티셔닝

ClickHouse는 SQL 호환 데이터 유형과 LowCardinality, UUID, Map, Nested과 같은 몇 가지 특수한 데이터 유형을 제공합니다. Nested는 컬럼 내에 테이블을 시뮬레이트하기 때문에 흥미롭습니다.

테이블을 디자인하는 동안 가장 먼저 언급되는 핵심 디자인 측면은 파티션 키입니다. 파티션은 월, 일 또는 주와 같이 시간 기간과 같은 임의의 표현일 수 있지만, ClickHouse는 가장 작은 파티션 집합을 사용하여 데이터를 읽는 것을 최소화하기 위해 최선을 다합니다.

권장 도서:

• Low Cardinality 파티션 키 선택
• 사용자 정의 파티션 키.

샤딩 및 복제

샤딩은 데이터를 여러 개의 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>주민등록번호 숨기기</name>
        <regexp>(^|\D)\d{3}-\d{2}-\d{4}($|\D)</regexp>
        <replace>000-00-0000</replace>
    </rule>
    <rule>
        <name>암호화/복호화 인수 숨기기</name>
        <regexp>
           ((?:aes_)?(?:encrypt|decrypt)(?:_mysql)?)\s*\(\s*(?:'(?:\\'|.)+'|.*?)\s*\)
        </regexp>
        <replace>\1(???)</replace>
    </rule>
</query_masking_rules>