요약
DuckDB 2.0.0 LTS가 서버 모드, 비동기 I/O, VARIANT 타입, 트리거를 담아 나왔습니다.
DuckDB 팀은 1.5 이후 2만 개 가까운 커밋을 모은 이번 버전을 지금까지 가장 큰 기능 릴리스라고 소개했습니다. 1.0이 안정성과 하위 호환에 집중했다면, 2.0은 새 기능에 무게를 뒀다고 밝혔습니다.
왜 중요한가
- 프로그램 안에 넣어 쓰던 내장형 DB가 이제 서버를 띄우고 원격 클라이언트를 받는 구조까지 지원합니다.
- LTS(장기 지원) 버전이라 최소 2027년 10월까지 지원을 받습니다.
- 2.0이 만든 DB 파일은 이전 버전이 열지 못합니다. 그래서 팀은 별도 환경에서 먼저 시험하고, 중요한 시스템은 11월 첫 패치를 기다리라고 권했습니다.
핵심 내용
- Quack 프로토콜(DuckDB 자체 통신 규약)로 서버를 띄우고 붙을 수 있으며, 기본으로는 로컬 접속만 받습니다.
- 비동기 I/O(데이터를 기다리는 동안 다른 요청을 함께 처리하는 입출력)로 S3 같은 원격 저장소 읽기가 빨라집니다.
- VARIANT 타입은 JSON 같은 반정형 데이터를 텍스트가 아닌 열 단위로 저장하고, 공통 구조를 찾아 압축합니다.
- CLI는 코딩 에이전트가 실행하면 출력을 줄이는 에이전트 모드로 바뀝니다. TPC-H 실험에서 모델이 읽을 출력이 59% 줄었습니다.
- 트리거(데이터가 바뀔 때 자동 실행되는 동작)와 새 SQL 파서가 들어왔고, 한 화살표 람다 문법은 기본으로 꺼졌습니다.
HN 반응
- 클라이언트-서버 구조가 여러 대로 된 데이터 스택을 대신할 것이라는 기대가 많았고, 트리거로 데이터 웨어하우스에 가까워졌다는 평도 나왔습니다.
- 2.0이 EC2에서 192 vCPU 안팎까지 코어를 잘 쓴다는 경험담이 나왔지만, 코어가 너무 많으면 병렬화 비용으로 오히려 느려진다는 지적도 있었습니다.
저희는 DuckDB 2.0이 EC2의 코어 수가 많은 머신에서 훨씬 빨라졌다는 걸 확인했습니다. S3에서 데이터를 읽는 속도만이 아니라 실제 연산도 그렇습니다. 128vCPU, 192vCPU 정도까지는 CPU 사용률이 100%에 이를 가능성이 훨씬 높아졌고, 그 사용률이 실제로 작업 완료 시간 단축으로 이어집니다.
여전히 192vCPU를 넘어서면 속도가 더 오르지 않는 경우가 많지만, 2.0 이전에는 64vCPU쯤에서 한계에 부딪혔으니 이건 큰 개선입니다.
덕분에 저희는 Splink(오픈소스 레코드 연결 소프트웨어)로 10억 건의 레코드, 100억 건의 레코드 비교를 10분 안에 처리할 수 있게 됐습니다. 제가 아는 한 이런 종류의 연결 엔진 중에서는 가장 빠릅니다. 이 성능은 대부분 큰 계산을 그냥 DuckDB 엔진에 맡긴 덕분입니다! https://moj-analytical-services.github.io/splink/topic_guides/performance/duckdb_performance_reprex.html
작업해 주신 팀 모두에게 감사드립니다!
비동기 I/O를 도입하면 병목이 디스크에서 CPU(더 흔하게는 메모리 대역폭)로 옮겨 가기 때문에, 부수 효과로 CPU 사용률이 올라가는 게 보통입니다.
제 경험은 다른 SQL 엔진에서 나온 것이지만, 스캔 속도가 좋아지면 다른 모든 연산자가 단위 시간당 처리할 일이 늘어나는 것으로 그대로 이어집니다.
CPU가 더 많이 100%에 붙어 있다는 건 언제나 흐름이 매끄럽다는 좋은 신호입니다. 다만 그 이상으로 최적화하려면 그다음부터는 데이터 레이아웃을 바꿔야 합니다. 동시성을 늘려 얻는 속도 향상이 선형에 못 미치더라도, 더 많이 투입해서 더 많이 얻는 건 여전히 이득입니다. 더 투입할 비용을 감당할 수 있다면 말이죠(인용할 만한 예가 Dy-skew 논문에 있습니다).
네, 말씀하신 대로입니다.
DuckDB에서 저희가 본 현상 하나는 문서에도 언급돼 있는데, '과도한 병렬화'가 가능하다는 겁니다. 코어가 일정 수를 넘으면 CPU가 100%로 돌아가는데도, 병렬화 오버헤드 때문에 CPU를 더할수록 전체 작업의 실제 소요 시간이 오히려 늘어납니다.
데이터를 S3에서 로컬 SSD로 먼저 옮겨 놓고 처리해도 이런 현상이 나타납니다.
전통적인 HPC에서도 있는 문제입니다. 코어 수에 비례해 선형으로 확장되는 알고리즘은 그리 많지 않습니다. HPC 알고리즘이 행렬 곱셈과 몬테카를로 방법 위에 세워진 게 많은 것도 부분적으로는 그 때문입니다. 이 둘은 거의 제한 없이 확장되는 편이거든요.
원인이 DuckDB가 아니라 AWS일 수도 있습니다.
이 일을 한 지 2년이 지났지만, 모든 코어가 동시에 바쁘게 돌아갈 때 AWS Nitro가 CPU Steal 비율을 높게 만드는 것일 수 있습니다.
taskset -c 1-191 <server-process>같은 식으로 실행하면 숨통이 조금 트입니다.저는 코어가 32개를 넘으면 거의 항상 이렇게 합니다. 나머지 CPU가 한창 돌고 있을 때도 ssh 접속이 늘 쾌적하게 반응하거든요.
코어가 많을수록 코어 하나를 비워 두는 부담은 작아집니다.
저는 splink의 열렬한 팬이고, DuckDB를 이렇게 잘 도입하신 것도 대단하다고 생각합니다.
DuckDB 성능이 이렇게 좋아지니 Spark 기반 워크플로우를 대규모로 배포한 사례를 보는 일이 줄었나요? DuckDB를 쓸 수 있다면 Spark의 복잡함을 정당화하기 어려워 보이는데, 그래도 최종 사용자가 어떤 이유로든 Spark를 찾는 경우가 있는지 궁금합니다.
좋게 봐 주셔서 감사합니다.
지금도 Spark를 쓰는 사람은 여럿 있는데, 대개 성능이 더 좋아서가 아니라 플랫폼이나 인프라의 제약 때문입니다. 예를 들어 Databricks 사용자는 큰 머신에서 DuckDB를 쓰기 어려운 경우가 있고, 그냥 Spark가 더 익숙한 사람도 있습니다.
워크로드를 어디서 돌릴지 자유로운 신규 사용자에게는 언제나 DuckDB를 권합니다. 지금은 특히 더 그렇습니다.
Spark를 오래 써 본 입장에서, 대부분의 워크로드에는 이제 Spark가 정말 필요하지 않다고 생각합니다. 너무 복잡하고 튜닝도 너무 어렵습니다. 정말로 어마어마한 데이터가 있다면 모르겠지만요. 대부분의 경우 Spark를 권하지 않는 이유는 여기에 조금 더 적어 두었습니다. https://www.robinlinacre.com/recommend_duckdb/
정말 빠릅니다. 특히 적당한 크기의 클라우드 VM에서, 그리고 Iceberg를 쿼리할 때 그렇습니다. 저는 알파 버전을 작은 조직의 중앙 분석 서버로 프로덕션에서 돌리고 있습니다.
Postgres 와이어 프로토콜이나 Arrow Flight로 접속할 수 있게 해 주는 DuckDB 확장을 직접 만들었습니다. DuckDB에는 자체 Quack 프로토콜도 있지만 지금은 Quack을 지원하는 클라이언트가 매우 적습니다. 반면 Postgres 와이어 프로토콜이나 ADBC(Arrow Flight와 함께 쓸 수 있습니다)를 지원하는 데이터 도구는 많습니다.
https://github.com/sidequery/duckflight-extension
Quack을 지원하는 (바이브 코딩으로 만든) Metabase 드라이버입니다. https://github.com/dragonsahead/duckdb-quack-metabase
멋지네요. 혹시 Quack v3(DuckDB 2.0과 함께 나왔습니다)는 벌써 지원하나요? 아쉽게도 v1과 호환이 안 돼서 수정이 필요할 겁니다.
저희는 예전에 Metabase를 썼는데, 클라우드판과 셀프 호스팅판이 나뉘어 있어서 손볼 게 너무 많았고 표현식 언어도 불편했습니다.
이제 클라이언트-서버 아키텍처로 쓸 수 있다는 점은 판을 바꿀 만한 변화예요. 지금은 서버 여러 대에 CPU와 RAM을 잔뜩 들여 돌리는 많은 데이터 스택을 분명히 대체하게 될 겁니다.
HTTP 서비스나 로드 밸런서 뒤에 두고 자원 사용률에 따라 수평 확장하거나, Cloud Run 같은 곳에서 0까지 축소할 수도 있다니요. 군침이 도네요!
맞아요! 게다가 서버라고 해도 진짜 서버가 아니라 여전히 "인프로세스"라서 가볍고 단순하게 유지돼요. 정말 환상적이에요.
트리거가 정말 기대돼요. 이제 DuckDB는 진짜 "상자 속 데이터 웨어하우스"에 가까워졌네요.
기본으로 돌아가자는 거죠! 정말로 트리거네요.
기본은 괜히 기본이 아니죠. 너무 남발하지만 않으면 트리거는 훌륭해요. (특히 데이터 정의 언어 코드를 전부 버전 관리하신다면요)
정말 훌륭한 소프트웨어입니다. 분석 엔진으로 쓰는 것을 넘어서, 데이터를 가져오고 모양을 바꾸는 데도 놀랄 만큼 다재다능합니다. 수고하셨습니다.
DuckDB UI 노트북을 파일로 저장할 수 있나요?
이걸 써 보세요. https://duckdbsnippets.com/snippets/223/exportimportshare-duckdb-ui-notebooks
DuckDB를 정말 써 보고 싶은데, 저희 회사에서는 쓸 만한 용도를 찾기가 어렵더라고요.
다들 어디에 쓰고 계세요?
서버와 브라우저에서 똑같은 SQL로 쿼리를 투명하게 실행하는 용도입니다.
Google의 Capacitor가 데이터 레이아웃에 쓰는 기법을 전부 적용하면, duckdb-wasm으로 브라우저 기반 쿼리 엔진에 약 200만~300만 행을 16~20MB에 담아 보낼 수 있습니다. HTTP range 쿼리와 cache-control을 쓰면 1GB 정도까지 확장할 수 있고요.
그 위에서 누가 후속 질문을 할 때마다 Jev가 1~2초 안에 SQL 쿼리를 작성하게 합니다. Jev가 SQL을 쓰게 하려면 준비가 좀 필요한데, 제 공동 창업자가 몇 년 전에 투시적(clairvoyant) 쿼리 실행에 관한 논문[1]을 썼습니다.
같은 애플리케이션에 사용자 3,000명이 로그인해 있어도 모두 각자 자기 CPU로 duckdb를 돌리게 됩니다. 이 방식이면 제 데이터 큐브의 컴퓨팅 확장 문제는 해결된 셈입니다.
[1] - https://dl.acm.org/doi/10.14778/2733004.2733064
좀 더 자세히 설명해 주실 수 있나요? duckdb가 커스텀 저장 포맷 쿼리도 지원하나요?
duckdb-wasm에서 range 쿼리가 제대로 동작하게 하려면 현재는
builtin_httpfs를 꼭 비활성화해야 합니다. 그러지 않으면 엄청난 양의 데이터를 끌어오게 될 수 있어요. https://github.com/duckdb/duckdb-wasm/issues/2228#issuecomment-5306086057이번 주에 Ducklake의 성능 문제를 디버깅하면서 꽤 좋은 개선을 해내던 참인데, 정확히 이 증상, 즉 read_parquet()가 S3에서 parquet 푸터를 읽으려고 아주 작은 range 요청을 엄청나게 보내는 문제는 여전히 원인을 알 수 없었습니다. 댓글을 우연히 발견하다니 얼마나 운이 좋은지요! 짚어 주셔서 정말 고맙습니다.
파일이 여럿이고 대부분을 걸러 내는 빡빡한 필터가 있다면 어느 정도는 피할 수 없습니다. 푸터를 끝에 두기로 한 선택은 돌아보면 나쁜 선택이었습니다(HDFS에서는 아니지만, XOR이나 다른 종류의 이레이저 코딩을 쓰는 곳이라면 그렇습니다). 제가 다뤄 본 다른 파일 포맷은 첫 GET의 지연 시간을 몇 ms 줄이려고 푸터 대신 헤더만 썼습니다.
Ducklake가 parquet 파일 위에 zone-map이나 ART 인덱스를 유지할 수 있을 것 같지는 않습니다. 여러 파일에 걸친 min/max/HLL을 압축해 둔 iceberg 메타데이터 같은 것에 해당하는 게 아직 없으니까요.
파일 식별자를 순차 파일에 저장하는 보조 인덱스가 아마 duckdb가 다음으로 만들 가장 쓸모 있는 기능일 겁니다.
놀랍네요, 저희도 회사에서 똑같이 했어요. 아주 잘 돌아가고 있고요. BI 데이터셋 중에는 ZSTD로 압축한 parquet 20MiB 미만에 들어가는 것이 많아요.
개인이나 소규모 팀·그룹이 쓰는 "크지 않은 빅데이터"*가 있나요? 많은 회사가 중앙 집중형 데이터 <저장소>(베이스, 웨어하우스, 레이크, 스웜프 등)를 두고 있는데, 런타임 보안(예: 행 단위 보안)이 까다로운 문제입니다. 사용자가 다루는 데이터가 GB나 MB 단위라면, DuckDB는 보안 문제를 아예 건너뛰고 그들에게 자기 데이터를 전부 제공하는 훌륭한 방법이 될 수 있습니다. 심지어 로컬에서도요. 그러면서도 일급 DB 도구와 성능(고전적인 클라이언트-서버보다 나을 수도 있습니다)을 그대로 누립니다. 예를 들어 예전 방식은 마케팅용 디멘션과 팩트 테이블을 잔뜩 만들고, 접근 권한을 관리하고, 보고서를 만들고, 보여 주면 안 되는 데이터가 새지 않게 챙기는 것이었습니다. 새 방식은 (AI로 탐색해서) SoT에서 추출·변환 작업을 짜고 parquet 파일을 만든 뒤, duckdb로 개인이나 그룹의 리포팅 솔루션이나 애드혹 용도에 제공하는 것입니다. 제 경험상 이 일회성 투자는 그리 크지 않고, 평생 따라다니는 확장과 접근 권한 문제를 없애 줍니다. 누가 쿼리를 쓰다가 사용자 테이블과 제대로 조인하지 않을까 걱정할 필요도 없고요!
최근에 Parquet 파일을 쓰는 Rust 프로파일러에 썼습니다. DuckDB가 요약, 분석, 실행 간 조인 같은 작업을 위한 쉬운 SQL 인터페이스를 제공해 줍니다.
csv와 parquet 파일에 비동기 I/O를 쓰면 어떤 이점이 있나요?
데이터가 도착하기를 기다리느라 (그동안 놀게 되는) 워커 스레드가 막히지 않아서 쓸 수 있는 대역폭을 전부 활용하게 됩니다. 요청과 처리가 독립적으로 관리되니, 결과적으로 활용도가 높아지고 성능이 좋아집니다.