# The Query Performance Spectrum ## 概要 DuckDB開発者 Torsten Grust(University of Tübingen)による講義シリーズ「Design and Implementation of DuckDB Internals(DiDi)」第2回のスライド。TPC-H `lineitem` テーブル(SF=1、6+百万行・16列・約720MB)の `quantity` 列を合計するだけの単純なクエリを題材に、awk・Python・C(getline)・C(mmap)・C(mmap+ブロック単位改行検索)・C(mmap+マルチスレッド)・SQL(DuckDB)の7実装を実測比較し、同一クエリの実行時間がハードウェアの限界(CPU/DRAM/ SSD 帯域)にどれだけ近づけるかという「性能スペクトラム」を示す。DBMS内部のパフォーマンスエンジニアリングが積み上げる最適化(システムコール削減・ワード単位処理・並列化)を、実装コードと計測値とともに段階的に提示する回である([[.raw/slides/duckdb-didi-02-query-performance-spectrum/duckdb-didi-02-query-performance-spectrum.pdf]])。 ## 主要メッセージ - クエリ実行時間はハードウェア限界(Torstenの MacBook Pro M2 Max: DRAM 21 GB/s、NVMe SSD 5 GB/s、外部USB-C SSD 800 MB/s)を上限とし、DBMS内部実装はこの限界へどこまで近づけるかを競う(p.4)。 - 逐次的なインタプリタ言語(awk、Python)はCPUバウンドとなり、OSファイルシステムキャッシュの恩恵を受けられない(p.6, p.7)。 - コンパイル言語(C)でも標準ライブラリ関数(`getline`・`atoi`・`strchr`)の呼び出しコストが支配的になりうる。プロファイルで「どこに時間が消えているか」を特定することが最適化の出発点となる(p.9)。 - `mmap(2)` によりファイル全体を1回のシステムコールでDRAMへマップし、行指向の逐次読み込みを回避できる。ただしOSファイルシステムキャッシュが温まっていない(cold)場合はディスクI/Oが支配的なままである(p.10, p.12)。 - 改行検索を64bit語単位のビット演算(SWAR: HAS_ZERO/HAS_NL マクロ)に置き換えると、バイト単位ループの53.1%のCPU時間を解消し、組み込み`strchr()`に匹敵する性能へ到達する(p.13-15)。 - マルチコア(T=12)を用いたチャンク分割並列化で18.8 GB/sに達し、DRAM帯域にほぼ到達する(p.16-19)。 - DuckDBのSQL `sum()` はこれらの手作業最適化に匹敵する約0.45秒(real)を達成し、`EXPLAIN`/`EXPLAIN ANALYZE`で内部実行計画・並列処理の可視化ができる(p.20-21)。 ## 視覚的に重要な図表 **p.4 ハードウェアの性能限界** ![[_attachments/duckdb-didi-02-query-performance-spectrum/page-004.png]] Torstenの実機(M2 Max)における一次記憶(DRAM 21 GB/s)・二次記憶(NVMe SSD 5 GB/s、外部USB-C SSD 800 MB/s、Ethernet 2.5 GB/s)の読み取り帯域とそれぞれを前提とした理論クエリ時間の対応表。CPUコストを無視した理論上限であり、DuckDBは0.002秒でこのクエリを処理する(補足として明示)。 **p.10 mmap(2)によるファイルのDRAMマッピング** ![[_attachments/duckdb-didi-02-query-performance-spectrum/page-010.png]] `mmap(NULL, size, PROT_READ, MAP_SHARED, file, 0)` によって720MBのCSVファイルをディスクから単一システムコールでDRAM上の連続領域に1:1マップする図。DRAMを超えるサイズならOSがオンデマンドでページインする。 **p.13 64bit語単位の改行検索(SWARビットトリック)** ![[_attachments/duckdb-didi-02-query-performance-spectrum/page-013.png]] `HAS_ZERO(x)`/`HAS_NL(x)` マクロで8バイト(64bit)を一括ロードし、XORとビットマスクだけで改行(`\n` = 0x0a)の有無・位置を検出する手法。1バイトずつの `strchr` 相当ループより高速な理由を示す(Stanford Bit Twiddling Hacksの技法を援用)。 **p.21 7実装の性能比較サマリ** ![[_attachments/duckdb-didi-02-query-performance-spectrum/page-021.png]] awk(1.60s, 471 MB/s)からC+mmap+12スレッド(0.04s, 18.8 GB/s)まで、実装言語・技法による約40倍の性能差を一覧化した表。DuckDB SQLは別スライド(p.20)で約0.45秒(3.32s分のCPU時間を並列に消費)。 ## 概念・実体への接続 - [[DuckDB]] — 本スライドの題材となる組み込み分析データベース。既存の[[@2019__SIGMOD__DuckDB - an Embeddable Analytical Database]]の実装内部を担当者自身が解説する続編に当たる。 - [[列指向OLAPデータベース]] — DuckDBのクエリ性能を支えるアーキテクチャ文脈。 - クエリ実装のハードウェア限界追跡(mmap、SWARビット演算、マルチスレッド分割)は本ソース固有の観察であり、今回新規の[[クエリ性能スペクトラム]]として概念化した。 ## 限界・不確実点 - タイトルスライド(p.1)には発表日として "April 7, 2026" と明記されているが、DuckDB公式ページ(`https://duckdb.org/library/design-and-implementation-of-duckdb-internals/`)のJekyll SEOメタデータでは `article:published_time` / `article:modified_time` がともに `2026-03-19` になっている。後者はコースページ全体(全チャプター一覧)の最終更新日時である可能性が高く、本チャプター固有の講義日はスライド記載の2026-04-07を優先したが、確証がないため `confidence: medium` とする。 - p.9のCPU時間内訳円グラフはページ内の数値ラベル(58%/14%/12%/16%)を読み取ったが、円グラフ自体の角度と数値の対応は目視確認のみで、元データは未取得。 - p.20のDuckDB実行環境(スレッド数・DuckDBバージョン)はスライドに明記されておらず、`EXPLAIN ANALYZE`の詳細な実行計画画面も本チャプターには含まれない(次章以降で扱われる可能性がある)。 - 音源・動画・transcriptは提供されておらず、口頭説明は反映していない。