컬럼 기반 저장(Columnar Storage)
1. 개요
가. 정의
컬럼 기반 저장(Columnar Storage, 열 지향 저장)은 하나의 테이블을 행 단위가 아니라 컬럼(열) 단위로 물리적으로 연속 배치하여, 같은 속성의 값들을 한데 모아 저장·압축·스캔하는 저장 모델(DSM, Decomposition Storage Model)이다. 이는 한 행의 모든 속성을 붙여 저장하는 전통적 행 지향 저장(NSM, N-ary Storage Model)과 대비되며, 대량 데이터를 대상으로 소수 컬럼만 집계·분석하는 OLAP·분석 워크로드에 최적화된 구조다.
나. 등장 배경 및 필요성
전통적 관계형 DBMS는 온라인 트랜잭션 처리(OLTP)를 전제로 설계되었다. 주문 한 건을 삽입하거나 특정 고객의 레코드 전체를 조회하는 업무에서는, 한 행의 모든 컬럼을 디스크의 한 위치에 붙여 두는 행 지향 방식이 유리하다. 한 번의 페이지 읽기로 필요한 레코드 전체를 얻을 수 있기 때문이다. 그러나 2000년대 이후 데이터 웨어하우스와 비즈니스 인텔리전스(BI)가 확산되면서 워크로드의 성격이 근본적으로 달라졌다. "지난 3년간 지역별 매출 합계"처럼 수억 건의 행을 훑되 실제로 사용하는 컬럼은 두세 개뿐인 분석 질의가 지배적이 된 것이다.
이런 질의를 행 지향 저장에서 처리하면 심각한 낭비가 발생한다. 매출 컬럼 하나만 필요해도 디스크는 페이지 단위로 읽히므로, 그 페이지에 함께 담긴 고객명·주소·상품설명 등 불필요한 컬럼까지 모두 I/O로 끌어올려야 한다. 컬럼이 100개인 테이블에서 3개만 쓰는 질의라면 이론상 97%의 I/O가 헛수고다. 디스크 대역폭과 메모리 버스가 병목인 대용량 분석에서 이 낭비는 곧 응답 시간과 비용으로 직결된다.
컬럼 기반 저장은 이 문제를 정면으로 해결한다. 질의에 등장하는 컬럼만 선택적으로 읽어(projection pushdown) I/O를 최소화하고, 같은 도메인·같은 타입의 값이 물리적으로 이웃하므로 압축률이 극적으로 높아지며, 값의 배열을 한꺼번에 처리하는 벡터화(vectorized)·SIMD 실행으로 CPU 캐시 효율까지 끌어올린다. 그 결과 동일 하드웨어에서 분석 질의 성능이 수 배~수십 배 향상되어, 오늘날 거의 모든 분석 엔진(Redshift·BigQuery·Snowflake·ClickHouse·DuckDB)이 컬럼 저장을 채택하고 있다.
이 아이디어 자체는 새롭지 않다. 학계에서는 1980년대의 분해 저장 모델(DSM) 연구에서 출발했고, 2000년대 초 네덜란드 CWI의 MonetDB와 마이클 스톤브레이커(Michael Stonebraker) 팀의 C-Store(이후 상용 제품 Vertica로 발전)가 컬럼 저장의 성능 잠재력을 실증하면서 본격적으로 산업에 확산되었다. 즉 컬럼 저장은 최신 유행이 아니라, 워크로드가 트랜잭션에서 분석으로 이동함에 따라 오랜 연구 성과가 주류 기술로 재부상한 사례에 가깝다.
다. 특징
- 선택적 컬럼 읽기(I/O 절감): 질의가 참조하는 컬럼만 디스크에서 읽어 불필요한 데이터 전송을 제거한다.
- 높은 압축률: 동일 타입·유사 값이 이웃하여 사전(dictionary)·RLE·델타 인코딩이 잘 들어맞아 일반적으로 행 저장 대비 2~10배 압축된다.
- 벡터화·SIMD 친화: 한 컬럼의 값이 연속 배열이므로 반복 연산을 벡터 단위로 처리해 CPU 파이프라인·캐시를 효율적으로 쓴다.
- 집계 최적화: SUM·AVG·COUNT 등 컬럼 전체 스캔·집계에 강하나, 단건 삽입·갱신·삭제(OLTP)에는 취약하다.
- 통계 기반 스키핑: 컬럼 청크별 min/max 등 통계를 함께 저장해, 조건에 맞지 않는 데이터 블록을 아예 읽지 않고 건너뛴다.
2. 전체 구조: 행 지향 vs 열 지향
행 지향과 열 지향의 차이는 "논리적으로 같은 표를 디스크에 어떻게 펼쳐 놓는가"에 있다. 논리 테이블은 동일하지만, 물리 배치가 달라지면서 I/O·압축·연산 특성이 통째로 갈린다. 아래 구조도는 4개 컬럼을 가진 테이블이 두 모델에서 각각 어떻게 직렬화되는지를 보여준다.
flowchart TB
T["논리 테이블(행 R1~R3 × 컬럼 A~D)"]
T --> NSM["행 지향(NSM)"]
T --> DSM["열 지향(DSM)"]
subgraph NSM_L["행 지향 물리 배치"]
N1["블록: (R1.A R1.B R1.C R1.D)"]
N2["블록: (R2.A R2.B R2.C R2.D)"]
N3["블록: (R3.A R3.B R3.C R3.D)"]
end
subgraph DSM_L["열 지향 물리 배치"]
D1["컬럼 A: (A1 A2 A3)"]
D2["컬럼 B: (B1 B2 B3)"]
D3["컬럼 C: (C1 C2 C3)"]
D4["컬럼 D: (D1 D2 D3)"]
end
NSM --> NSM_L
DSM --> DSM_L
위 그림에서 행 지향은 한 행의 A~D가 한 블록에 붙어 있어 "R2 전체를 달라"는 요청에 강하다. 반면 열 지향은 컬럼 A의 값들만 따로 모여 있어 "모든 행의 A를 합산"하는 요청을 한 번의 순차 스캔으로 끝낸다. 이 배치 차이가 곧 워크로드 적합성을 결정한다.
각 구성 요소를 좀 더 풀어 보면 다음과 같다. 컬럼 청크(column chunk)는 한 컬럼의 값들을 모은 물리 단위로, 여기에 인코딩·압축이 적용된다. 값 자체 외에 어느 행이 NULL인지 표시하는 정의 수준(definition level)·널 비트맵, 그리고 각 값이 어느 논리 행에 속하는지 되짚기 위한 행 위치(ordinal position) 정보가 함께 관리된다. 열 지향은 행을 통째로 저장하지 않으므로, 여러 컬럼을 결합해 원래의 행을 되살리는 튜플 재구성(tuple reconstruction) 이 별도로 필요하며, 이 비용을 어떻게 최소화하느냐가 컬럼 엔진 설계의 핵심 과제가 된다.
이 물리 배치 차이가 실제 수치로 어떻게 드러나는지 예를 들어 보자. 컬럼이 50개이고 각 행이 평균 500바이트인 10억 건 테이블(약 500GB)에서 "매출 컬럼(8바이트)의 합계"를 구한다고 하자. 행 지향에서는 원리적으로 500GB 전체를 스캔해야 하지만, 열 지향에서는 매출 컬럼만 읽으므로 약 8GB(압축 전)만 접근하면 되고, 사전·델타 인코딩으로 2GB 안팎까지 줄어든다. 동일한 디스크 대역폭에서 읽어야 할 데이터가 두 자릿수 배 줄어드는 셈이며, 이것이 컬럼 저장이 분석 질의에서 압도적 이점을 갖는 근본 이유다.
또한 열 지향은 스키마 진화(schema evolution) 에도 유연하다. 컬럼이 독립적으로 저장되므로 새 컬럼 추가는 기존 데이터를 재기록하지 않고 새 컬럼 파일만 덧붙이면 되고, 특정 컬럼만 다른 인코딩으로 재작성하는 부분 최적화도 가능하다. 반면 행 지향은 컬럼 추가·변경이 행 레코드 구조 전체에 영향을 주어 상대적으로 무겁다. 이처럼 물리 배치 하나의 선택이 I/O·압축·연산뿐 아니라 스키마 운영 방식까지 연쇄적으로 규정한다.
| 구분 | 행 지향(NSM) | 열 지향(DSM) |
|---|---|---|
| 물리 배치 | 한 행의 모든 컬럼 연속 | 한 컬럼의 모든 값 연속 |
| 유리한 질의 | 단건 조회·삽입(OLTP) | 대량 스캔·집계(OLAP) |
| 압축률 | 낮음(이종 타입 혼재) | 높음(동종 값 이웃) |
| 갱신 비용 | 낮음 | 높음(여러 컬럼 파일 접근) |
| 대표 시스템 | MySQL·PostgreSQL·Oracle | Redshift·ClickHouse·DuckDB |
3. 핵심 기법: 인코딩·압축과 실행
컬럼 저장의 성능은 단순히 "컬럼을 모아 둔다"에서 나오지 않고, 그 위에 얹히는 경량 인코딩(lightweight encoding) 과 벡터화 실행에서 완성된다. 아래 상세도는 원시 컬럼 값이 인코딩·압축을 거쳐 저장되고, 질의 시 데이터 스키핑과 늦은 구체화를 통해 처리되는 파이프라인을 나타낸다.
flowchart LR
RAW["원시 컬럼 값"] --> ENC["경량 인코딩(사전·RLE·델타)"]
ENC --> CMP["범용 압축(LZ4·Zstd)"]
CMP --> STORE[("컬럼 청크 저장(+ 존 맵)")]
Q["분석 질의"] --> SKIP["데이터 스키핑(min/max 존 맵)"]
STORE --> SKIP
SKIP --> SCAN["벡터화 스캔(SIMD)"]
SCAN --> LATE["늦은 구체화(late materialization)"]
LATE --> RESULT["결과 집계"]
가. 경량 인코딩. 컬럼 저장이 높은 압축률을 얻는 첫 번째 이유는 값의 동질성이다. 사전 인코딩(dictionary encoding) 은 반복되는 문자열·범주형 값을 정수 코드로 치환해 저장 크기를 줄이고, 정수 비교만으로 필터를 수행하게 해 CPU 부담까지 낮춘다. RLE(Run-Length Encoding) 는 정렬되거나 반복이 많은 컬럼에서 "값+반복횟수"로 압축하며, 델타 인코딩(delta encoding) 은 타임스탬프·일련번호처럼 증가 추세가 뚜렷한 컬럼에서 이전 값과의 차이만 저장한다. 여기에 비트 패킹(bit-packing) 을 결합하면 실제 값 범위에 맞는 최소 비트 수만 사용한다. 예컨대 국가 코드 컬럼(값 종류 수백 개)은 사전 인코딩으로 원본의 10% 이하로 줄고, 초 단위로 증가하는 로그 타임스탬프는 델타+비트패킹으로 대폭 압축된다.
인코딩 기법은 컬럼의 데이터 특성에 맞춰 선택된다. 아래 표는 대표 인코딩과 그것이 잘 맞는 컬럼 유형, 그리고 기대 효과를 정리한 것이다. 실제 엔진은 컬럼별 통계를 보고 인코딩을 자동 선택하거나(예: 카디널리티가 낮으면 사전 인코딩) 여러 기법을 계단식으로 결합한다.
| 인코딩 | 적합한 컬럼 | 원리 | 기대 효과 |
|---|---|---|---|
| 사전(Dictionary) | 저카디널리티 범주형·문자열 | 값→정수 코드 치환 | 크기 축소 + 정수 비교 필터 |
| RLE | 정렬·반복 많은 컬럼 | 값+반복횟수로 표현 | 반복 구간 극단 압축 |
| 델타(Delta) | 증가형 숫자·타임스탬프 | 이전 값과의 차이만 저장 | 좁은 값 범위로 축소 |
| 비트 패킹 | 값 범위가 좁은 정수 | 필요한 최소 비트만 사용 | 정수 저장 효율화 |
나. 범용 압축과의 결합. 경량 인코딩으로 1차 정리된 바이트 스트림에 다시 LZ4·Snappy·Zstandard 같은 범용 압축을 씌우면 압축률이 한층 높아진다. 실무에서는 "질의 시 압축 해제 비용"과 "저장·전송 절감" 사이의 트레이드오프에 따라, 뜨거운(hot) 데이터에는 해제 속도가 빠른 LZ4/Snappy를, 차가운(cold) 아카이브에는 압축률이 높은 Zstd를 쓰는 식으로 계층화한다. 압축은 저장 비용뿐 아니라 디스크·네트워크 I/O량 자체를 줄여, 압축 해제에 드는 CPU를 상쇄하고도 순이득이 나는 경우가 많다.
다. 데이터 스키핑(존 맵). 컬럼 청크마다 최소·최대값, NULL 개수 같은 존 맵(zone map)·통계를 함께 저장하면, WHERE 매출 > 1억 같은 필터에서 최대값이 1억 이하인 청크 전체를 읽지 않고 건너뛴다. 이 프레디킷 푸시다운(predicate pushdown)·데이터 스키핑은 컬럼 저장의 I/O 절감을 배가하며, 데이터가 관련 컬럼으로 정렬·클러스터링되어 있을수록 효과가 커진다.
라. 벡터화 실행과 늦은 구체화. 컬럼 값이 연속 배열이므로, 엔진은 한 번에 한 행이 아니라 수천 개의 값을 배치(batch)로 처리한다. 이 벡터화 모델은 함수 호출 오버헤드를 분산하고 SIMD 명령으로 병렬 연산해 CPU 효율을 높인다. 전통적 행 기반 실행이 튜플 하나마다 연산자를 호출하는 "볼케이노(Volcano) 반복 모델"이라면, 벡터화는 그 호출을 배치당 한 번으로 줄여 인터프리터 오버헤드를 상각한다. 또한 늦은 구체화(late materialization) 는 필터·집계에 필요한 컬럼만 먼저 처리하고, 원래의 행 형태로 되돌리는 튜플 재구성을 최대한 뒤로 미뤄 불필요한 데이터 결합을 피한다. 반대로 질의 초반에 행을 복원하는 이른 구체화(early materialization)는 구현이 단순하지만 대량 스캔에서 손해를 본다. 필터 선택도(selectivity)가 매우 낮아 대부분의 행이 걸러지는 질의일수록 늦은 구체화의 이득이 커진다.
마. 한계와 부적합 워크로드. 반대로 컬럼 저장이 불리한 경우도 분명히 있다. SELECT *처럼 모든 컬럼을 요구하는 질의는 컬럼 파일을 다시 행으로 재조립해야 하므로 오히려 손해이며, 단건 삽입·수정이 잦은 OLTP, 또는 소수 행을 키로 정확히 찾아 전체 속성을 가져오는 포인트 조회 역시 행 지향·B+Tree 인덱스가 유리하다. 따라서 컬럼 저장은 "만능 대체재"가 아니라 분석 워크로드에 특화된 도구로 이해하고, 트랜잭션 시스템과 역할을 나누어 배치하는 것이 올바른 설계 관점이다.
4. 비교와 적용 사례
행 지향과 열 지향은 우열이 아니라 워크로드 정합성의 문제다. 차이가 생기는 근본 원인은 "한 번의 I/O로 읽어 온 데이터 중 실제로 질의가 소비하는 비율"에 있다. OLTP는 특정 행 전체를 자주 다루므로 행 지향이 그 비율을 높이고, OLAP는 소수 컬럼을 전 범위로 훑으므로 열 지향이 그 비율을 높인다. 갱신 특성도 갈린다. 열 지향에서 한 행을 갱신하려면 흩어진 여러 컬럼 파일을 모두 손대야 하므로, 대부분의 컬럼 시스템은 개별 UPDATE 대신 불변(immutable) 파일에 새 버전을 추가(append)하고 병합(compaction) 하는 방식을 택한다.
갱신 처리 방식을 조금 더 들여다보면, 많은 컬럼 엔진은 [[lsm-tree]]와 유사한 발상으로 쓰기를 흡수한다. 새로 들어온 행을 우선 작은 메모리·행 버퍼(또는 소규모 파일)에 모아 두었다가, 일정 임계치에 도달하면 이를 컬럼 형식의 불변 파일로 플러시하고, 백그라운드에서 여러 조각을 하나로 병합(compaction) 한다. 삭제·수정은 해당 행을 곧바로 제거하는 대신 삭제 표시(tombstone)나 새 버전으로 기록하고, 읽는 시점에 걸러 내거나(merge-on-read) 병합 시점에 반영한다(merge-on-write). 이 구조 덕분에 대량 적재 처리량은 높지만, 병합이 밀리면 소파일이 쌓여 스캔 성능이 떨어지므로 병합 정책 관리가 운영의 핵심이 된다.
이 트레이드오프 때문에 최신 시스템은 두 모델을 결합한다. 하이브리드 HTAP 접근으로, 최근 데이터는 행 저장(빠른 삽입)으로 받고 오래된 데이터는 열 저장(빠른 분석)으로 전환하는 구조가 대표적이다. 예를 들어 ClickHouse는 컬럼 저장 위에서 초당 수십억 행의 집계를 처리해 대규모 로그·이벤트 분석에 쓰이고, Amazon Redshift는 컬럼 저장과 존 맵·정렬 키를 결합해 페타바이트급 웨어하우스를 운영하며, Google BigQuery는 Capacitor 컬럼 포맷과 Dremel 실행 엔진으로 서버리스 분석을 제공한다. 임베디드 분석에서는 단일 파일로 동작하는 DuckDB가 컬럼·벡터화 엔진으로 노트북 환경에서도 대용량 CSV·Parquet 분석을 수 초 내에 수행하는 사례가 늘고 있다.
구체적 적용 사례로 관측성(Observability) 로그 분석을 들 수 있다. 수천 대 서버가 초당 수백만 건의 로그·메트릭을 쏟아내는 환경에서, 이를 행 지향 RDBMS에 넣고 "지난 1시간 오류율을 서비스별로 집계"하면 전체 스캔 부담으로 응답이 수십 초를 넘긴다. 동일 데이터를 ClickHouse·Druid 같은 컬럼 엔진에 적재하고 시간·서비스 컬럼으로 정렬해 두면, 존 맵 스키핑과 벡터화 집계로 같은 질의를 1초 내에 처리한다. 또 다른 사례로, 통신사의 통화·과금 상세기록(CDR) 분석에서는 수백 컬럼 중 요금 관련 몇 개만 반복 집계되므로, 컬럼 저장으로 전환한 뒤 저장 비용은 압축으로 수 배 줄고 월말 정산 배치 시간은 크게 단축된 사례가 보고된다. 이처럼 "넓고(많은 컬럼) 깊은(많은 행) 데이터에서 소수 컬럼을 반복 집계"하는 패턴일수록 컬럼 저장의 이득이 커진다.
| 관점 | 행 지향(OLTP) | 열 지향(OLAP) |
|---|---|---|
| 대표 질의 | SELECT * WHERE id=? |
SELECT SUM(x) GROUP BY y |
| 삽입/갱신 | 빠름 | 느림(append·compaction) |
| 스캔·집계 | 느림 | 빠름 |
| 압축 | 제한적 | 우수 |
| 인덱스 의존 | 높음(B+Tree) | 낮음(스캔+스키핑) |
정리하면, 두 모델의 선택 기준은 "질의가 행 지향적인가, 컬럼 지향적인가"라는 단일 질문으로 수렴한다. 소수의 행을 폭넓은 컬럼으로 다루면 행 저장이, 다수의 행을 소수 컬럼으로 집계하면 열 저장이 정답이다. 현실의 시스템은 이 둘을 하나의 저장소로 통합하기보다 역할을 나눈 저장 계층으로 구성하고, 그 사이를 데이터 파이프라인으로 잇는 편이 총소유비용(TCO)과 성능 모두에서 유리한 경우가 많다.
5. 심화: 저장 포맷 표준화와 레이크하우스
컬럼 저장은 데이터베이스 엔진 내부 기술에서 출발했지만, 오늘날의 흐름은 개방형 파일 포맷(open format) 으로의 표준화다. 순수 열 저장(모든 값을 컬럼별 파일로 완전 분리)은 튜플 재구성 비용이 크다는 약점이 있어, 실무 포맷은 대부분 PAX(Partition Attributes Across) 계열의 하이브리드를 택한다. 즉, 테이블을 수만~수십만 행 단위의 행 그룹(row group) 으로 먼저 나누고, 각 행 그룹 안에서만 컬럼별로 값을 모으는 방식이다. 이렇게 하면 컬럼 스캔의 이점을 살리면서도 하나의 행 그룹 안에서 관련 컬럼을 지역적으로 재구성할 수 있어 I/O 지역성이 개선된다.
이 하이브리드 설계를 표준화한 대표 포맷이 Apache Parquet 와 Apache ORC 다. Parquet는 행 그룹 → 컬럼 청크 → 페이지 계층으로 구성되며 중첩(nested) 데이터를 정의 수준·반복 수준으로 표현하는 Dremel 모델을 채택했고, Spark를 비롯한 빅데이터 생태계의 사실상 표준 포맷으로 쓰인다. ORC는 스트라이프(stripe) 단위 구조와 내장 인덱스·통계로 Hive 계열에서 널리 쓰인다. 메모리 영역에서는 Apache Arrow 가 언어·엔진 간에 복사·직렬화 없이 데이터를 주고받는 인메모리 컬럼 표준으로 자리 잡아, 이기종 시스템 사이의 데이터 교환 비용을 낮추고 있다.
상용 클라우드 웨어하우스도 같은 원리를 내부에 녹였다. Snowflake는 데이터를 수십~수백 MB 단위의 불변 마이크로 파티션(micro-partition) 으로 나누고 그 안에서 컬럼 단위로 저장·압축하며, 파티션마다 min/max·distinct 수 같은 메타데이터를 두어 프루닝(pruning)한다. 이는 앞서 본 PAX 하이브리드와 존 맵 스키핑을 상용 규모로 구현한 사례다. 정리하면, 학술 개념(C-Store·PAX)에서 출발한 컬럼 저장이 개방형 파일 포맷(Parquet·ORC)과 인메모리 표준(Arrow), 그리고 상용 엔진(Snowflake·BigQuery·Redshift)에 이르기까지 하나의 계보로 이어져 오늘날 분석 인프라 전반을 관통하고 있다.
가장 최근의 동향은 레이크하우스(Lakehouse) 다. 오브젝트 스토리지(S3 등)에 쌓인 Parquet·ORC 파일 위에 Delta Lake·Apache Iceberg·Apache Hudi 같은 테이블 포맷이 트랜잭션 로그·스키마 진화·시점 조회(time travel)·ACID를 얹어, 값싼 데이터 레이크에 데이터 웨어하우스의 신뢰성을 결합한다. 여기서 컬럼 파일(Parquet)은 데이터를 담는 물리 계층을, 테이블 포맷은 어떤 파일들이 특정 시점의 테이블을 구성하는지를 기술하는 메타데이터 계층을 담당한다. 이 분리 덕분에 하나의 데이터 사본을 두고도 배치·스트리밍·BI·ML이 서로 다른 엔진으로 동시에 접근하면서 일관성을 유지할 수 있다. 이로써 저장은 개방형 컬럼 포맷 하나로 통일하고, 그 위에서 여러 질의 엔진(Spark·Trino·Snowflake·DuckDB)이 각자 접근하는 저장·연산 분리(decoupled storage-compute) 아키텍처가 표준으로 굳어지고 있다. 관련 개념은 [[data-warehouse-olap]], [[btree-bplus-index]] 와 함께 이해하면 저장·색인·분석의 전체 그림이 잡힌다.
6. 고려사항 및 시사점
컬럼 저장은 특정 제품의 한 기능이 아니라 데이터 아키텍처의 근간을 이루는 선택이므로, 도입 전에 워크로드 특성과 장기 운영 부담을 함께 저울질해야 한다.
특히 기술사 답안에서는 다음의 다섯 축 — 워크로드 분리, 압축 트레이드오프, 갱신·규제 대응, 개방형 포맷, 운영·모니터링 — 을 균형 있게 짚어 적용 전략과 트레이드오프, 전망, 연계 기술을 함께 논하는 것이 바람직하다.
- 워크로드 분리 전략(HTAP): 트랜잭션과 분석을 하나의 저장 모델로 억지로 통합하기보다, 행 저장(OLTP) + 열 저장(OLAP)을 계층화하고 CDC(Change Data Capture)·ETL/ELT로 동기화하는 하이브리드가 현실적이다. 최근 HTAP 엔진은 내부적으로 두 표현을 함께 유지하되 일관성·지연을 관리하는 방향으로 진화한다.
- 압축·성능 트레이드오프: 높은 압축률은 저장·I/O를 줄이지만 질의 시 압축 해제 CPU를 요구한다. 데이터 온도(hot/cold)에 따라 인코딩·압축 코덱과 정렬 키를 차등 적용하고, 존 맵 효과를 살리도록 자주 필터되는 컬럼 기준으로 데이터를 정렬·클러스터링하는 물리 설계가 성능을 좌우한다.
- 갱신·삭제와 규제 대응: 컬럼·불변 파일 구조는 개별 삭제가 어렵다. GDPR·개인정보보호법의 삭제권 대응, 소규모 잦은 갱신으로 인한 소파일(small file) 폭증 문제는 주기적 병합(compaction)·파티션 설계·머지-온-리드/라이트 전략으로 관리해야 한다.
- 개방형 포맷과 락인 회피: Parquet·Iceberg 등 개방형 포맷·테이블 포맷을 채택하면 특정 벤더 엔진에 대한 종속(lock-in)을 줄이고, 저장·연산 분리로 엔진을 교체·병행할 수 있는 유연성을 확보한다. 이는 멀티클라우드·비용 최적화(FinOps) 관점에서도 중요한 선택 기준이다.
- 운영·모니터링 관점: 컬럼 저장 시스템의 성능은 파티션·정렬 키 설계와 병합 주기에 크게 좌우되므로, 소파일 수·병합 지연·스키핑 효율(스캔 대비 실제 읽은 청크 비율) 같은 지표를 지속 관측하고 물리 설계를 반복 조정하는 운영 역량이 요구된다.
- 전망: GPU 기반 벡터 처리, 실시간 스트리밍과 배치의 통합, 그리고 벡터 임베딩([[vector-database]])·AI 워크로드를 함께 담는 분석 플랫폼으로 컬럼 저장의 적용 범위가 확대되고 있다. 개방형 테이블 포맷의 표준 경쟁(Iceberg 중심의 수렴 흐름)도 향후 데이터 아키텍처 선택에서 핵심 변수가 될 전망이다.
참고자료
- Apache Parquet, "File Format", https://parquet.apache.org/docs/file-format/
- Apache ORC, "ORC Specification", https://orc.apache.org/specification/
- Stonebraker et al., "C-Store: A Column-oriented DBMS", VLDB 2005, https://www.vldb.org/archives/website/2005/program/paper/thu/p553-stonebraker.pdf
- Ailamaki et al., "Weaving Relations for Cache Performance (PAX)", VLDB 2001, https://www.vldb.org/conf/2001/P169.pdf
- Apache Arrow, "Format", https://arrow.apache.org/docs/format/Columnar.html
한 줄 요약: 컬럼 기반 저장은 데이터를 열 단위로 모아 선택적 읽기·고압축·벡터화 실행을 실현하는 분석(OLAP) 최적 저장 모델로, Parquet·ORC 같은 개방형 하이브리드 포맷과 레이크하우스를 통해 오늘날 데이터 분석 인프라의 표준 기반이 되었다.