ベクトル化クエリ実行

なぜ行単位処理は分析で遅いのか：Volcanoモデルの限界

分析クエリ（数億行を集約・フィルタ・結合する OLAP）を速くしたい。まず立ちはだかるのが、伝統的なクエリ実行の骨格である Volcanoモデル（反復子モデル） です。各演算子（スキャン、フィルタ、集約、結合）が next() を持ち、上位が呼ぶたびに 1行（タプル）を1件返す 。これは美しく汎用的で、任意の演算子を組み合わせられます。しかし分析ワークロードでは原理的に遅い。

理由は、返す価値のある「実データの処理」に対して、制御のオーバーヘッドが1行ごとに丸ごとかかることにあります。

• 仮想関数呼び出しのコスト。next() は演算子ごとに実装が違う仮想呼び出しで、1行につき演算子の段数ぶん発生する。呼び出し自体のコスト（間接ジャンプ、レジスタ退避）が実処理に匹敵する。
• 分岐予測ミス。演算子ごとの型判定や NULL 判定が1行ごとに走り、CPUのパイプラインが乱れる。
• 命令キャッシュの汚染。1行のために多数の演算子コードを行き来するので、命令が局所化されず、CPUが同じコードを繰り返し実行する利点を失う。

10億行なら、この固定費が10億回。「1行あたりの実処理は数ナノ秒なのに、その周りの制御に十数ナノ秒かかる」 という逆転が起きます。OLTPのように数行を触るだけなら誤差ですが、全行を舐める分析では致命的です。

ベクトル化：一括処理で固定費を割り勘にする

ベクトル化実行（vectorized execution） は、next() が1行ではなく 列の値を数千件まとめた「バッチ（ベクトル）」を返す ように変えます。MonetDB/X100 が示した定石で、典型的なバッチは 1024〜数千要素。演算子は1呼び出しの中で、タイトなループでバッチ全要素を処理します。

# 行単位（Volcano）：1行ごとに next() と型判定
for 各行:
    row = child.next()          # 仮想呼び出し（1行ぶん）
    if row.price > 100: emit(row)   # 分岐（1行ぶん）

# ベクトル化：1バッチ = 1回の呼び出しで N 件をループ
batch = child.next_batch()      # 仮想呼び出しは N 件で1回
prices = batch.column("price")  # 連続した配列
for i in 0..N:                  # 単純ループ（コンパイラが最適化しやすい）
    result[i] = prices[i] > 100

効くポイントは3つあります。第一に、仮想関数呼び出しがバッチ単位になり、1行あたりの呼び出しコストが N 分の1に薄まる。第二に、ループ本体が単純で型が固定なので、分岐が減り、CPUの分岐予測が当たりやすい。第三に、同じ演算子コードを N 回連続実行するので命令キャッシュが効き、CPUが投機的実行・パイプライン化をフルに使えます。処理は行の集合ではなく 列ごとの配列 に対して進むため、列指向ストレージ（/database/ の列ストア）と自然に噛み合います。

SIMDとキャッシュ効率：ハードウェアを使い切る

ベクトル化の真価は、列を連続配列で持つとハードウェアの並列性を引き出せる点にあります。

CPUには SIMD（Single Instruction, Multiple Data） 命令があり、1命令で複数のデータ要素を同時に処理します。AVX-512 なら512ビット幅、32ビット整数を 一度に16個 足せます。列の値が隙間なく並んでいれば、コンパイラの 自動ベクトル化 がループを SIMD 命令に置き換えたり、エンジンが手書き SIMD で述語評価・集約・ハッシュ計算を一括化できます。行指向でフィールドが構造体に散っていると、この一括ロードができません。

もう一つが キャッシュ効率 です。CPUはメモリを キャッシュライン（例 64バイト）単位 で読みます。列を連続配置すれば、1ラインのフェッチで必要な値だけが密に載り、無駄がありません。

述語評価も分岐を避ける形に変わります。price > 100 を各行で if するのではなく、全要素を比較して真偽を配列（マスク）に書き出し、通過した行の位置だけを 選択ベクトル（selection vector） に集めて後続へ渡す。分岐の代わりに算術と添字操作で進むので、パイプラインが乱れません。さらに列が 辞書エンコード（値を整数IDに置換）されていれば、比較や集約を整数IDのまま実行でき、メモリ帯域と計算量をさらに削れます。ここは圧縮された列を展開せずに処理するという分析基盤特有の最適化で、ビッグデータ処理でこそ効きます。

コード生成：もう一つの高速化軸

固定費を潰すアプローチはベクトル化だけではありません。コード生成（code generation / query compilation） は、クエリごとに 専用の機械語を実行時に生成（JITコンパイル） します。HyPer が広めた データ中心（data-centric）／プッシュ型 モデルが代表で、演算子の抽象を消し去り、そのクエリだけのループへ融合します。

Volcanoの「1行ごとに仮想 next()」も、ベクトル化の「バッチを跨ぐたびに中間ベクトルをメモリへ実体化」も無くし、1行をレジスタに載せたまま、フィルタ→計算→集約を一気通貫で処理する。これを パイプライン融合（operator fusion） と呼びます。

両者は競合ではなく 相補的 です。ベクトル化は実装・デバッグが容易で、SIMD を効かせやすく、起動が速い。一方でバッチ境界ごとに中間結果をメモリへ書き戻す実体化コストがあります。コード生成はその実体化を消せますが、クエリごとのコンパイルに時間がかかり、短いクエリでは割に合わず、生成コードのデバッグも難しい。

分析基盤での位置づけ：なぜ今これが標準なのか

ベクトル化は単体エンジンの小技ではなく、現代の分析・レイクハウス基盤の共通土台になっています。クラウドの列指向ウェアハウスや、Spark を高速化する Photon、Presto/Spark 系の実行を差し替える Velox、組み込み分析の DuckDB、カラム型 OLAP の ClickHouse は、いずれもベクトル化実行を中核に持ちます。

その背景には分散データ処理特有の事情があります。第一に、分析基盤のデータは Parquet / ORC など列指向フォーマットで貯まっており、列を連続で読む実行モデルと最初から相性が良い。第二に、S3 などのオブジェクトストレージからの読み出しは帯域が貴重なので、使う列だけ・圧縮のまま処理する列指向＋ベクトル化が I/O 削減に直結する。第三に、1ノードのCPUを使い切る垂直効率を上げることは、同じ処理をより少ないノードでこなせることを意味し、分散クラスタのコストを直接下げます。

まとめ

• 分析クエリでVolcanoモデル（1行ずつ next()）が遅いのは、仮想関数呼び出し・分岐予測ミス・命令キャッシュ汚染という固定費が行数に比例して積み上がるため。実計算より段取りが重い。
• ベクトル化は処理単位を**列のバッチ（数千行）**に変え、固定費をN分の1に割り勘にする。ループが単純化し分岐予測が当たり、命令キャッシュも効く。
• 列を連続配列で持つと SIMD（1命令で複数要素）とキャッシュライン利用率が最大化し、述語はマスク＋選択ベクトル、圧縮列は辞書エンコードのまま処理して帯域を節約できる。バッチはキャッシュに収まる大きさが最適。
• コード生成（JIT）は演算子抽象を消してパイプライン融合し、中間結果の実体化を無くす別の高速化軸。ベクトル化とは相補的で、実体化コストとコンパイルコストのどちらを払うかの選択。
• 両者は突き詰めると性能が拮抗し、Photon・Velox・DuckDB・ClickHouse など現代の分析基盤はベクトル化を土台に両取りする。列指向フォーマット・オブジェクトストレージ・分散コストの事情がこれを標準にした。