DuckDB 2.0, 쿼리 한 줄 안 바꾸고 S3 읽기 2~3배 빨라졌다
Why DuckDB 2.0 is faster
DuckDB 2.0 알파를 직접 노트북과 S3에서 테스트한 결과, async I/O가 기본으로 켜져 2.2GB Parquet 파일 읽기가 18.8초에서 7.7초로 줄었다. 재귀 CTE 엔진은 2만 커밋 git 이력을 1.8~16초에서 0.1초로 단축했고, VARIANT 타입은 JSON 문자열보다 저장 공간이 2.7배 작고 필드 쿼리는 약 6배 빠르다. 다만 리스트 캐스팅은 아직 느리다.
2.0은 예전에 그래프 데이터베이스에 밀어 넣던 작업을 평범한 쿼리로 바꿔준다.
HN 토론
61- scythmic_waves
시각화도 정말 마음에 들지만, 문체에서 LLM 냄새가 너무 강하게 난다:
> 설정 하나가 이걸 좌우한다,...
> 비용은 이제 실제로 건드리는 행 수에 달려 있지, 라운드 수 곱하기 테이블 크기가 아니라.
등등.
직장에서 이런 문체를 해석하려다 뇌가 녹아버릴 것 같아서, 다른 곳에서 보는 건 괴롭다. 내가 틀렸다면 사과한다. 하지만 아니라면 OP는 LLM한테 글을 쓰게 하지 마라. 독자 건강에 해롭다 [2].
[1]: https://www.youtube.com/watch?v=ipUJq-odt5Q
[2]: https://discourse.haskell.org/t/how-to-keep-enjoying-program...
- stacktraceyo
시각화 훌륭하다. 덧붙이자면, 새 C++ 확장 API도 그 확장들을 개발/배포하는 관점에서 더 빨라질 거다.
- robertclaus
AI가 쓴 글이라도 2.0에 트리거(Triggers)가 추가됐다는 부분까지는 괜찮았는데, 글쓴이가 그걸 느린 연결에서 S3 파일 접근을 위해 워커를 최적화하는 것보다 별로라고 판단한 순간 끝났다. 아니다. 릴리스 노트는 내가 직접 읽겠다.
- rumbledownunda
다음 주피터 노트북에서 한번 써볼 생각이다.
- jiggawatts
Umbra / CedarDB처럼 태스크 기반 설계를 쓰는 데이터베이스 엔진이 더 많아졌으면 좋겠다.
세상에 나와 있는 대부분의 DB 엔진은 여전히 교환 연산과 형편없는 비동기 I/O 관리가 있는 "n-스레드" 스타일 병렬성을 쓰는 것 같다.
DuckDB는 이 부분에서 개선되고 있지만, 어떤 의미에서는 이미 수십 년 된 R&D(그리고 구현!)를 따라잡고 있는 셈이다.
이런 시스템을 만드는 소프트웨어 개발자들에게 내가 좋아하는 "수사학적 도전"이 하나 있다: 만약 내가 1,024개의 코어와 그에 맞는 네트워크 및 스토리지 대역폭을 가진 컴퓨터를 준다면 -- 다만 지연 시간은 상당하다 -- 쿼리 하나로 이런 시스템을 100% 활용할 수 있겠는가?
거의 모든 소프트웨어의 답은 "아니오"다.
예를 들어, SQL Server는 단일 쿼리에 대해 하드웨어 스레드 64개에서 상한이 걸린다: https://learn.microsoft.com/en-us/sql/database-engine/config...
GPU 코드는 이제 거기에 도달하기 시작했지만, CPU 코드는 컴퓨터 과학의 이 frontier에서 훨씬 뒤처져 있다.
데이터베이스만 그런 게 아니다! 파일을 병렬로 (압축)해제할 수 있는가? 해시를 병렬로 검증할 수 있는가? CPU와 I/O 태스크 병렬성으로 스토리지에 업로드/다운로드할 수 있는가? 이 모든 작업을 겹쳐서, 굳이 기다릴 필요 없는 것 때문에 멈추는 일이 없게 할 수 있는가?
이건 중요하다! 생물정보학 코드로 몇 가지 테스트를 해봤는데 대부분 타르 구덩이에 빠져 있었다. 많은 코드가 CPU 코어를 아무리 많이 던져줘도 수백만 IOPS의 최신 SSD나 수백 기가비트 처리량의 최신 네트워킹으로 확장하지 못했다.
추신: AMD의 Zen 6 시대 EPYC 9006 프로세서는 51개 [...]