랩톱 한 대로 4억 행을 다루기: 클로저에서 만난 DuckDB

데이터 규모가 커지면 개발팀은 반사적으로 분산 클러스터를 떠올린다. 하지만 로컬 디스크 용량과 단일 칩의 연산 능력이 꾸준히 성장한 지금, 수십 기가바이트 수준의 데이터를 반드시 클러스터로 옮겨야 하는지는 다시 따져볼 문제다. TechAscent가 자사 데이터 처리 라이브러리 tech.ml.dataset(TMD)에 임베디드 분석용 데이터베이스 DuckDB를 통합한 사례는, 바로 그 통념을 랩톱 위에서 재검토한 실험이다.

인메모리의 한계와 관계형 DB의 유혹

TMD는 컬럼 지향(column-major) 인메모리 처리 플랫폼으로, 데이터가 메모리에 들어가는 동안은 강력하게 동작한다. 메모리를 넘어서면 표본을 뽑거나 관련 부분집합만 필터링해 작업 범위를 좁히고, 저장은 nippy·arrow·parquet 같은 포맷으로 처리하는 것이 기존 방식이었다. 문제는 relational한 성격을 가진 100GB 규모의 CSV 묶음처럼 데이터가 더 커질 때다. 이 지점에서 팀은 스파크 기반 클러스터 운영이라는 번거로운 길로 끌려가기 쉽다.

관계형 데이터베이스는 메모리 밖 저장과 빠른 관계형 질의에 잘 맞는 도구다. 하지만 함수형 프로그래밍의 장점과 TMD의 컬럼 지향 처리 모델을 포기하지 않으면서 이를 활용하려면 걸림돌이 있다. JDBC와 Postgres 조합이 하나의 답이 되긴 했지만, 행 단위로 넘어오는 비효율적이고 배치 처리가 안 되는 API를 통해 데이터를 다시 컬럼 형태로 변환하는 과정은 번거롭고 성능을 갉아먹었다.

2년 사이에 달라진 DuckDB

DuckDB는 2021년 5월 깃허브 이슈를 통해 등장했고, 그해 12월 tmducken이라는 이름으로 C 바인딩과 최소한으로 통합됐다. 초기 버전은 질의 결과를 한 번에 모두 반환해 전부 메모리에 담아야 했고, 고성능 append나 insert 체계도 없어 IO가 성능의 발목을 잡았다. 그래서 한동안은 Postgres가 TMD의 보조 처리 시스템 자리를 지켰다.

지난 2년간 상황은 크게 바뀌었다. 무엇보다 C 인터페이스가 insert와 query 양쪽에서 배치 방식을 제공하게 되면서, 대규모 조인 처리가 가능해졌다. 이 개선된 기능을 클로저에서 TMD를 거쳐 DuckDB의 벡터화 SQL 실행 엔진에 연결할 수 있게 된 것이다.

실제로 얼마나 빠른가

글에서 든 예시는 구체적이다. 3년치 거래 데이터를 담은 50GB CSV 파일은 4억 행에 이른다. 이를 DuckDB로 적재하는 데는 약 2분이 걸리지만, 그 결과 파일 크기는 인덱스까지 자동 생성된 상태로 18GB까지 줄어든다. 여기에 각 sku의 색상 정보를 담은 별도 데이터셋을 더해, sku당 평균 약 3.51개 색상을 갖는 조건으로 4억 행과 조인한다. "2021년 3월에 색상별로 몇 개가 팔렸나"라는 질문의 답은 1초 만에 나온다.

SQL에 잘 맞지 않는 처리에는 클로저와 TMD로 넘어갈 수 있다는 점도 강조된다. 특정 sku의 모든 거래를 시간순으로 정렬해 reduce하는 예시 역시 1초에 끝난다. 핵심은 실체화된(realized) 데이터셋을 reduction 메커니즘을 통해 임의로 처리하면서도 메모리가 고갈되지 않는다는 데 있다. 나아가 질의 결과의 어떤 청크도 reducing 함수 밖으로 나갈 필요가 없다면 {:reduce-type :zero-copy-imm} 옵션으로 zero copy 경로를 켤 수 있는데, 이것이 이론상 가장 낮은 메모리 사용 경로다.

인덱스 전략과 실무적 함의

DuckDB는 모든 수치 데이터를 minmax 인덱스(BRIN)로 자동 저장한다. 원본 크기를 크게 늘리지 않으면서 질의 성능을 극적으로 끌어올리는 방식이다. 유일 값이나 기본 키 컬럼에는 ART 인덱스를 자동 생성하며, 범주형 컬럼은 사용자가 선택적으로 인덱스를 만들 수 있으나 저장 공간이 늘고 트랜잭션이 느려질 수 있다는 대가가 따른다. 이 트레이드오프는 실무자가 직접 판단해야 할 대목이다.

이식성 측면에서 DuckDB는 표준 C++11로 작성돼 있고, 2023년 9월 기준 src 디렉터리는 약 10만 줄 규모다. 맥 M1용 변형도 빠르게 나왔다. MIT 라이선스에 개방형 개발 모델, 반응 빠른 커뮤니티라는 점도 도입 판단의 근거가 된다. 다만 이 글은 TechAscent가 자사 통합 제품을 소개하는 성격이므로, 제시된 수치와 소요 시간은 특정 하드웨어와 데이터 특성에 따라 달라질 수 있다는 점은 감안해야 한다. 그럼에도 요지는 분명하다. 잘 만든 임베디드 도구 하나면, 남들이 클러스터로 해결하려는 규모의 작업을 작은 팀이 랩톱에서 함수형으로 처리할 여지가 있다는 것이다.