DuckDB 2.0을 EC2의 코어 수가 많은 머신에서 써보니 훨씬 빨라짐. S3 데이터 읽기뿐 아니라 실제 연산도 빨라졌고, 약 128~192 vCPU까지 CPU 사용률 100%에 도달하는 일이 훨씬 잦아지면서 작업 완료 시간도 줄어듦.
약 192 vCPU를 넘으면 여전히 속도 향상이 드물지만, 이전에는 약 64 vCPU에서 성능이 정체됐으니 큰 개선임. 덕분에 오픈소스 레코드 연결 소프트웨어 Splink로 레코드 10억 개와 레코드 비교 100억 건을 10분에 처리할 수 있게 됨. 내가 아는 한 이런 종류의 연결 엔진 중 가장 빠르며, 성능 대부분은 큰 연산을 DuckDB 엔진에 맡기는 것만으로 얻어짐. https://moj-analytical-services.github.io/splink/topic_guide....
비동기 I/O는 병목을 디스크에서 CPU, 더 흔하게는 메모리 대역폭으로 옮기면서 CPU 사용률도 높이는 경우가 많음. 다른 SQL 엔진에서 겪은 일이지만, 스캔 속도가 높아지면 다른 모든 연산자가 단위 시간당 처리할 작업도 곧바로 늘어남.
더 많은 CPU가 100%로 돌아가는 것은 데이터 흐름이 원활하다는 좋은 신호지만, 그 지점부터 더 최적화하려면 데이터 배치 변경이 필요함. 동시성을 늘린 만큼 선형적으로 빨라지지 않더라도, 비용을 감당할 수 있다면 자원을 더 써서 성능이 좋아지는 것 자체는 이득임. Dy-skew 논문에도 인용할 만한 예가 있음.
Splink와 DuckDB를 활용한 방식이 정말 마음에 듦. DuckDB의 성능 덕분에 Spark 기반 대규모 배포가 줄어드는 추세인지 궁금함. DuckDB를 쓸 수 있다면 Spark의 복잡성을 감수하기 어려워 보이는데, 최종 사용자들이 여전히 Spark를 선택하는 이유가 있는지?
이제 클라이언트-서버 구조로 사용할 수 있다는 점이 판도를 바꿀 만함. 많은 서버와 막대한 CPU·메모리를 쓰는 데이터 스택 상당수를 대체할 것으로 봄.
서버라고 해도 여전히 프로세스 내부에서 실행되므로 가볍고 단순하게 유지된다는 점이 정말 좋음.
HTTP 서비스나 로드 밸런서 뒤에 두고 자원 사용량에 따라 수평 확장하거나, Cloud Run 등으로 인스턴스 수를 0까지 축소할 수 있다는 점이 기대됨.
적당히 큰 클라우드 VM에서, 특히 Iceberg를 쿼리할 때 매우 빠름. 소규모 조직의 중앙 분석 서버로 알파 버전을 운영 환경에서 사용 중임. Postgres 통신 프로토콜이나 Arrow Flight로 접속할 수 있는 DuckDB 확장을 만들었음. DuckDB 자체 Quack 프로토콜도 있지만 아직 클라이언트 지원이 매우 제한적인 반면, 많은 데이터 도구가 Postgres 통신 프로토콜이나 Arrow Flight와 함께 쓸 수 있는 ADBC를 지원함. https://github.com/sidequery/duckflight-extension
분석 엔진으로도 훌륭하지만, 데이터 수집과 구조 변환에도 놀라울 만큼 다재다능한 소프트웨어임.
DuckDB 활용처를 회사에서 찾기가 어려웠지만 정말 써보고 싶음. 다들 어디에 사용 중인지?
서버와 브라우저에서 동일한 SQL로 쿼리하는 데 사용함. Google Capacitor의 데이터 배치 기법들을 적용하면 duckdb-wasm으로 브라우저 쿼리 엔진에 약 200만300만 행을 1620MB로 전달할 수 있음. 캐시 제어를 곁들인 HTTP 범위 요청으로 약 1GB까지 확장 가능함.
후속 질문이 생길 때마다 Jev로 1~2초 안에 SQL 쿼리를 작성함. 이를 위해 약간의 준비가 필요하지만, 공동 창업자가 몇 년 전 선견적 쿼리 실행에 관한 논문을 쓴 적이 있음.
같은 애플리케이션에 사용자 3,000명이 접속해도 각자 자신의 CPU로 DuckDB를 실행함. 이 접근법으로 데이터 큐브의 연산 확장 문제를 해결함. [1] - https://dl.acm.org/doi/10.14778/2733004.2733064.
개인이나 소규모 팀이 쓰는, 그리 크지 않은 빅데이터가 있는지? 많은 회사가 데이터를 중앙에 모으지만, 행 단위 보안 같은 실행 시점의 접근 제어는 까다로움. 사용자가 다루는 데이터가 GB나 MB 단위라면, 각자에게 허용된 데이터 전체를 제공하고 로컬에서도 쓰게 하는 DuckDB 방식이 좋은 대안임. 그러면서도 제대로 된 DB 도구와 성능을 누릴 수 있고, 기존 클라이언트-서버 방식보다 빠를 수도 있음.
예전에는 마케팅용 차원·사실 테이블을 만들고 권한과 보고서를 관리하면서 데이터 유출을 막아야 했음. 대신 기준 원천 데이터에서 추출·변환해 Parquet 파일을 만들고, DuckDB로 개인이나 팀의 보고서 도구와 임시 분석에 제공할 수 있음. 추출·변환 작업에는 AI 활용도 검토할 만함. 내 경험상 초기 투자는 크지 않은데, 장기적인 확장·접근 제어 부담이나 사용자 테이블을 잘못 조인하는 쿼리에 대한 걱정을 덜어줌. 실제로 대부분 회사의 데이터는 많아야 수 TB 정도이며, DuckDB로 충분히 처리 가능함.
최근 Parquet 파일을 기록하는 Rust 프로파일러에 사용함. DuckDB 덕분에 요약·분석과 실행 회차 간 조인을 간단한 SQL로 처리할 수 있음.
CSV·JSON 파일 조회에 사용함. 형식 간 변환도 한 줄로 처리 가능함.
로그 처리·집계 도구를 만들어보면 좋겠음!
트리거가 정말 기대됨. 이제 DuckDB가 하나로 완결되는 데이터 웨어하우스에 상당히 가까워짐.
DuckDB 2.0이 Parquet·CSV 읽기에 비동기 I/O를 도입한다는데, 자체 DuckDB 형식은 이미 지원한다는 뜻인지, 아직 지원하지 않는다는 뜻인지?
현재는 DuckDB 자체 형식과 JSON 모두 동기 I/O를 사용함.
비동기 I/O의 이점은 주로 원격 데이터 접근에서 나오지만, 캐시되지 않은 로컬 데이터 읽기에도 그보다는 작은 효과가 있음. 다음으로 JSON과 DuckDB 자체 파일의 비동기 읽기를 추가할 계획이며, 코어 외부 확장에서 제공하는 형식은 아직 로드맵에 없음.
DuckDB UI 노트북을 파일로 저장할 수 있는지?
CSV와 Parquet 파일에 비동기 I/O를 사용하면 어떤 이점이 있는지?
데이터가 도착할 때까지 작업 스레드가 대기하며 놀지 않게 해 가용 대역폭을 더 충분히 활용할 수 있음. 요청과 처리를 독립적으로 관리하므로 자원 활용률과 성능이 좋아짐.
S3나 HTTP/S를 통한 접근처럼 네트워크 부가 비용이 있고, -*.parquet 같은 글로브 패턴으로 한 쿼리에서 여러 파일을 읽을 때 효과가 가장 큼. 로컬 I/O에도 적용될 것으로 보지만, 지연 시간이 짧으므로 개선 폭은 더 작을 듯함.