HTAP アーキテクチャと行/列デュアルストア

なぜ「行と列を1つに」したいのか

行指向は OLTP、列指向は OLAP という棲み分けは、物理レイアウトの非対称性から導かれる原則です。ところが現実の要求は「いま発生したトランザクションを、いますぐ分析したい」――注文が入った瞬間の在庫分析、決済直後の不正検知、といった鮮度依存の分析です。従来はトランザクション系から分析系へ ETL でデータを夜間コピーしていましたが、これでは分析が常に過去を見ます。

HTAP（Hybrid Transactional/Analytical Processing） は、この ETL の壁を取り払い、OLTP と OLAP を単一システムで両立させるアーキテクチャです。中核となるのが、行指向ストアと列指向ストアを同居させる 行/列デュアルストア（dual-store） で、更新は行側で受け、分析は列側で走らせます。本稿はその内部構造――delta/main の二層、差分マージ、実行リソースの分離――を設計判断の観点から解説します。

デュアルストアの基本構造：delta と main

列指向ストアは大量集計に強い一方、1行の挿入・更新が苦手です。1行を足すだけで全カラムの圧縮ブロックを触り、途中更新は圧縮の再構成を招くためです。そこで HTAP は、更新を列ストアへ直接当てず、書き込み最適化の小さな層に一度吸わせるという二層構造を採ります。

• delta（差分ストア）: 直近の挿入・更新・削除を受ける書き込み最適化層。行指向、あるいは未圧縮の小さな列バッファとして持ち、点更新を低コストで追記する。
• main（基底ストア）: 大半のデータを保持する読み出し最適化層。列指向で強く圧縮され、スキャン・集計に最適化されている。原則として直接は更新せず、追記とまとめ反映で更新する。

書き込み（OLTP）
   │  INSERT/UPDATE/DELETE を低コストで吸う
   ▼
┌──────────── delta ────────────┐   小さい・書き込み最適化・行指向/未圧縮
│ 直近の挿入・更新・削除（差分）  │
└───────────────┬───────────────┘
                │  背景でまとめてマージ（圧縮・列化）
                ▼
┌──────────── main ─────────────┐   大きい・読み出し最適化・列指向・高圧縮
│ 大半のデータ（基底スナップ）    │
└───────────────────────────────┘
                ▲
   読み取り（OLAP/OLTP）：main + delta を重ねて一貫した像を見る

この「小さく書き込み最適な層に追記し、背景でまとめて読み出し最適な層へ畳む」という発想は LSM-Tree と同根です。LSM が memtable と SSTable で行っていることを、HTAP は delta と列指向 main で行う、と捉えると構造が掴めます。ランダムな点更新を避け、シーケンシャルなマージに均すことで、列ストアの圧縮効率とスキャン局所性を守るわけです。

読み取り時の重ね合わせと一貫性

デュアルストアの肝は、読み取りが main と delta を一つの整合した像として見ることです。OLAP クエリが main だけをスキャンすると、delta に溜まった最新更新を取りこぼします。逆に無条件に両方を足すと、更新された旧版を二重に数えてしまいます。

これを解くのが MVCC のスナップショットです。各行版にコミット時刻（バージョン）を付与し、クエリは自分のスナップショット時刻で可視な版だけを選びます。読み取りの流れは概念的に次の通りです。

read(snapshot_ts):
  rows  = scan(main, visible_at = snapshot_ts)   # 列スキャン（高速・圧縮のまま）
  rows -= apply(delete_delta, visible_at = snapshot_ts)  # main から消された行を除く
  rows += scan(insert_delta, visible_at = snapshot_ts)   # delta の新規/新版を足す
  return merge(rows)   # 同一キーは最新版を採用

ここで重要なのは、main のスキャンは列指向のまま高速に走り、delta は小さいので重ね合わせのコストが低い点です。delta が肥大化すると重ね合わせと delta スキャンが重くなるため、マージ（後述）で delta を小さく保つことが性能の前提になります。OLTP の点読み取りは主キー索引で delta を優先的に引き、OLAP の全件集計は main を主体に delta を被せる、と経路を分けるのが定石です。

差分マージ（delta → main）の設計判断

delta は放置すれば肥大化し、読み取りの重ね合わせコストを押し上げます。そこで背景プロセスが定期的に delta を main へマージします。これは LSM のコンパクションに相当し、設計上いくつかの判断点があります。

マージ中も読み書きは止められません。多くの実装は、新しい main を別領域に構築してからアトミックに切り替えるコピーオンライト方式を採り、切り替え前の古い main を参照中のスナップショットには見せ続けます。切り替え後、どのスナップショットからも参照されなくなった旧版を GC（ガベージコレクション） で回収します。これは MVCC の版回収と同じ問題で、長時間走る OLAP クエリが古い版を握り続けると回収が滞り、ストレージが膨らむ点に注意が要ります。

実行リソースの分離：干渉をどう抑えるか

OLTP と OLAP は資源プロファイルが正反対です。OLTP は短命・低レイテンシ・点アクセス中心で、応答時間のばらつき（テールレイテンシ）を嫌います。OLAP は長命・高スループット・全件スキャン中心で、CPU・メモリ帯域・I/O を大量に食います。同じノードで素朴に混走させると、重い分析クエリが OLTP のレイテンシを破壊します。HTAP の設計判断の二つ目は、この実行リソースをどう分離するかです。

論理分離は鮮度が最も高い一方、メモリ帯域や I/O のような物理資源は完全には切れず、隔離は弱くなります。物理分離は、OLTP のプライマリから レプリケーションログ を流して列指向レプリカを別ノードで更新し続ける方式です。分析クエリは列レプリカへルーティングされ、OLTP ノードに一切触れないため隔離が強い反面、ログ追従の遅延ぶん鮮度が落ちます。多くの場合この遅延はミリ秒〜秒オーダーで、夜間 ETL の「1日遅れ」とは別次元の鮮度です。

まとめ