Comparing Write, Read, and Query Performance of General-Purpose and Columnar Data Serialization Formats at Increasing Scale: An Empirical Benchmark Study with Statistical Validation on Synthetic and Real-World Data

초보자용 해설

데이터를 파일로 저장할 때 어떤 포맷을 쓰느냐에 따라 읽기·쓰기·쿼리 속도가 수십 배에서 수천 배까지 차이 난다는 것을 실제 벤치마크로 증명한 논문입니다. CSV, JSON, Pickle, SQLite, Parquet 등 6가지 포맷을 5만~300만 행 규모에서 20회 반복 측정했고, 통계적 유의성 검정까지 마쳤습니다. 핵심은 '필터링 전에 전체를 메모리에 올리는 평면 포맷(CSV, JSON, Pickle)'은 선택적 쿼리에서 인덱스 있는 SQLite나 Parquet 푸시다운보다 1~3자릿수 느리다는 점입니다. 반면 쓰기 속도는 Pickle이 Parquet보다 빠르다는 의외의 결과도 나왔습니다. 실무에서 데이터 파이프라인 포맷을 고를 때 감이 아닌 숫자로 판단할 수 있게 해줍니다.

실무자 관점 요약

이 논문은 데이터 엔지니어링에서 가장 흔하면서도 주먹구구로 결정되는 '직렬화 포맷 선택'을 통계적으로 검증한 드문 사례다. 합성 데이터 4개 스케일(50K~3M rows) × 2개 호스트(Apple Silicon 24GB, 단일코어 4GB VM) × 20회 반복 × 9개 포맷/액세스 조합이라는 실험 설계가 탄탄하다. Welch t-test와 Mann-Whitney U test로 유의성을 검증했고, 실데이터(147만 행 이커머스 사기 데이터셋)로 재현까지 했다. 핵심 인사이트 세 가지: 첫째, 평면 포맷(CSV, JSON Lines, Pickle)은 필터링 전 전체 역직렬화가 필수라 선택적 쿼리에서 인덱스드 SQLite나 Parquet 푸시다운 대비 10~1000배 느리다. 이는 '메모리에 다 올리고 필터링'하는 파이썬 스크립트 방식이 스케일업 시 병목이 되는 이유를 수치로 보여준다. 둘째, 쓰기 경로에서는 Pickle이 Parquet(naive/pushdown)보다 유의하게 빠르다. 기존 5회 파일럿에서는 통계적 동률로 나왔으나 20회로 늘리자 차이가 드러났다. 직렬화 오버헤드가 컬럼라 포맷의 인코딩 비용보다 낮다는 뜻이다. 셋째, SQLite 인덱스는 모든 스케일·호스트에서 선택적 접근 1위를 지켰다. 임베디드 DB로 인덱스만 잘 걸면 별도 OLAP 엔진 없이도 포인트 룩업/레인지 스캔에서 Parquet 푸시다운을 이긴다. 한계도 명확하다: 동시성, 트랜잭션, 스키마 진화, 압축률 트레이드오프, 분산 쿼리 엔진과의 통합 등은 다루지 않는다. 단일 스레드·단일 노드·읽기 전용 워크로드 기준이다. 하지만 '로컬 개발·테스트·중소규모 배치·임베디드 분석' 시나리오에서는 이 벤치마크 숫자가 바로 의사결정 근거가 된다. 특히 파이썬 데이터 스택(pandas, polars, duckdb, sqlite3)을 쓰는 팀이라면 포맷별 성능 프로파일을 외우지 말고 이 논문 표를 북마크해두면 된다.

왜 지금 봐야 하나요?

포맷 선택을 감이 아닌 통계로 할 수 있는 드문 벤치마크다. 로컬 파이프라인·임베디드 분석·중소규모 배치 잡을 짜는 개발자라면 당장 적용 가능한 숫자가 있다. Pickle이 쓰기에서 Parquet을 이긴다는 반직관적 결과도 실무에서 쓰기 병목일 때 바로 써먹을 수 있다.

직접 구현해볼 아이디어

포맷 성능 비교 대시보드: 로컬 CSV/JSON/Parquet/SQLite 파일을 드롭하면 쓰기·읽기·필터 쿼리 레이턴시를 자동 측정해 표와 차트로 보여주는 CLI 툴

서비스 아이디어로 바꾸면

데이터 팀이 파이프라인 포맷을 바꿀 때 예상 속도·비용 변화를 시뮬레이션해주는 SaaS. 업로드된 샘플 데이터로 대표 워크로드(전체 스캔, 포인트 룩업, 레인지 필터)를 돌려 포맷별 P99 레이턴시와 스토리지 비용을 리포트로 제공