Brain45. 컬럼 지향 저장소 (Columnar Storage)
⚠️ 이 문서는 데이터 웨어하우스(DW)와 빅데이터 분석 환경에서 대용량 데이터를 집계할 때 디스크 I/O를 극적으로 줄이고 쿼리 성능을 비약적으로 향상시키는 **컬럼(열) 단위의 데이터 저장 포맷(예: Parquet, ORC)**을 다룹니다.
핵심 인사이트 (3줄 요약)
- 본질: 전통적인 RDBMS가 데이터를 '행(Row)' 단위로 디스크에 순차 저장하는 것과 달리, 데이터를 속성별 '열(Column)' 단위로 모아서 저장하는 물리적 파일 포맷이다.
- 가치: 수백 개의 컬럼 중 분석에 필요한 2~3개의 컬럼만 선택적으로 디스크에서 읽어올 수 있어(I/O 최소화), OLAP(온라인 분석 처리) 환경의 대규모 집계 쿼리 속도를 수십 배에서 수백 배까지 높여준다.
- 기술 체계: 동일한 데이터 타입이 연속으로 저장되므로 압축률이 매우 뛰어나며(RLE, Dictionary Encoding 등 활용), Hadoop 생태계의 Apache Parquet와 Apache ORC가 대표적인 업계 표준이다.
Ⅰ. 행(Row) 저장 방식의 한계와 분석의 병목
트랜잭션(OLTP)에는 최적인 방식이 대용량 분석(OLAP)에서는 최악의 병목이 된다.
- 로우 지향 스토리지 (Row-oriented Storage):
- CSV나 일반 RDBMS는 한 사람의 정보(ID, 이름, 나이, 주소, 매출액 등)를 연속된 디스크 블록에 묶어서 저장한다.
- 새로운 데이터를 추가(INSERT)하거나 하나의 레코드를 통째로 가져올 때는 매우 빠르다.
- 분석 쿼리(OLAP) 시의 I/O 낭비:
SELECT SUM(매출액) FROM 테이블;과 같은 분석 쿼리를 실행할 때, 로우 기반 저장소는 이름, 나이, 주소 등 필요 없는 컬럼들까지 디스크에서 통째로 메모리로 끌어올려야(Full Table Scan) 하므로 막대한 I/O 낭비가 발생한다.
📢 섹션 요약 비유: 도서관에서 '모든 책의 출판 연도만' 조사하고 싶은데, 책들이 통째로 제본(Row)되어 있어서 무거운 책 수천 권을 전부 책상으로 들고 와서 출판 연도만 확인하고 덮는 낭비와 같습니다.
Ⅱ. 컬럼 지향 저장소의 원리와 성능 극대화 메커니즘
데이터를 세로로 잘라서 따로 저장하면 놀라운 최적화가 가능해진다.
- 디스크 I/O 최소화 (Column Projection):
- ID끼리, 이름끼리, 매출액끼리 모아서 디스크 블록에 저장한다.
- 분석 쿼리가 '매출액'만 요구하면, 디스크 상에서 매출액이 모여있는 블록만 정확히 읽어오므로 전체 I/O의 90% 이상을 절약할 수 있다.
- ┌─────────────────────────────────────────────────────────┐ │ [Row] 1, 홍길동, 30 | 2, 김철수, 25 | 3, 이영희, 35 │ │ [Col] ID: 1, 2, 3 | 이름: 홍길동, 김철수, 이영희 | 나이: 30, 25, 35 │ └─────────────────────────────────────────────────────────┘
- 극대화된 압축률 (High Compression Ratio):
- 동일한 데이터 타입(예: 나이는 숫자, 이름은 문자열)이 연속적으로 저장되므로, 데이터의 패턴이 단순하여 압축 알고리즘(Run-Length Encoding 등)의 효율이 폭발적으로 증가한다. (비용 절감 및 네트워크 전송 속도 향상)
- 대표적인 포맷:
- Apache Parquet (파케이): 스파크(Spark), 임팔라 등에서 널리 쓰이는 표준.
- Apache ORC (Optimized Row Columnar): 하이브(Hive) 생태계에서 고성능을 내기 위해 최적화된 포맷.
📢 섹션 요약 비유: 책을 만들 때 내용 전체를 한 권으로 묶는 대신, '저자만 모은 책', '제목만 모은 책', '출판 연도만 모은 책(Column)'으로 분리해 두어, 출판 연도 조사가 필요할 때 아주 가벼운 책 한 권만 가져와서 빠르게 집계하는 원리입니다.