DuckDB v2.0、非同期I/OでS3からのクエリが最大3.7倍高速化
Asynchronous I/O in DuckDB: Work, Thread, Work
DuckDBは2026年秋リリース予定のv2.0から、ParquetとCSVファイルの非同期読み取りをデフォルトでサポートします。これにより、EC2/S3構成などで同期I/Oが帯域幅を活かしきれない場合に、クエリを大幅に高速化できます。TPC-H Query 6 (SF100) のベンチマークでは、S3上の22GBのParquetファイルで実行時間が8.230秒から2.844秒に短縮され、さらにチューニングにより2.227秒（v1.5.5比3.7倍）を達成しました。非同期I/Oは、専用のASYNCスレッドプールと先読みキューを備え、メモリ管理も行われます。
It doesn't matter how fast query operators are in a database system if we can't pull in the data quickly.
HNでの議論
31- diarrhea
ワーカープールがコア数と同じ数のスレッドを保持するのは、非同期プールとうまく共存できるのでしょうか？基本的に設計上オーバーサブスクリプションになっています。
私はかつて、6 vCPUのシステム上で、Rayonのワーカースレッドプール（4スレッド）とTokioの非同期プール（2スレッド、マルチスレッドランタイム）を持つシステムを構築したことがあります。これは結局うまく機能しました。Tokioはスターveされず、ネットワークリクエストを低レイテンシで処理できました。
1つの違いは、DuckDBは純粋なネットワーククライアントであることです。非同期スレッドの1つがスターveされても、それは世界の終わりではありません（例えば、k8sはヘルスチェックへの応答失敗でポッドを殺したりしません）。
- bburnett44
22GBのリモートファイルに対して512GBのRAMを使うのは、ベンチマークとしては少し変に感じますが、もしかしたら大量のメモリなしでは多数のコアを用意できなかったのかもしれませんね。
- NorthSouthNorth
このような非同期I/Oアーキテクチャへの深掘りは、高性能データ処理にとって純粋なエンジニアリングの宝です。素晴らしい解説です。