OLTP 엔진에서 OLAP 레이크하우스로: InnoDB와 Iceberg 내부 구조 비교
Same Job, Two Engines: InnoDB and Iceberg Internals
MarcPaul이 주식 분석 리포지토리 StockAlgo를 InnoDB 기반 OLTP에서 Iceberg, MinIO, Polaris, Spark로 구성된 OLAP 레이크하우스로 전환한 경험을 공유한다. InnoDB의 행 기반 저장, 인덱스, MVCC가 쓰기 집약적 수집에 왜 불리한지 설명하고, Iceberg의 파티셔닝, 매니페스트, 데이터 파일, 스플릿 플래닝이 읽기 최적화를 어떻게 제공하는지 분석한다. 100GB가 넘는 데이터를 재설계하며 겪은 시행착오와 레이크하우스 쿼리 최적화의 핵심 개념을 담았다.
5년간 v1을 운영하면서 내 분석 작업이 테이블당 2~3개 컬럼만 사용하는데도 모든 컬럼을 읽어야 한다는 사실을 깨달았다.
- sgarland
InnoDB의 세 가지 보장
행이 모든 컬럼을 함께 저장한다
보장되지 않는다. DYNAMIC(기본값) 및 COMPRESSED 행 포맷[0]은 가변 길이 컬럼의 더 큰 값들을 off-page 레코드로 옮길 수 있다. 주어진 예시에서는 이런 일이 발생하지 않겠지만, 그 자체로 보장은 아니다. 이는 대략 Postgres의 TOAST와 동등한데, 다만 Postgres의 TOAST 기본 임계값은 페이지의 1/4(기본 8 KiB 페이지 크기에서 2 KiB)인 반면, InnoDB는 페이지의 1/2(기본 16 KiB 페이지 크기에서 8 KiB)이다.
0: https://dev.mysql.com/doc/refman/9.7/en/innodb-row-format.ht...
- wood_spirit
새로운 것을 배우고 공유하는 개인적인 여정을 엿볼 수 있어서 좋다.
다음 단계로 제안하자면 DuckDB를 시도해보는 것이다. 내 추측으로는 이 규모에서는 spark 같은 걸 압도할 것이다. 데이터 생태계의 다양한 구석을 배우는 건 항상 좋다.