行指向ストレージと列指向ストレージ

同じ表でも「並べ方」で性能が変わる

リレーショナルな表は論理的には行と列の二次元ですが、ディスクやメモリは一次元の連続バイト列です。二次元の表を一次元に どう写すか――この物理レイアウトの選択が、圧縮率・スキャン量・OLTP/OLAP 適性を根本から決めます。代表的な選択肢が 行指向（row-oriented / NSM） と 列指向（column-oriented / DSM） です。

例として orders(id, user_id, amount, status) という4カラムの表を考えます。

行指向（NSM: N-ary Storage Model）
ブロック内: [id1,user1,amount1,status1][id2,user2,amount2,status2]...
            └─ 1行が連続 ─┘

列指向（DSM: Decomposition Storage Model）
id列:     [id1, id2, id3, ...]
user_id列:[user1, user2, user3, ...]
amount列: [amount1, amount2, amount3, ...]
status列: [status1, status2, status3, ...]

行指向は「1行の全カラム」が物理的に隣り合います。列指向は「1カラムの全行の値」が隣り合います。どちらも同じデータですが、後段の処理特性がまったく変わります。行をまたいで同じカラムを縦に走査するのが集計、1行の全カラムを横に取り出すのが業務処理――という対比を念頭に置くと理解が早いです。

スキャン量：読まないカラムは読まない

SELECT SUM(amount) FROM orders WHERE status = 'paid' のような集計を考えます。必要なのは amount と status の2カラムだけです。

• 行指向: 1行が連続配置されているため、amount を読むには id や user_id も含む行全体がストレージブロックに同居します。ブロック単位の I/O では、関心のないカラムも巻き込んで読むことになります。
• 列指向: amount 列と status 列のブロックだけを読めばよく、id・user_id 列のブロックには一切触れません。これを 射影プッシュダウン（projection pushdown） と呼びます。

カラム数が N で、集計が k カラムだけを使うとき、列指向が読む I/O 量は素朴には k / N の割合まで減ります。広い表（N が大きい）で少数カラムを集計する OLAP では、この差が支配的です。逆に「1行の全カラムが欲しい」点取得は、列指向だと N 個のブロックを別々に読んで再構成する必要があり不利になります。

圧縮効率：同型の値が並ぶ強み

列指向の二つ目の武器が圧縮です。圧縮は 似たデータが近くにあるほどよく効くという性質を持ち、列指向は「同じカラムの値＝同じ型・近い分布」を連続配置するため、行指向より格段に有利です。

• RLE（Run-Length Encoding）: status のように取りうる値が少ないカラムをソートしておくと paid,paid,paid,... と同値が連続し、(paid, 1000回) のように畳める。
• 辞書符号化（dictionary encoding）: 低カーディナリティのカラムで、実値を小さな整数 ID に置き換え、ID 列を格納する。{tokyo,osaka,...} を {0,1,...} にすると、4バイト整数どころか数ビットで足りる。
• ビットパッキング / フレーム・オブ・リファレンス: 整数列の値域が狭ければ、必要ビット数だけに詰める。連番に近い id は差分（delta）化してから詰めるとさらに縮む。

辞書や RLE で符号化した列は、復号せずに圧縮されたまま述語評価できることがあります。status = 'paid' を辞書 ID 0 への等値比較に変換すれば、整数比較で済みます。圧縮はストレージ削減だけでなく、I/O と CPU の双方を減らす点が本質です。行指向では1行内に型の異なる値が混在するため、ここまで強い符号化は効きません。

OLTP と OLAP：なぜ適性が分かれるか

ここまでの性質が、そのまま OLTP / OLAP の適性差になります。

列指向で INSERT が不得意なのは、1行を足すだけで N 個のカラム領域すべてに値を追記し、各々の符号化・圧縮を更新する必要があるためです。さらに行の途中更新は圧縮ブロックの再構成を招きます。そこで分析系エンジンは更新を 追記中心で扱い、変更を別領域に溜めて後でまとめて反映する設計を採ります。この「追記して後で畳む」発想は LSM-Tree と同根で、ランダム更新を避けてシーケンシャルに均すという点で共通しています。点更新の局所性が要る OLTP では B+Tree 系の行指向ストレージ が依然として主役です。

ベクトル化実行：列指向の本領

列指向の真価は、ストレージ削減以上に 実行モデルにあります。従来の行指向エンジンは「1行を取り、式を評価し、次の行へ」という 火山（Volcano）モデルで、行ごとに next() を呼びます。これは1値あたりの関数呼び出しや分岐のオーバーヘッドが大きく、CPU が遊びます。

列指向では値が型のそろった配列として並ぶため、1行ずつではなくカラムの一塊（バッチ、典型的には1000〜数千値）をまとめて処理できます。これが ベクトル化実行（vectorized execution） です。

スカラ実行（行ごと）:
  for row in rows: out[row] = a[row] + b[row]   # 1値ごとに呼び出し・分岐

ベクトル化実行（バッチ単位）:
  add(out_vec, a_vec, b_vec, n=1024)  # 配列をまとめて1関数で処理

ここで効くのが次の3点です。

• SIMD: 連続した同型配列は、1命令で複数要素を同時計算する SIMD 命令に乗せやすい。amount 列の合計は8値・16値を一度に足し込める。
• CPU キャッシュと予測: 同型値の連続アクセスはキャッシュ効率がよく、分岐がループ外に出るため分岐予測も当たりやすい。
• 解釈オーバーヘッドの償却: 関数呼び出し1回でバッチ全体を処理するため、1値あたりの固定費が 1 / バッチサイズ に薄まる。

JIT で式をネイティブコードへコンパイルする方式もありますが、ベクトル化は事前コンパイル済みの型別カーネルを束ねるだけで近い効果を、より単純な実装で得られます。クエリオプティマイザ が選んだ実行計画を、この列バッチのパイプラインで流すのが現代の分析エンジンの基本形です。

まとめ