DuckDB 2.0、S3クエリが3倍速くなる理由
Why DuckDB 2.0 is faster
DuckDB 2.0のalpha版が登場。非同期I/OによりS3上のParquet読み込みが2〜3倍高速化し、クエリ変更は不要。再帰CTEは2万コミットの履歴走査を0.1秒に短縮。VARIANT型はJSON文字列より2.7倍小さく、フィールドアクセスは6倍速い。ただし、小さなファイルやリストキャストには効果が限定的。
ネットワークとCPUが同時にビジーになる。
HNでの議論
61- scythmic_waves
ビジュアライゼーションは私も気に入っているけど、文章からは強烈にLLMの香りがする：
> これを駆動する設定が一つあって、...
> コストは実際に触る行数で決まるようになり、ラウンド数×テーブルサイズではなくなった。
などなど。
仕事でこの文体を解読しようとすると脳がバグる[1]ので、他の場所で見るのは嫌だ。間違っていたら申し訳ない。でも間違っていないなら、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でトリガーが追加されたという事実に触れた部分で、記事がそれを、遅い接続でのS3ファイルアクセス向けにワーカーを最適化することに比べて「まあまあ」程度だと判断したのには参った。いや、自分でリリースノートを読むよ。
- rumbledownunda
次のJupyterノートブックで試してみるつもり。
- jiggawatts
Umbra / CedarDB のようなタスクベースの設計を使うデータベースエンジンがもっと増えてほしい。
世の中のほとんどのDBエンジンは、いまだにexchangeオペレーションを伴う「nスレッド」スタイルの並列性と、お粗末な非同期I/O管理を使っているように見える。
DuckDBはこの面で改善しているが、ある意味では今や数十年も前のR&D（そして実装！）に追いつこうとしているだけだ。
こうしたシステムに取り組むソフトウェア開発者によく投げかける「修辞的な挑戦」がある：もし私が1,024コアと、それに見合うネットワーク帯域とストレージ帯域を備えたコンピュータを渡したら——ただしレイテンシはかなり大きい——君はこのようなシステムを1つのクエリで100%使い切れるか？
ほとんどすべてのソフトウェアの答えは「ノー」だ。
例えば、SQL Serverは1つのクエリで最大64ハードウェアスレッドまでしか使えない：https://learn.microsoft.com/en-us/sql/database-engine/config...
GPUのコードはそこに近づきつつあるが、CPUのコードはコンピュータサイエンスのこのフロンティアでは遥かに遅れている。
これはデータベースだけの話ではない！ファイルを並列に（解）圧縮できるか？そのハッシュを並列に検証できるか？CPUとI/Oのタスク並列性をもってストレージからアップロード/ダウンロードできるか？これらすべての操作を重ね合わせて、待つ必要のないものを待つことのないようにできるか？
これは重要だ！バイオインフォマティクスのコードでいくつかテストを走らせたところ、ほとんどがタールピットにはまって動けなくなっていた。何百万ものIOPSを持つ現代のSSDや、数百ギガビットのスループットを持つ現代のネットワークに、どれだけCPUコアを投じてもスケールできないものが多かった。
PS: AMDのZen 6世代EPYC 9006プロセッサは51 […]