Array/Map/Nested — 컬럼 지향 저장 안에서 반정형 데이터를 표현하는 법
ClickHouse SAMPLE 절 및 Array/Map/Nested 데이터 타입 공식 문서 종합 (웹 리서치, 2026) — ClickHouse 공식 문서(sql-reference/statements/select/sample, sql-reference/data-types/nested-data-structures/nested) ClickHouse 공식 문서 Nested data structures
이 모듈을 다 읽으면
- Nested가 실제로는 독립된 배열 컬럼들의 집합일 뿐이라는 것을 설명할 수 있다
- 이 설계가 왜 컬럼 지향 저장의 압축·벡터화 이점을 유지하기 위한 트레이드오프인지 설명할 수 있다
clickhouse-learn-01에서 다룬 컬럼 지향 저장을 전제로, 한 셀에 여러 값(리스트, 키-값 쌍, 여러 필드로 구성된 레코드 목록)을 담아야 할 때 이 구조를 컬럼 지향 저장과 어떻게 양립시키는지를 Array/Map/Nested 타입으로 정리한다.
Array — 가변 길이 리스트를 한 셀에
Array(T) 타입은 한 행의 한 컬럼에 같은 타입 T의 값 여러 개를 가변 길이 리스트로 저장한다(예: Array(String)로 태그 목록을 저장). Map(K, V)은 키-값 쌍의 집합을 저장하는 타입으로, 내부적으로는 키 배열과 값 배열 한 쌍으로 구현된다. 둘 다 단일 컬럼 안에 '여러 개의 값'을 담는다는 공통점이 있어, 관계형 정규화로 별도 테이블을 만드는 대신 반정형 데이터를 한 행 안에 압축해 표현할 수 있게 해준다.
핵심 포인트
- Array(T): 같은 타입 T의 값을 가변 길이 리스트로 한 셀에 저장
- Map(K, V): 키-값 쌍 집합을 저장, 내부적으로는 키 배열+값 배열 한 쌍으로 구현
Nested의 정체 — '셀 안의 작은 테이블'처럼 보이지만 실제론 병렬 배열
Nested(ID UInt32, Serial UInt32, ...)처럼 여러 필드를 가진 레코드 목록을 한 셀에 담는 것처럼 보이는 Nested 타입은, 실제로는 각 필드가 Goals.ID, Goals.Serial처럼 독립된 Array(UInt32) 컬럼으로 저장되는 것에 불과하다 — 공식 문서 표현으로는 '여러 개의 길이가 같은 컬럼 배열의 집합'으로 이해하는 게 가장 정확하다. 즉 Nested는 진짜 중첩된 계층 구조를 저장하는 게 아니라, 여러 개의 병렬 배열(parallel arrays)을 마치 하나의 논리적 레코드 목록처럼 보이게 해주는 문법적 편의일 뿐이다.
핵심 포인트
- Nested(필드1, 필드2, ...)는 실제로는 각 필드가 독립된 Array 컬럼(예: Goals.ID, Goals.Serial)으로 저장되는 병렬 배열 구조
- 진짜 계층적 중첩 저장이 아니라, 여러 병렬 배열을 하나의 논리적 레코드 목록처럼 보이게 하는 문법적 설탕일 뿐
왜 이렇게 설계했나 — 컬럼 지향 저장의 이점을 포기하지 않기 위해
만약 Nested를 진짜 행 지향적인 중첩 구조로 저장했다면, 같은 필드의 값들이 서로 다른 레코드에 흩어져 컬럼 지향 저장의 핵심 이점(같은 컬럼의 비슷한 값들이 모여 있어 압축률이 높고, 쿼리가 필요한 컬럼만 골라 읽으며, 벡터화 연산이 전체 배열 단위로 한 번에 처리됨)이 무너진다. 병렬 배열 설계는 이 이점을 유지하는 대신, 한 행 안에서 같은 Nested 구조에 속한 모든 배열 컬럼의 길이가 반드시 일치해야 한다는 제약(삽입 시점에 검증됨)을 대가로 치른다 — 계층적 유연성보다 컬럼 지향 성능을 우선한 설계 선택이다.
핵심 포인트
- 병렬 배열 설계는 컬럼 지향 저장의 압축률/컬럼 선택적 읽기/벡터화 연산 이점을 유지하기 위한 것
- 대가로 같은 Nested 구조 내 모든 배열 컬럼의 길이가 한 행 안에서 반드시 일치해야 함(삽입 시점 검증) — 계층적 유연성보다 컬럼 지향 성능을 우선한 설계