데이터 타입
수치형
Float64 유형은
정밀도가 일부 희생되는 대신 더 넓은 값 범위를 제공합니다.
반면 ClickHouse는 float와 integer에 대해 다양한 signed 및 unsigned
정밀도를 제공합니다. 이를 통해 정수에 필요한 precision을
명시적으로 지정하여 스토리지와 메모리 오버헤드를 최적화할 수 있습니다. 또한
Snowflake의 Number 유형에 해당하는 Decimal 유형은
최대 76자리까지 지원하므로 precision과 scale 측면에서 두 배의 범위를 제공합니다. 이와 함께 Float64 외에도,
ClickHouse는 정밀도가 덜 중요하고
compression이 특히 중요한 경우를 위해 Float32도 제공합니다.
문자열
VARCHAR는 UTF-8 유니코드 문자를 저장하며, 사용자가
최대 길이를 지정할 수 있습니다. 이 길이는 저장 공간이나
성능에 영향을 주지 않으며, 문자열은 항상 필요한 최소 바이트 수로 저장되고,
오히려 후속 도구에서 활용할 수 있는 제약 조건만 제공합니다. Text 및 NChar와 같은 다른 유형은
단지 이 유형의 별칭일 뿐입니다. 반면 ClickHouse는
모든 문자열 데이터를 원시 바이트로 String
유형에 저장하며(길이 지정 불필요), 인코딩은 사용자에게 맡기고,
다양한 인코딩을 처리할 수 있는 쿼리 시점 함수를
제공합니다. 그 배경에 대해서는 “Opaque data argument”를
참조하십시오. 따라서 ClickHouse의 String은 구현 측면에서
Snowflake의 Binary 유형에 더 가깝습니다. Snowflake
와 ClickHouse는 모두
“collation”을 지원하므로, 사용자가 문자열의 정렬 및 비교 방식을 재정의할 수 있습니다.
반정형 유형
VARIANT, OBJECT, ARRAY 유형을 지원합니다.
ClickHouse는 이에 대응하는 Variant,
Object(현재는 네이티브 JSON 유형으로 대체되어 더 이상 권장되지 않음)와 배열
유형을 제공합니다. 또한 ClickHouse에는 JSON
유형이 있으며, 이 유형은 현재 더 이상 권장되지 않는 Object('json') 유형을 대체하고 다른 네이티브 JSON 유형과 비교했을 때도
특히 높은 성능과 뛰어난 저장 효율을 제공합니다.
ClickHouse는 또한 이름이 있는 Tuples와 튜플의 배열을
Nested 유형으로 지원하여,
중첩 구조를 명시적으로 매핑할 수 있게 합니다. 이를 통해 Snowflake와 달리 계층 전체에 걸쳐 코덱과 유형
최적화를 적용할 수 있습니다. Snowflake는 외부
객체에 OBJECT, VARIANT, ARRAY 유형을 사용해야 하며,
명시적인 내부 타이핑을 허용하지 않습니다.
이러한 내부 타이핑은 또한 ClickHouse에서 중첩된 숫자형에 대한 쿼리를 단순화하며,
CAST가 필요 없고 인덱스 정의에도 사용할 수 있습니다.
ClickHouse에서는 코덱과 최적화된 유형을 하위 구조에도 적용할 수 있습니다.
그에 따라 중첩 구조를 사용하더라도 압축 효율이
평탄화된 데이터와 비교해도 매우 우수한 수준으로 유지된다는 추가 이점이 있습니다. 반면,
하위 구조에 특정 유형을 적용할 수 없기 때문에 Snowflake는 최적의 압축을 위해
데이터를 평탄화할 것을 권장합니다.
또한 Snowflake는 이러한 데이터 유형에 대해 크기 제한도 적용합니다.
자료형 참고
마지막으로, ClickHouse는 집계 함수의 중간
상태를 저장할 수 있는 고유한 기능을 제공합니다. 이
상태는 구현별로 다르지만, 집계 결과를 저장해 두었다가
나중에 조회할 수 있게 해줍니다(해당 머지 함수 사용). 일반적으로 이
기능은 materialized view를 통해 사용되며, 아래 예시와 같이 삽입된 데이터에 대한 쿼리의
증분 결과를 저장하여 적은 저장 비용으로 특정 쿼리의 성능을 개선할 수 있습니다
(자세한 내용은 여기 참조).