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

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

PostgreSQL과의 차이점

이 문서는 ClickHouse를 개요로 제공하는 데 상당히 좋습니다.

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

이 차이점은 테이블을 디자인할 때 중요합니다. 다음 중 하나:

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

ACID 호환성

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

단일 쓰기에서 여러 삽입은 트랜잭션 지원 문제로 피해야 합니다. 이는 분산된 뷰에서만 지원됩니다.

ClickHouse는 분석 쿼리에 대한 최고의 지원을 제공하기 위해 많은 분량으로 프로덕션되었습니다. 집계와 같은 작업은 매우 빠르며 이러한 기능을 보완하기 위한 여러 기능이 있습니다. ClickHouse에는 집계의 자세한 내용을 다룬 좋은 블로그 글이 있습니다.

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

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

특히 ClickHouse에서 데이터베이스 인덱스 디자인이 PostgreSQL과 같은 트랜잭션 데이터베이스와 다른 점을 이해하는 것이 중요합니다.

기본 인덱스 디자인은 쿼리 성능에 매우 중요하며 신중하게 명시해야 합니다. 대부분의 쿼리는 전체 데이터 스캔을 하면 소요시간이 오래 걸리므로 기본 인덱스에 의존해야 합니다.

Merge 트리 테이블 엔진(ClickHouse의 기본 테이블 엔진)에서 쿼리 성능에 미치는 영향을 알아보기 위해 쿼리에서의 기본 키 및 인덱스에 대한 문서를 읽으세요.

ClickHouse의 보조 인덱스는 다른 시스템에서 사용 가능한 것과 다릅니다. 또한 데이터 건너뛰기 인덱스로도 불립니다. 데이터 건너뛰기 인덱스 문서를 참조하세요.

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

데이터 유형 및 파티셔닝

ClickHouse는 SQL 호환 데이터 유형과 LowCardinality, UUID, Maps, 중첩과 같은 몇 가지 특수 데이터 유형을 제공합니다. 흥미로운 것은 열 내에 테이블을 시뮬레이션하는 것입니다.

테이블을 디자인할 때 바로 나오는 중요한 디자인 측면 중 하나는 파티션 키입니다. 파티션은 월, 일 또는 주 같은 시간 기간과 같은 임의의 표현식이 될 수 있지만, ClickHouse는 가장 작은 파티션 세트를 사용하여 읽는 데이터 양을 최소화하려는 노력을 합니다.

권장 문서:

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

샤딩 및 복제

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

ClickHouse 문서 및 복제 및 샤딩 섹션을 참조하세요. ClickHouse는 Zookeeper를 사용하거나 ClickHouse Keeper라는 컴포넌트를 통해 자체 호환 API를 통해 일치 유지를 위해 사용합니다.

노드를 설정한 후에 클라이언트에서 노드가 보이지 않게되며, 쓰기 및 읽기 쿼리를 임의로 노드에 발행할 수 있습니다.

대부분의 경우 클러스터는 일정한 수의 노드(~샤드)로 시작됩니다. 샤드 다시 분배는 활동적으로 이루어지며 철저한 테스트가 필요합니다.

복제는 MergeTree Table 엔진에서 지원됩니다. 세부 정보는 복제 섹션을 참조하시기 바랍니다. 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>