메인 콘텐츠로 건너뛰기

데이터 타입

ClickHouse와 Redshift 사이에서 데이터를 옮기는 사용자는 ClickHouse가 더 다양한 타입을 제공하고, 제약도 훨씬 적다는 점을 바로 알 수 있습니다. Redshift에서는 문자열 길이가 가변적이더라도 허용 가능한 길이를 지정해야 하지만, ClickHouse는 문자열을 인코딩 없이 바이트로 저장하므로 이러한 제약과 번거로움이 없습니다. 따라서 ClickHouse의 String 타입에는 길이 제한도, 길이 지정 요구 사항도 없습니다. 또한 ClickHouse에서는 Redshift에 기본적으로 없는 배열, 튜플, Enum을 기본 제공 타입처럼 활용할 수 있습니다(배열/struct는 SUPER로 어느 정도 흉내 낼 수는 있음). 이는 많은 사용자가 자주 불편을 느끼는 부분이기도 합니다. ClickHouse는 집계 상태도 쿼리 시점은 물론 테이블에도 저장할 수 있습니다. 이를 통해 일반적으로 materialized view를 사용해 데이터를 사전 집계할 수 있으며, 자주 사용하는 쿼리의 성능을 크게 향상할 수 있습니다. 아래에서는 각 Redshift 타입에 대응하는 ClickHouse 타입을 매핑합니다: * ClickHouse는 추가로 더 넓은 범위의 부호 없는 정수도 지원합니다. 즉, UInt8, UInt32, UInt32 and UInt64입니다.
**ClickHouse의 String 타입은 기본적으로 길이 제한이 없지만, 제약 조건을 사용해 특정 길이로 제한할 수 있습니다.

DDL 구문

정렬 키

ClickHouse와 Redshift에는 모두 데이터를 저장할 때의 정렬 방식을 정의하는 “정렬 키”라는 개념이 있습니다. Redshift에서는 SORTKEY 절을 사용해 정렬 키를 정의합니다:
CREATE TABLE some_table(...) SORTKEY (column1, column2)
이에 반해 ClickHouse는 정렬 순서를 지정할 때 ORDER BY 절을 사용합니다:
CREATE TABLE some_table(...) ENGINE = MergeTree ORDER BY (column1, column2)
대부분의 경우 기본 COMPOUND 유형을 사용한다면, ClickHouse에서는 Redshift와 동일한 정렬 키(sorting key) 컬럼과 순서를 사용할 수 있습니다. Redshift에 데이터가 추가되면 새로 추가된 데이터를 다시 정렬하고 쿼리 플래너를 위한 통계를 업데이트하기 위해 VACUUMANALYZE 명령을 실행해야 합니다. 그렇지 않으면 정렬되지 않은 공간이 점점 늘어납니다. ClickHouse에서는 이러한 과정이 필요하지 않습니다. Redshift는 정렬 키를 위한 몇 가지 편의 기능을 지원합니다. 첫 번째는 자동 정렬 키(SORTKEY AUTO 사용)입니다. 이는 시작하기에는 적절할 수 있지만, 정렬 키가 최적으로 설정된 경우에는 명시적 정렬 키가 최상의 성능과 스토리지 효율성을 보장합니다. 두 번째는 INTERLEAVED 정렬 키로, 쿼리에서 하나 이상의 보조 정렬 컬럼을 사용할 때 성능을 높이기 위해 정렬 키의 일부 컬럼에 동일한 가중치를 부여합니다. ClickHouse는 명시적인 프로젝션을 지원하며, 약간 다른 설정을 통해 동일한 최종 결과를 얻을 수 있습니다. “primary key” 개념은 ClickHouse와 Redshift에서 서로 다른 의미를 가진다는 점을 알아두어야 합니다. Redshift에서 primary key는 제약 조건을 적용하기 위한 전통적인 RDBMS 개념과 유사합니다. 그러나 Redshift에서는 이것이 엄격하게 적용되지는 않으며, 대신 쿼리 플래너와 노드 간 데이터 배포를 위한 힌트 역할을 합니다. ClickHouse에서 primary key는 희소 프라이머리 인덱스를 구성하는 데 사용되는 컬럼을 뜻하며, 이 인덱스는 디스크에서 데이터가 정렬되도록 하여 압축을 극대화하고 프라이머리 인덱스가 불필요하게 커지는 것을 막아 메모리 낭비를 방지합니다.
마지막 수정일 2026년 6월 10일