OLTP と OLAP：本番 DB に分析 SQL を流さない

Stage 3 — 第1章 | データマネジメント入門 推定学習時間：35〜45分 | 難易度：★★☆☆☆

この章で学ぶこと

Stage 2 では 意味と正本 を整えました。 Stage 3 からは データの置き場所 —— どこに、どんな形で保存し、誰が触るか —— に入ります。

最初の論点は、分析 SQL と業務 DB の 分離 です。 さくら商事では、新人アナリストの 1 本のクエリが EC サイトの応答遅延を引き起こしました。

この章を終えると、こんなことができるようになります：

• OLTP（Online Transaction Processing）と OLAP（Online Analytical Processing）の 目的の違い を説明できる
• 本番 DB に分析クエリを流すリスクを具体例で説明できる
• 分析用データを 別系統 に置く設計の基本を説明できる
• Stage 1 のライフサイクル「保存・加工」と接続できる

1. 金曜日の 15 時：サイトが重い

さくら商事の EC サイトが、金曜 15 時ごろ突然遅くなりました。 インフラ担当のログを見ると、PostgreSQL（本番 DB）の CPU が 95% 付近で張り付いていました。

Slack #incident

インフラ:「本番 DB が飽和。誰か重い SELECT 回してない？」

山田:「すみません… orders 全件 JOIN して 2 年分集計してました。」

鈴木:「本番は OLTP 用 です。分析は DWH へ。」

30 分後、クエリは止まり、サイトは復旧。 売上損失は小さかったものの、「分析のために本番を触る」文化 が問題として表面化しました。

2. OLTP と OLAP：目的が違う

同じ orders テーブルでも、使い方が違えば別世界 です。 OLTP は「注文 1 件を正確に書く」、OLAP は「100 万行を横断して読む」。

2.1 なぜ混ぜると壊れるか

現場メモ

「読み取りだけなら大丈夫」は 半分正しく半分危険 です。 SELECT でもフルスキャンは 書き込み性能 を圧迫します。

3. 分離の基本パターン

分析は 本番からデータを複製・移送 し、別の置き場で行います。

[OLTP 本番 DB] ──ETL/CDC──> [分析基盤: DWH / レイク] ──> [マート / BI]
                 ↑
             業務 API のみ触る
          

3.1 レプリカ直読みの落とし穴

「本番ではなくレプリカなら OK」——小規模ではよく見る妥協です。

鈴木さんの方針は 「レプリカは移行期のみ。分析の正本は BigQuery DWH」 です。

4. さくら商事の役割分担

山田さんには 本番 PostgreSQL への read 権限を付与しない 方針に変更しました。 代わりに、DWH 上の mart_finance と mart_marketing へのアクセスを整備します。

5. DAMA・ライフサイクルとの接続

Stage 2 で決めた「公式売上の正本」は、OLAP 側の mart_finance です。 OLTP の orders は ソース であり、会議でそのまま触る場所ではありません。

6. よくある誤解

体系コラム：カリキュラム上の位置づけ

コラム：よくある誤解 —「BigQuery があれば OLTP は不要」

金曜 15 時、さくら商事の EC サイトが重くなった原因は、分析用の全件スキャンが本番 DB に流れていたことでした。鈴木さんは「BigQuery があるから本番も BigQuery で」と言う声に、注文処理と分析は別エンジン だと説明しました。

OLTP は短いトランザクションを大量に捌く。OLAP は横断集計を重くてもよい。DWH があっても、カート更新や在庫引当は依然 OLTP 側です。分析は CDC やバッチで OLAP 側に複製 して触るのが基本です。

もう一つの誤解は「リアルタイム分析＝本番直読」です。ダッシュボードを 5 分更新したいからといって本番 orders を直接読むと、ピーク時にサイト全体が止まります。リアルタイムに近づけたいなら、ストリーミング取込で OLAP 側を更新 する設計が先です。

まとめ

この章のキーメッセージ：

分析 SQL は 才能の問題 ではなく 置き場所の問題 です。 本番 DB は EC を動かすための OLTP。数字を出す場所は、別系統の OLAP 側に用意してください。

次に読む

• 前章（Stage 2）: セマンティックレイヤー
• 次章: レイク・DWH・マート
• 関連: データマート（analytics）

確認問題

問題 1

さくら商事で本番 PostgreSQL に 2 年分の JOIN 集計を流し、EC が遅くなった。 最も本質的な設計ミス はどれですか。

A. JOIN 句の順序
B. 分析ワークロードを OLTP 本番で実行した
C. PostgreSQL ではなく MySQL を使うべきだった
D. 統計検定 2 級の知識不足

正解: B

解説: 症状は SQL 技法ではなく OLTP/OLAP 未分離 です。C/D は論点外、A は二次要因に過ぎません。

問題 2

「読み取り専用レプリカなら、分析 SQL を流しても本番に影響しない」について 最も正確 なのはどれですか。

A. 常に完全に真。レプリカなら無制限で OK
B. 本番への直接負荷は減らせるが、レプリカ性能・スキーマ・ガバナンスの問題は残る
C. レプリカは OLAP 専用なので SSOT に最適
D. レプリカは分析に使えない

正解: B

解説: レプリカは 移行期の妥協 になりがちです。性能・分析向けスキーマ・正本の一元化は DWH 側で解決するのが本筋です。

問題 3

公式売上の SSOT が mart_finance.monthly_revenue（BigQuery）にある。 経理が「本番 DB の orders を直接集計した数字が正しい」と主張した。 データマネジメント上 望ましい対応 はどれですか。

A. 本番直集計を SSOT に変更する
B. 本番はソース、公式数字は OLAP マート経由である理由（リネージ・定義）を説明し、会議はマートを正とする
C. 両方を SSOT として併存させる
D. 数字の議論をやめ、感覚で経営する

正解: B

解説: OLTP は ソース、OLAP マートが 公式分析正本 という役割分担です。A/C は SSOT 崩壊、D は Stage 1 の症状の放棄です。

用語メモ（この章）