カラム指向ストレージ(Columnar Storage)

1. 概要

A. 定義

カラム指向ストレージ(列指向ストレージ)とは、一つのテーブルを行単位ではなく列単位で物理的に連続配置し、同じ属性の値をまとめて格納・圧縮・スキャンするストレージモデル(DSM, Decomposition Storage Model)である。これは一行のすべての属性を連ねて格納する伝統的な行指向ストレージ(NSM, N-ary Storage Model)と対比され、大量データを対象に少数の列だけを集計・分析するOLAP・分析ワークロードに最適化された構造である。

B. 登場背景と必要性

伝統的なリレーショナルDBMSはオンライントランザクション処理(OLTP)を前提に設計された。注文一件を挿入したり特定顧客のレコード全体を照会したりする業務では、一行のすべての列をディスクの一箇所に連ねて置く行指向方式が有利である。一度のページ読み込みで必要なレコード全体を得られるからである。しかし2000年代以降、データウェアハウスとビジネスインテリジェンス(BI)が普及するにつれ、ワークロードの性格が根本的に変わった。「過去三年間の地域別売上合計」のように数億件の行を走査しながら実際に使う列は二つ三つだけという分析クエリが支配的になったのである。

こうしたクエリを行指向ストレージで処理すると深刻な無駄が生じる。売上列一つだけ必要でもディスクはページ単位で読まれるため、そのページに一緒に収められた顧客名・住所・商品説明など不要な列までもすべてI/Oで引き上げなければならない。列が100個あるテーブルで3個だけ使うクエリなら、理論上97%のI/Oが無駄である。ディスク帯域幅とメモリバスがボトルネックとなる大容量分析において、この無駄はそのまま応答時間とコストに直結する。

カラム指向ストレージはこの問題を正面から解決する。クエリに登場する列だけを選択的に読んで(projection pushdown)I/Oを最小化し、同じドメイン・同じ型の値が物理的に隣接するため圧縮率が劇的に高まり、値の配列を一度に処理するベクトル化(vectorized)・SIMD実行でCPUキャッシュ効率まで引き上げる。その結果、同一ハードウェアで分析クエリ性能が数倍〜数十倍向上し、今日ではほぼすべての分析エンジン(Redshift・BigQuery・Snowflake・ClickHouse・DuckDB)がカラム指向ストレージを採用している。

このアイデア自体は新しくない。学界では1980年代の分解格納モデル(DSM)研究から出発し、2000年代初頭にオランダCWIのMonetDBとマイケル・ストーンブレーカー(Michael Stonebraker)チームのC-Store(後に商用製品Verticaへ発展)がカラム指向ストレージの性能ポテンシャルを実証したことで、本格的に産業へ広がった。すなわちカラム指向ストレージは最新の流行ではなく、ワークロードがトランザクションから分析へ移るに従って長年の研究成果が主流技術として再浮上した事例に近い。

C. 特徴

選択的な列読み込み(I/O削減): クエリが参照する列だけをディスクから読み、不要なデータ転送を排除する。
高い圧縮率: 同一型・類似値が隣接するため辞書(dictionary)・RLE・デルタエンコーディングがよく適合し、一般に行格納比で2〜10倍圧縮される。
ベクトル化・SIMD親和性: 一つの列の値が連続配列であるため、反復演算をベクトル単位で処理しCPUパイプライン・キャッシュを効率的に使う。
集計最適化: SUM・AVG・COUNTなど列全体のスキャン・集計に強いが、単件の挿入・更新・削除(OLTP)には弱い。
統計ベースのスキッピング: 列チャンクごとにmin/maxなどの統計を併せて格納し、条件に合わないデータブロックを一切読まずに飛ばす。

2. 全体構造: 行指向 vs 列指向

行指向と列指向の違いは「論理的に同じ表をディスクにどう展開して置くか」にある。論理テーブルは同一だが、物理配置が変わることでI/O・圧縮・演算の特性が丸ごと分かれる。以下の構造図は、4つの列を持つテーブルが二つのモデルでそれぞれどう直列化されるかを示す。

flowchart TB
  T["論理テーブル(行 R1~R3 × 列 A~D)"]
  T --> NSM["行指向(NSM)"]
  T --> DSM["列指向(DSM)"]
  subgraph NSM_L["行指向の物理配置"]
    N1["ブロック: (R1.A R1.B R1.C R1.D)"]
    N2["ブロック: (R2.A R2.B R2.C R2.D)"]
    N3["ブロック: (R3.A R3.B R3.C R3.D)"]
  end
  subgraph DSM_L["列指向の物理配置"]
    D1["列 A: (A1 A2 A3)"]
    D2["列 B: (B1 B2 B3)"]
    D3["列 C: (C1 C2 C3)"]
    D4["列 D: (D1 D2 D3)"]
  end
  NSM --> NSM_L
  DSM --> DSM_L

上図で行指向は一行のA〜Dが一ブロックに連なっており「R2全体をくれ」という要求に強い。一方、列指向は列Aの値だけが別にまとまっており「すべての行のAを合算する」要求を一度の逐次スキャンで終える。この配置の違いがそのままワークロード適合性を決める。

各構成要素をもう少し掘り下げると次のとおりである。列チャンク(column chunk)は一つの列の値をまとめた物理単位で、ここにエンコーディング・圧縮が適用される。値そのもののほか、どの行がNULLかを示す定義レベル(definition level)・NULLビットマップ、および各値がどの論理行に属するかを辿るための行位置(ordinal position)情報が併せて管理される。列指向は行を丸ごと格納しないため、複数の列を結合して元の行を復元するタプル再構成(tuple reconstruction)が別途必要であり、このコストをいかに最小化するかがカラムエンジン設計の中核課題となる。

この物理配置の違いが実際の数値でどう現れるか例を挙げよう。列が50個で各行が平均500バイトの10億件テーブル(約500GB)で「売上列(8バイト)の合計」を求めるとする。行指向では原理的に500GB全体をスキャンしなければならないが、列指向では売上列だけを読むため約8GB(圧縮前)にアクセスすればよく、辞書・デルタエンコーディングで2GB前後まで減る。同じディスク帯域幅で読むべきデータが二桁倍減るわけで、これがカラム指向ストレージが分析クエリで圧倒的な優位を持つ根本理由である。

またカラム指向はスキーマ進化(schema evolution)にも柔軟である。列が独立して格納されるため、新列の追加は既存データを再書き込みせず新しい列ファイルを追加するだけでよく、特定列だけを別のエンコーディングで書き直す部分最適化も可能である。一方、行指向は列の追加・変更が行レコード構造全体に影響するため相対的に重い。このように物理配置一つの選択が、I/O・圧縮・演算だけでなくスキーマ運用のあり方まで連鎖的に規定する。

区分	行指向(NSM)	列指向(DSM)
物理配置	一行のすべての列が連続	一列のすべての値が連続
有利なクエリ	単件照会・挿入(OLTP)	大量スキャン・集計(OLAP)
圧縮率	低い(異種型が混在)	高い(同種値が隣接)
更新コスト	低い	高い(複数の列ファイルにアクセス)
代表システム	MySQL・PostgreSQL・Oracle	Redshift・ClickHouse・DuckDB

3. 中核技術: エンコーディング・圧縮と実行

カラム指向ストレージの性能は単に「列をまとめて置く」ことから生まれるのではなく、その上に載る軽量エンコーディング(lightweight encoding)とベクトル化実行で完成する。以下の詳細図は、生の列値がエンコーディング・圧縮を経て格納され、クエリ時にデータスキッピングと遅延マテリアライゼーションを通じて処理されるパイプラインを表す。

flowchart LR
  RAW["生の列値"] --> ENC["軽量エンコーディング(辞書·RLE·デルタ)"]
  ENC --> CMP["汎用圧縮(LZ4·Zstd)"]
  CMP --> STORE[("列チャンク格納(+ ゾーンマップ)")]
  Q["分析クエリ"] --> SKIP["データスキッピング(min/max ゾーンマップ)"]
  STORE --> SKIP
  SKIP --> SCAN["ベクトル化スキャン(SIMD)"]
  SCAN --> LATE["遅延マテリアライゼーション"]
  LATE --> RESULT["結果集計"]

A. 軽量エンコーディング。カラム指向ストレージが高い圧縮率を得る第一の理由は値の同質性である。辞書エンコーディング(dictionary encoding)は繰り返す文字列・カテゴリ値を整数コードに置換して格納サイズを減らし、整数比較だけでフィルタを行わせてCPU負担まで下げる。RLE(Run-Length Encoding)はソートや反復の多い列で「値+反復回数」で圧縮し、デルタエンコーディング(delta encoding)はタイムスタンプ・連番のように増加傾向が明確な列で前の値との差だけを格納する。ここにビットパッキング(bit-packing)を組み合わせると、実際の値範囲に合う最小ビット数だけを使う。例えば国コード列(値の種類が数百個)は辞書エンコーディングで原本の10%以下に減り、秒単位で増えるログのタイムスタンプはデルタ+ビットパッキングで大幅に圧縮される。

エンコーディング技法は列のデータ特性に合わせて選択される。以下の表は代表的なエンコーディングと、それがよく適合する列の種類、そして期待効果をまとめたものである。実際のエンジンは列ごとの統計を見てエンコーディングを自動選択したり(例: カーディナリティが低ければ辞書エンコーディング)、複数の技法を段階的に組み合わせたりする。

エンコーディング	適した列	原理	期待効果
辞書(Dictionary)	低カーディナリティのカテゴリ・文字列	値→整数コード置換	サイズ縮小 + 整数比較フィルタ
RLE	ソート・反復の多い列	値+反復回数で表現	反復区間の極端な圧縮
デルタ(Delta)	増加型の数値・タイムスタンプ	前の値との差だけ格納	狭い値範囲へ縮小
ビットパッキング	値範囲が狭い整数	必要な最小ビットだけ使用	整数格納の効率化

B. 汎用圧縮との組み合わせ。軽量エンコーディングで一次整理されたバイトストリームに、さらにLZ4・Snappy・Zstandardのような汎用圧縮をかけると圧縮率が一段と高まる。実務では「クエリ時の解凍コスト」と「格納・転送の節約」の間のトレードオフに応じて、ホット(hot)データには解凍速度の速いLZ4/Snappyを、コールド(cold)アーカイブには圧縮率の高いZstdを使う形で階層化する。圧縮は格納コストだけでなくディスク・ネットワークI/O量そのものを減らし、解凍にかかるCPUを相殺してなお純益が出る場合が多い。

C. データスキッピング(ゾーンマップ)。列チャンクごとに最小・最大値、NULL個数のようなゾーンマップ(zone map)・統計を併せて格納すると、WHERE 売上 > 1億のようなフィルタで最大値が1億以下のチャンク全体を読まずに飛ばす。このプレディケートプッシュダウン(predicate pushdown)・データスキッピングはカラム指向ストレージのI/O削減を倍加させ、データが関連列でソート・クラスタリングされているほど効果が大きくなる。

D. ベクトル化実行と遅延マテリアライゼーション。列の値が連続配列であるため、エンジンは一度に一行ではなく数千個の値をバッチ(batch)で処理する。このベクトル化モデルは関数呼び出しのオーバーヘッドを分散し、SIMD命令で並列演算してCPU効率を高める。伝統的な行ベース実行がタプル一つごとに演算子を呼ぶ「ボルケーノ(Volcano)反復モデル」だとすれば、ベクトル化はその呼び出しをバッチあたり一回に減らし、インタプリタのオーバーヘッドを償却する。また遅延マテリアライゼーション(late materialization)はフィルタ・集計に必要な列だけを先に処理し、元の行形態へ戻すタプル再構成をできるだけ後ろへ遅らせて不要なデータ結合を避ける。逆にクエリ序盤で行を復元する早期マテリアライゼーション(early materialization)は実装が単純だが大量スキャンで損をする。フィルタ選択度(selectivity)が非常に低く大半の行が除かれるクエリほど、遅延マテリアライゼーションの利得が大きくなる。

E. 限界と不適合ワークロード。逆にカラム指向ストレージが不利な場合も明確にある。SELECT *のようにすべての列を要求するクエリは列ファイルを再び行へ組み立て直さねばならずかえって損であり、単件の挿入・修正が頻繁なOLTP、または少数の行をキーで正確に見つけて全属性を取ってくるポイント照会もまた行指向・B+Treeインデックスが有利である。したがってカラム指向ストレージは「万能の代替物」ではなく分析ワークロードに特化したツールとして理解し、トランザクションシステムと役割を分けて配置するのが正しい設計観点である。

4. 比較と適用事例

行指向と列指向は優劣ではなくワークロード整合性の問題である。違いが生じる根本原因は「一度のI/Oで読んできたデータのうち実際にクエリが消費する割合」にある。OLTPは特定の行全体を頻繁に扱うため行指向がその割合を高め、OLAPは少数の列を全範囲で走査するため列指向がその割合を高める。更新特性も分かれる。列指向で一行を更新するには散らばった複数の列ファイルをすべて手当てせねばならないため、大半のカラムシステムは個別のUPDATEの代わりに不変(immutable)ファイルへ新バージョンを追加(append)し併合(compaction)する方式を採る。

更新処理の方式をもう少し覗くと、多くのカラムエンジンは[[lsm-tree]]と類似の発想で書き込みを吸収する。新しく入ってきた行をまず小さなメモリ・行バッファ(または小規模ファイル)にため、一定のしきい値に達するとこれをカラム形式の不変ファイルへフラッシュし、バックグラウンドで複数の断片を一つに併合(compaction)する。削除・修正は当該行を即座に除去する代わりに削除マーク(tombstone)や新バージョンとして記録し、読む時点で除去するか(merge-on-read)併合時点で反映する(merge-on-write)。この構造のおかげで大量ロードのスループットは高いが、併合が滞ると小ファイルが積もりスキャン性能が落ちるため、併合ポリシー管理が運用の中核となる。

このトレードオフのため最新システムは二つのモデルを組み合わせる。ハイブリッドHTAPアプローチで、最近のデータは行格納(高速な挿入)で受け、古いデータは列格納(高速な分析)へ転換する構造が代表的である。例えばClickHouseはカラム指向ストレージ上で毎秒数十億行の集計を処理し大規模なログ・イベント分析に使われ、Amazon Redshiftはカラム指向ストレージとゾーンマップ・ソートキーを組み合わせてペタバイト級ウェアハウスを運用し、Google BigQueryはCapacitorカラムフォーマットとDremel実行エンジンでサーバーレス分析を提供する。組込み分析では単一ファイルで動作するDuckDBが、カラム・ベクトル化エンジンでノートブック環境でも大容量CSV・Parquet分析を数秒内に実行する事例が増えている。

具体的な適用事例としてオブザーバビリティ(Observability)ログ分析を挙げられる。数千台のサーバーが毎秒数百万件のログ・メトリクスを吐き出す環境で、これを行指向RDBMSに入れて「過去1時間のエラー率をサービス別に集計」すると、全スキャンの負担で応答が数十秒を超える。同じデータをClickHouse・Druidのようなカラムエンジンに積み、時刻・サービス列でソートしておくと、ゾーンマップスキッピングとベクトル化集計で同じクエリを1秒内に処理する。別の事例として、通信会社の通話・課金明細記録(CDR)分析では数百の列のうち料金関連のいくつかだけが繰り返し集計されるため、カラム指向ストレージへ転換した後は格納コストが圧縮で数倍減り、月末精算バッチ時間が大きく短縮された事例が報告される。このように「広く(多くの列)深い(多くの行)データで少数の列を繰り返し集計する」パターンほど、カラム指向ストレージの利得が大きくなる。

観点	行指向(OLTP)	列指向(OLAP)
代表クエリ	`SELECT * WHERE id=?`	`SELECT SUM(x) GROUP BY y`
挿入/更新	速い	遅い(append·compaction)
スキャン・集計	遅い	速い
圧縮	限定的	優秀
インデックス依存	高い(B+Tree)	低い(スキャン+スキッピング)

まとめると、二つのモデルの選択基準は「クエリが行指向的か、列指向的か」という単一の問いに収束する。少数の行を幅広い列で扱うなら行格納が、多数の行を少数の列で集計するなら列格納が正解である。現実のシステムは、この二つを一つのストレージへ統合するより役割を分けたストレージ層として構成し、その間をデータパイプラインでつなぐほうが、総所有コスト(TCO)と性能の双方で有利な場合が多い。

5. 深化: 格納フォーマットの標準化とレイクハウス

カラム指向ストレージはデータベースエンジン内部の技術から出発したが、今日の流れはオープンなファイルフォーマット(open format)への標準化である。純粋な列格納(すべての値を列別ファイルへ完全分離)はタプル再構成コストが大きいという弱点があるため、実務のフォーマットは大半がPAX(Partition Attributes Across)系のハイブリッドを採る。すなわち、テーブルを数万〜数十万行単位の行グループ(row group)にまず分け、各行グループの中だけで列別に値をまとめる方式である。こうすると列スキャンの利点を生かしつつ、一つの行グループの中で関連列を局所的に再構成できてI/O局所性が改善する。

このハイブリッド設計を標準化した代表的フォーマットがApache ParquetとApache ORCである。Parquetは行グループ → 列チャンク → ページの階層で構成され、ネスト(nested)データを定義レベル・反復レベルで表現するDremelモデルを採用し、Spark をはじめとするビッグデータエコシステムの事実上の標準フォーマットとして使われる。ORCはストライプ(stripe)単位の構造と内蔵インデックス・統計でHive系で広く使われる。メモリ領域ではApache Arrowが言語・エンジン間でコピー・シリアライズなしにデータをやり取りするインメモリ・カラム標準として定着し、異機種システム間のデータ交換コストを下げている。

商用クラウドウェアハウスも同じ原理を内部に溶け込ませた。Snowflakeはデータを数十〜数百MB単位の不変マイクロパーティション(micro-partition)に分け、その中で列単位に格納・圧縮し、パーティションごとにmin/max・distinct数のようなメタデータを置いてプルーニング(pruning)する。これは先に見たPAXハイブリッドとゾーンマップスキッピングを商用規模で実装した事例である。まとめると、学術概念(C-Store・PAX)から出発したカラム指向ストレージが、オープンなファイルフォーマット(Parquet・ORC)とインメモリ標準(Arrow)、そして商用エンジン(Snowflake・BigQuery・Redshift)に至るまで一つの系譜として連なり、今日の分析インフラ全般を貫いている。

最も最近の動向はレイクハウス(Lakehouse)である。オブジェクトストレージ(S3など)に積まれたParquet・ORCファイルの上にDelta Lake・Apache Iceberg・Apache Hudiのようなテーブルフォーマットがトランザクションログ・スキーマ進化・時点照会(time travel)・ACIDを載せ、安価なデータレイクにデータウェアハウスの信頼性を結合する。ここで列ファイル(Parquet)はデータを収める物理層を、テーブルフォーマットはどのファイル群が特定時点のテーブルを構成するかを記述するメタデータ層を担う。この分離のおかげで一つのデータのコピーを置いても、バッチ・ストリーミング・BI・MLが互いに異なるエンジンで同時にアクセスしながら一貫性を保てる。これにより格納はオープンなカラムフォーマット一つに統一し、その上で複数のクエリエンジン(Spark・Trino・Snowflake・DuckDB)が各自アクセスする格納・演算の分離(decoupled storage-compute)アーキテクチャが標準として固まりつつある。関連する概念は[[data-warehouse-olap]]、[[btree-bplus-index]]と併せて理解すると、格納・索引・分析の全体像がつかめる。

6. 考慮事項および示唆点

カラム指向ストレージは特定製品の一機能ではなくデータアーキテクチャの根幹をなす選択であるため、導入前にワークロード特性と長期の運用負担を併せて秤にかけねばならない。

特に技術士の答案では、次の五つの軸 — ワークロード分離、圧縮トレードオフ、更新・規制対応、オープンフォーマット、運用・監視 — をバランスよく押さえ、適用戦略とトレードオフ、展望、連携技術を併せて論じるのが望ましい。

ワークロード分離戦略(HTAP): トランザクションと分析を一つの格納モデルへ無理に統合するより、行格納(OLTP) + 列格納(OLAP)を階層化しCDC(Change Data Capture)・ETL/ELTで同期するハイブリッドが現実的である。最近のHTAPエンジンは内部的に二つの表現を併せ持ちつつ一貫性・遅延を管理する方向へ進化する。
圧縮・性能トレードオフ: 高い圧縮率は格納・I/Oを減らすがクエリ時に解凍CPUを要求する。データ温度(hot/cold)に応じてエンコーディング・圧縮コーデックとソートキーを差別的に適用し、ゾーンマップ効果を生かすよう頻繁にフィルタされる列を基準にデータをソート・クラスタリングする物理設計が性能を左右する。
更新・削除と規制対応: 列・不変ファイル構造は個別削除が難しい。GDPR・個人情報保護法の削除権対応、小規模で頻繁な更新による小ファイル(small file)の急増問題は、周期的な併合(compaction)・パーティション設計・merge-on-read/write戦略で管理せねばならない。
オープンフォーマットとロックイン回避: Parquet・Icebergなどオープンなフォーマット・テーブルフォーマットを採用すると特定ベンダーエンジンへの依存(lock-in)を減らし、格納・演算の分離でエンジンを交換・並行できる柔軟性を確保する。これはマルチクラウド・コスト最適化(FinOps)の観点でも重要な選択基準である。
運用・監視の観点: カラム指向ストレージシステムの性能はパーティション・ソートキー設計と併合周期に大きく左右されるため、小ファイル数・併合遅延・スキッピング効率(スキャン対比で実際に読んだチャンク割合)のような指標を継続的に観測し物理設計を反復調整する運用力が求められる。
展望: GPUベースのベクトル処理、リアルタイムストリーミングとバッチの統合、そしてベクトル埋め込み([[vector-database]])・AIワークロードを併せて収める分析プラットフォームへとカラム指向ストレージの適用範囲が拡大している。オープンなテーブルフォーマットの標準競争(Iceberg中心の収束の流れ)も今後のデータアーキテクチャ選択で核心的な変数となる見通しである。

参考資料

Apache Parquet, "File Format", https://parquet.apache.org/docs/file-format/
Apache ORC, "ORC Specification", https://orc.apache.org/specification/
Stonebraker et al., "C-Store: A Column-oriented DBMS", VLDB 2005, https://www.vldb.org/archives/website/2005/program/paper/thu/p553-stonebraker.pdf
Ailamaki et al., "Weaving Relations for Cache Performance (PAX)", VLDB 2001, https://www.vldb.org/conf/2001/P169.pdf
Apache Arrow, "Format", https://arrow.apache.org/docs/format/Columnar.html

一言まとめ: カラム指向ストレージはデータを列単位でまとめ、選択的読み込み・高圧縮・ベクトル化実行を実現する分析(OLAP)最適の格納モデルであり、Parquet・ORCのようなオープンなハイブリッドフォーマットとレイクハウスを通じて今日のデータ分析インフラの標準基盤となった。