DuckDB 2.0 알파, S3 읽기가 2배에서 3배 빨라져 쿼리 수정 없이 적용됨
- 비동기 I/O로 S3 Parquet 읽기가 1.5.5 대비 2배에서 3배 빨라짐, 2.2GB 파일 한 컬럼 조회는 18.8초에서 7.7초로 줄어듦
- read_ahead_depth 기본값이 -1이라 비동기 I/O가 기본으로 켜져 있고, 0으로 설정하면 1.5 방식으로 돌아감
- 다운로드 풀이 워커보다 앞서 여러 row group을 받아 두어서 네트워크와 CPU가 동시에 바쁘게 돌아감
- 작은 Parquet 파일 30개(각 약 1MB)에서는 3.7초에서 3.3초로 거의 변화가 없음, 파일별 왕복 횟수가 병목이라 read-ahead로 줄지 않음
- DuckDB 팀이 재귀 CTE 엔진을 다시 작성해 그래프 도달성 계산에서 40배 향상을 주장함, 저자는 이 부분을 자세히 검증하지 않음
Hacker News 의견들
시각화는 진짜 좋은데 글에서 LLM 냄새가 심함. 'One setting drives this' 같은 문장 읽다 보면 머리가 멍해짐. 작업 중에 이런 글 읽는 게 제일 힘듦.
그럼 본인 글을 LLM에 먹여서 그 스타일로 다시 쓰게 하면 되지 않나. 우리 팀장이 보고서 그렇게 만들었는데 본인이 만족함.
나는 LLM 냄새를 거의 못 느꼈음. 글이 좀 헤매는 느낌은 있었는데 읽을 만은 했음.
Triggers 추가는 별거 아닌 것처럼 넘기고 S3 워커 최적화만 강조하는 게 불만임. 결국 릴리스 노트는 직접 봐야 할 듯.
재귀 CTE 부분은 설명이 부실함. 40배라고만 하고 어떻게 최적화했는지 안 나와서 DuckDB 공식 블로그 글을 따로 찾아봐야 했음.
C++ 확장 API가 개발이랑 배포 쪽에서 더 빨라진다는 얘기는 개인적으로 제일 반가움.
DB 대부분이 아직 n-thread 방식이라 async I/O 관리가 허접함. Umbra나 CedarDB 쪽 task 기반 설계가 맞는 방향으로 보임. SQL Server는 쿼리 하나에 스레드 64개가 한계라고 함.
파일 전체를 해시하는 거면 병렬화가 안 되는 게 맞음. 청크로 나눠서 해시하면 가능하긴 함.
Umbra랑 CedarDB 둘 다 오픈소스가 아님. 말만 많고 직접 볼 수 있는 게 없음.