OLAP vs OLTP

OLAP vs OLTP とは

OLTP (Online Transaction Processing) は受注・入金・在庫更新のように、少数の行を確実に読み書きする処理である。OLAP (Online Analytical Processing) は「先月のカテゴリ別売上」のように、大量の行から少数の列を集計する処理を指す。両者を分ける軸は 1 クエリが触る行数と列数で、OLTP は行数が少なく列はほぼ全部、OLAP は行数が膨大で列はごく一部になる。この非対称がそのまま、ストレージ形式・正規化の方針・レイテンシ目標の違いに現れる。

比較

以下の違いは製品ごとの好みではなく、上の非対称から導かれる帰結である。

観点	OLTP	OLAP
目的	トランザクション処理	データ分析
クエリ	単純 (1 行の CRUD)	複雑 (集計、JOIN)
データ量	GB〜TB	TB〜PB
レイテンシ	ミリ秒	秒〜分
ストレージ	行指向	列指向
正規化	正規化 (3NF)	非正規化 (スタースキーマ)
AWS	DynamoDB, Aurora	Redshift, Athena

行指向と列指向で速さが逆転する理由

差は物理的な置き方から来る。行指向ではディスクブロックに 1 レコード分の列値が連続して並ぶため、1 行を丸ごと読み書きするのに触るブロックが少ない。列指向では 1 ブロックに単一列の値が複数行分まとまるので、集計に必要な列のブロックだけを読めば足り、走査する I/O が減る。さらにブロック内が同じデータ型で揃うため型に合わせた圧縮が効き、同じ行数を読むための I/O がもう一段下がる。Amazon Redshift の開発者ガイドも、この 2 点 (必要な列のブロックだけ読む・列のデータ型に合わせた圧縮) を列指向が分析クエリで有利になる理由として挙げている。

裏返しが列指向の弱点である。1 行の更新は、その行が持つ全列のブロックに触ることになる。行指向なら 1 ブロックの書き換えで済む更新が、列数だけブロックを巻き込む。そのため列指向のシステムは単一行の更新を正面から受けず、まとめて追記してから並べ替える (Redshift ならソートキー順への再編) 設計を取る。OLAP 側が遅いのではなく、1 行更新という別の仕事に向いていないだけだと押さえておくと、サービス選定を誤らない。

AWS でのデータフロー

典型的な構成は、OLTP 側で起きた変更を捕まえて分析用のストレージへ流し込む形になる。

OLTP (DynamoDB)
  ↓ DynamoDB Streams → Lambda → S3 (Parquet)
OLAP (Athena / Redshift)
  ↓ クエリ結果
BI ダッシュボード (QuickSight)

自分でパイプラインを組まず、ゼロ ETL 統合に任せる選択肢もある。2026 年 8 月時点の Amazon Redshift 管理ガイドは、統合元として Aurora MySQL / Aurora PostgreSQL / DynamoDB / RDS for MySQL / RDS for PostgreSQL / RDS for Oracle などを挙げている。初回ロードのあとはソースから継続的に複製される仕組みで、変換の実装を持たずに済む一方、OLTP と OLAP が同じデータの複製を別々に抱える構造そのものは変わらない。

OLTP の例 (DynamoDB)

主キー指定の 1 件取得は、触る行が 1 行で列はその行の全部という OLTP の典型である。

// 1 件の注文を取得 (ミリ秒)
await db.get({ TableName: 'orders', Key: { id: '123' } });

OLAP の例 (Athena)

こちらは全期間の注文を走査するが、使う列は order_date と amount の 2 つだけである。Parquet のように列単位で保存してあれば、読むのはこの 2 列分のブロックに限られる。

-- 月別の売上集計 (秒〜分)
SELECT DATE_TRUNC('month', order_date) AS month, SUM(amount) AS total
FROM orders
GROUP BY 1
ORDER BY 1;

HTAP という中間

同じデータに対して OLTP と OLAP の両方を動かす方式は HTAP (Hybrid Transactional/Analytical Processing) と呼ばれる。実装は大きく 2 通りで、①同一システムが行ストアと列ストアを二重に持つ ②別システムへ準リアルタイムに複製する、のいずれかになる。①の例が SQL Server で、SQL Server 2016 で導入された列ストアインデックスにより、分析と OLTP のワークロードを同じテーブルに対して同時に実行できる (Microsoft はこれを real-time operational analytics と呼んでいる)。②の例が前述のゼロ ETL 統合である。

判断軸は「分析結果がどれだけ新しくないと困るか」に尽きる。日次レポートなら夜間に流すバッチで足りるので、分けたほうが安く単純になる。数分前の注文まで含めた在庫の見え方が必要なら、二重保持や継続複製のコスト (書き込み負荷の増加・ストレージの二重化) を払う価値が出る。ここを詰めずに HTAP へ寄せると、要らない新鮮さのために OLTP 側の書き込み性能を削ることになる。

いつどちらを使うか

迷ったら、そのクエリが何行を触り何列を使うかを数えると寄せ先が決まる。

ケース	推奨
ユーザーの注文処理	OLTP (DynamoDB)
月次売上レポート	OLAP (Athena + Parquet)
リアルタイムダッシュボード	OLTP + キャッシュ、または HTAP
アドホック分析	OLAP (Redshift)

手元で違いを確かめるなら、同じデータを RDS のテーブルと S3 上の Parquet に置き、片方で主キー 1 件の取得、もう片方で 1 列の合計を測ってみるとよい。得意な仕事が入れ替わることが実行時間の数字で見える。設計の型として体系的に押さえたい場合は、関連書籍もあわせて参照したい。