2025年5月14日·1 分
なぜOLTPとOLAPのワークロードは1つのデータベースに同居すべきでないことが多いのか
トランザクション（OLTP）と分析（OLAP）を1つのデータベースで混在させるとアプリの遅延、コスト増、運用の複雑化を招く理由と、代替策（レプリカ、データウェアハウス、CDC/ELT）を解説します。
トランザクション（OLTP）と分析（OLAP）を1つのデータベースで混在させるとアプリの遅延、コスト増、運用の複雑化を招く理由と、代替策（レプリカ、データウェアハウス、CDC/ELT）を解説します。
人が「OLTP」や「OLAP」と言うとき、それはデータベースの使われ方が大きく異なる二つのパターンを指します。
**OLTP（Online Transaction Processing）**は、常に速く正確である必要がある日々の操作を支えるワークロードです。イメージは「今この変更を保存する」。
典型的なOLTP作業は、注文の作成、在庫の更新、支払いの記録、顧客住所の変更など。これらは通常小さな単位（数行）、頻繁に発生し、数ミリ秒の応答が求められます。人や他のシステムが応答を待っているからです。
**OLAP（Online Analytical Processing）**は、何が起きたか、なぜ起きたかを理解するためのワークロードです。イメージは「大量のデータを走査して要約する」。
典型的なOLAP作業は、ダッシュボード、トレンドレポート、コホート分析、予測、そして「過去18か月で地域と商品カテゴリごとの収益はどう変わったか？」のような“スライス＆ダイス”な問いです。これらのクエリは多くの行を読み込み、重い集計を行い、秒（あるいは分）単位で実行されても「間違い」ではありません。
要点は簡単です：OLTPは高速で一貫した書き込みと小さな読み取りを最適化し、OLAPは大規模な読み取りと複雑な計算を最適化します。目的が異なれば、最適なデータベース設定、インデックス、ストレージの配置、スケーリング方法も異なります。
また、「rarely（めったにない）」であり「never（決してない）」ではないことにも注意してください。小規模でデータ量が控えめ、クエリが慎重に設計されているチームなら、しばらくの間ひとつのデータベースを共有することは可能です。後続のセクションでは何が最初に壊れるか、一般的な分離パターン、そして本番からレポーティングを切り離す方法を説明します。
OLTPとOLAPはどちらも「SQLを使う」かもしれませんが、最適化する仕事が異なり、それは成功の定義にも現れます。
OLTP（トランザクショナル）システムは日々のオペレーションを支えます：チェックアウト、アカウント更新、予約、サポートツール。優先順位は明確です：
成功は通常、p95/p99のリクエスト時間、エラー率、ピーク時の同時実行での振る舞いで評価されます。
OLAP（分析）システムは「今四半期に何が変わったか？」や「新価格後にどのセグメントが離脱したか？」のような問いに答えます。これらのクエリはしばしば：
成功はクエリスループット、インサイトまでの時間、チューニング無しで複雑なクエリを実行できる能力で測られます。
両方のワークロードを1つのデータベースに押し込むと、トランザクション向けに最適化された動作と、分析向けに最適化された動作の両方を同時に求めることになります。結果は妥協になることが多く：OLTPは予測できないレイテンシーを受け、OLAPは本番を保護するために制限され、どちらのチームも「どのクエリが許されるか」で揉めます。目的が違えば成功指標も別であるべきで、通常はシステムも別です。
OLTP（アプリの日々のトランザクション）とOLAP（レポーティング・分析）が同じデータベースで動くと、有限なリソースを奪い合います。結果は単なる「レポートが遅い」ではなく、チェックアウトやログインの遅延、予測不能なアプリの不調になります。
分析クエリは長時間で重いことが多く、巨大なテーブル間の結合、集計、ソート、グルーピングを行います。これらはCPUコアやハッシュ結合・ソートバッファのメモリを独占しがちです。
一方、トランザクションは小さくてレイテンシーに敏感です。CPUが飽和したりメモリ圧力で頻繁にページが追い出されると、短いクエリが長いクエリの後ろで待つことになります—実際に必要な処理は数ミリ秒でも待たされます。
分析は大きなテーブルスキャンや順次読みを引き起こす一方、OLTPは多くの小さなランダム読みと継続的なインデックス／ログへの書き込みを行います。
両者を混在させると、ストレージサブシステムが互いに相容れないアクセスパターンをさばかなければなりません。OLTPに有効だったキャッシュが分析のスキャンで「洗い流され」、レポートのためにディスクが連続読みをしている間に書き込みレイテンシが急増することがあります。
数人のアナリストが広範なクエリを走らせると、接続を数分占有することがあります。アプリが固定サイズのプールを使っている場合、リクエストは空き接続を待ってキュー化されます。そのキューイングは健全なシステムを「壊れているように」見せることがあり、平均レイテンシは大丈夫でもテールレイテンシ（p95/p99）が苦痛になります。
外から見ると、これはタイムアウト、遅いチェックアウト、検索結果の遅延、あるいは一般的に不安定な挙動として現れます—しばしば「レポーティング時だけ」や「月末だけ」に起きます。アプリチームにはエラー、分析チームには遅いクエリ、根本問題は共有リソースの競合です。
OLTPとOLAPは単に「データベースの使い方が違う」だけでなく、望ましい物理設計が正反対になることがあります。両方を満たそうとすると、コストの高い妥協に落ち着くことが多いです。
トランザクションワークロードは、1件の注文を取得、1行の在庫を更新、特定ユーザーの最新20イベントを取得――のような短いクエリが中心です。
そのためOLTPスキーマは行指向ストレージと、主キーや外部キー、いくつかの重要なセカンダリインデックスのようなポイントルックアップに有利なインデックスを志向します。目標は書き込みの予測可能で低いレイテンシーです。
分析では多くの行と少数の列を読むことが多く、「週・地域ごとの収益」「キャンペーン別のコンバージョン率」「利幅での上位商品」といった集計が求められます。
OLAPはカラムナストレージ（必要な列だけ読むため）、パーティショニング（古いデータや無関係なデータを速くプルーニングするため）、事前集計（マテリアライズドビュー、ロールアップ、サマリーテーブル）が役立ちます。
ダッシュボードを速くするためにインデックスを増やすのは一般的な反応ですが、追加のインデックスは書き込みコストを増やし、ストレージを圧迫し、vacuumやreindex、バックアップといった保守作業を遅くします。
データベースは統計（フィルタで何行がヒットするか、インデックスの選択性、データ分布）に基づいてクエリプランを選びます。OLTPはデータを常に変化させるため、分布がずれ、プランナーが昨日は良かったが今日は遅いプランを選ぶことがあります。
重いOLAPクエリが混ざると変動は大きくなり、「ベストプラン」の予測がつきにくくなり、あるワークロード向けのチューニングが他方を悪化させます。
データベースが「同時実行をサポートする」場合でも、重いレポートとライブトランザクションを混在させると微妙な遅延が発生し、説明しにくい顧客向けのスピニングになることがあります。
OLAP系のクエリは大量の行を走査し、複数テーブルを結合し、数秒〜数分走ることがあります。その間、スキーマオブジェクトに対するロックや一時構造へのソート/集計のためのリソースを保持することがあり、間接的にロック競合を増やします。
MVCC（マルチバージョン並行制御）により読み書きのブロックは緩和されますが、ホットなテーブルに対しては競合が完全に消えるわけではありません。
MVCCでは古い行バージョンが安全に削除できるまで残ります。長時間のレポートが古いスナップショットを開いたままにすると、クリーンアップが進まず：
結果として、レポーティングは即時の負荷を与えるだけでなく、時間経過でシステムを遅くします。
分析ツールはより強い隔離レベルを要求することがあり（あるいは長いトランザクションを無自覚に走らせることがある）、高い隔離はロック待ちやエンジンが管理するバージョン量を増やします。OLTP側では、ほとんどの注文は速く処理されるが一部だけが急に滞る、という不規則なスパイクとして現れます。
月末に財務が月次の「商品別収益」クエリを走らせると、注文や明細を月全体で走査します。クエリ実行中も新しい注文は受け付けられますが、vacuumが古いバージョンを回収できずインデックスが劣化します。結果として注文APIに時折タイムアウトが生じます—“ダウン”しているわけではなく、競合やクリーンアップのオーバーヘッドが静かにレイテンシーを押し上げているのです。
OLTPは予測可能性で生き残ります。チェックアウトやサポート操作が「概ね速い」ではユーザーは遅い瞬間に気づきます。対してOLAPはバースト的になることが多く、数本の重いクエリが長時間CPUやメモリ、I/Oを消費します。
分析トラフィックは次のようなタイミングで集中しがちです：
一方、OLTPは一般により安定した負荷になります。両者が同一DBだと分析のスパイクがトランザクションの予測不能なレイテンシーに直結します。
夜間にレポートを走らせる、同時実行を制限する、ステートメントタイムアウトやクエリコストキャップを設定する、といった対策は被害を減らします。これは本番でのレポーティングに有効なガードレールです。
しかし、これらは根本的な不一致を取り除くものではありません。OLAPクエリは大きなリソースを使って大きな問いに答える設計であり、OLTPは日中ずっと小さなリソースを必要とします。予期せぬダッシュボード更新やアドホッククエリが通ってしまえば、共有データベースは再び露呈します。
共有インフラでは、あるユーザーやジョブがキャッシュを独占したりディスクを飽和させたりCPUスケジューリングを圧迫したりしても、それ自体は「間違い」ではありません。OLTPはその巻き添えを食い、失敗はランダムな遅延として現れるため原因特定が難しくなります。
OLTPとOLAPを混在させると性能の頭痛だけでなく日々の運用が複雑になります。データベースが「何でも入りのボックス」になり、あらゆる運用タスクが両方のワークロードのリスクを引き受けます。
分析テーブルは幅が広く急速に成長することが多く、そのボリュームがリカバリストーリーを変えます。
フルバックアップはより時間がかかり、ストレージを多く消費し、バックアップウィンドウを逃す可能性が高くなります。リストアはさらに深刻で、迅速に復旧する必要があるときにトランザクションデータだけでなく大規模な分析データまですべて戻すことになります。災害復旧テストも時間がかかるため頻度が下がり、望ましくない循環になります。
トランザクションの成長は比較的予測可能です：顧客や注文の増加に伴って行数が増えます。一方で分析の成長は断続的です：新しいダッシュボード、保持ポリシーの変更、あるチームが「あと1年だけ生のイベントを残す」と決めるだけで増えます。
両者が混在すると、次のような疑問に答えにくくなります：
その不確実性が過剰プロビジョニング（無駄なコスト）や過小プロビジョニング（突発的な障害）を招きます。
共有データベースでは一つの「無害な」クエリがインシデントに発展します。ステートメントタイムアウト、ワークロードクォータ、スケジュールされたレポートウィンドウ、ワークロード管理ルールなどのガードレールを導入しますが、これらは脆弱で変更が片方のグループを壊すことがあります。
アプリケーションは通常、狭い目的別の権限が必要です。アナリストは多くのテーブルに跨る広い読み取り権限を必要とすることがあり、両者を同一データベースに置くと「レポートを動かすために広い権限を与える」圧力が生じ、ミスの影響範囲が広がり、機密データにアクセスできる人が増えます。
同じデータベースでOLTPとOLAPを動かそうとすると、初めは安く見えてもスケールするにつれてコストが跳ね上がります。問題は性能だけでなく、別々にスケールするべきワークロードを妥協して一緒にスケールせざるを得ない点です。
トランザクショナルシステムは書き込みに制約されます：多数の小さな更新、厳しいレイテンシー、急増を受け止める必要があります。OLTPのスケールは垂直スケール（より大きなCPU、高速ディスク、より多くのメモリ）になることが多く、書き込み中心の負荷は簡単に水平分散できません。
垂直限界に達したらシャーディングなどの書き込みスケーリングが必要になり、エンジニアリングコストが増えます。
分析ワークロードは長い走査や重い集計、高い読み取りスループットが必要です。多くのモダンな解析基盤は計算とストレージを分離し、クエリの計算力を独立して増やせます。
OLAPがOLTPデータベースを共有していると、分析だけを独立してスケールできず、データベース全体をスケールする必要があります—トランザクションが問題なくてもです。
トランザクションを速く保つために余分なCPU、ハイエンドストレージ、大きなインスタンスを過剰に用意してしまいがちです。つまりOLAPの振る舞いを支えるためにOLTP向けの高コスト設備を買っている状態です。
分離すると、それぞれのシステムを仕事に合わせてサイズ決めできます：OLTPは低レイテンシーな書き込み向け、OLAPはバースト的な重い読み取り向け。結果的に「二つのシステム」になっても総コストは下がることが多いです。
多くのチームは、**トランザクションワークロード（OLTP）と分析ワークロード（OLAP）**を、単一DBに押し込むのではなく、読み取り指向の第二システムを追加して分離します。
最初の一歩としてリードレプリカ（フォロワー）を作り、BIツールはそこにクエリを投げます。
長所：アプリ変更が最小、慣れ親しんだSQL、セットアップが速い。
短所：同じエンジンとスキーマなので重いレポートがレプリカのCPU/I/Oを枯渇させることがあり、レプリケーション遅延で数分以上のズレが生じることもあります。結果、「なぜ本番と一致しない？」という混乱が起きやすいです。
適合：小規模チーム、控えめなデータ量、「数分遅れ」が許容できる場合、レポートクエリが管理されている場合。
OLTPは書き込みとポイント読み取りに最適化し、分析はスキャン、圧縮、集計に強いデータウェアハウスへ移します。
長所：OLTP性能が予測可能、ダッシュボードが速い、アナリストの同時実行性に強い、コストと性能のチューニングが明確になる。
短所：別システムを運用する必要があり、分析向けのデータモデル（多くはスター・スキーマ）を作る必要がある。
適合：データが増えている、多くの利害関係者がいる、複雑なレポーティングがある、または厳しいOLTPレイテンシー要求がある場合。
定期ETLの代わりに、OLTPログからCDC（変更データキャプチャ）でウェアハウスへストリームします（多くはELTと組み合わせ）。
長所：OLTPへの負荷を抑えつつ鮮度を高められ、増分処理や監査性が向上する。
短所：構成要素が増え、スキーマ変更を丁寧に扱う必要がある。
適合：データ量が大きい、鮮度要件が高い、データパイプラインを運用する準備があるチーム。
トランザクションDBから分析システムへデータを移すのは「テーブルをコピーする」以上の話で、信頼できて本番に負荷をかけないパイプラインを作ることが目的です。
**ETL（Extract, Transform, Load）**はデータをウェアハウスに入れる前に整形します。ウェアハウスでの計算が高コストな場合や、格納データを厳格に管理したい場合に有効です。
**ELT（Extract, Load, Transform）**は生に近いデータをまずロードし、その後ウェアハウス内で変換します。設定が速く、要件変更に対応しやすいので、ソースの履歴を保持して後から変換を変えられる利点があります。
実践的ルール：ビジネスロジックが頻繁に変わるならELTで再作業を減らし、厳密にキュレートしたものだけを格納する必要があるならETLが向きます。
**CDC（Change Data Capture）**はOLTPのログからinsert/update/deleteをストリームし、分析側へ送ります。大きなテーブルを繰り返し走査する代わりに、変化分だけ移せます。
可能にすること：
鮮度はビジネス判断であり、技術的コストがあります。
利害関係者に「鮮度とは何か」のSLA（例：「データは15分以内に更新される」）を明確に伝えましょう。
パイプラインは静かに壊れることが多いので、軽量なチェックを追加します：
これらのガードによりOLAPの信頼性を保ちつつ、OLTPへの影響を避けられます。
OLTPとOLAPを一緒にしておくのが常に間違いというわけではありません。アプリが小さく、分析ニーズが狭く、分析が顧客に影響を与えないように厳しい境界を守れるなら一時的に合理的です。
軽量な分析と厳しいクエリ制限がある小さなアプリは単一DBでうまく回ることがあります。鍵は「軽量」が何を意味するか正直に定義すること：少数のダッシュボード、控えめな行数、クエリ実行時間と同時実行に上限を設けること。
定期レポートが少数であれば、マテリアライズドビューやサマリーテーブルで分析コストを下げられます。生トランザクションを走査する代わりに日次の集計を事前計算すれば、多くのクエリは短く予測可能になります。
遅延が許容できるならオフピークのレポート時間を設けることも有効です。重いジョブは夜間に走らせ、専用のレポーティングロールに限定された権限とリソース制限を与えます。
トランザクションレイテンシーの上昇、レポート実行時の定期的なインシデント、コネクションプールの枯渇、あるいは「ある1つのクエリが本番をダウンさせた」という話が出てきたら、安全圏を超えています。その時点でデータベースの分離（少なくともリードレプリカの利用）は最適化ではなく基本的な運用管理です。
分析を本番データベースから切り離す作業は大改修というより、可視化、目標設定、段階的な移行の連続です。
仮定ではなく証拠から始めます：
BIツールからのアドホックSQLやスケジュールジョブ、CSVエクスポートのような“隠れた”分析も含めます。
最適化すべき目標を書き出します：
これにより「遅い」「問題だ」の議論を避け、適切なアーキテクチャを選べます。
目標を満たす最も単純なオプションを選びます：
レプリカ遅延やパイプライン遅延、ダッシュボード実行時間、ウェアハウスの支出を監視します。クエリ予算（タイムアウト、同時実行制限）を設定し、鮮度が落ちたときや負荷が急増したときのプレイブックを用意します。
初期段階で高速に動く場合、最大のリスクは分析がいつのまにかコアトランザクション経路に取り込まれてしまうことです（たとえば、ダッシュボードクエリが知らずに“本番クリティカル”になってしまう）。これを避ける一つの方法は、分離を前提に設計しておくことです—たとえ小さなリードレプリカから始めるにしても、アーキテクチャチェックリストに分離を組み込んでおきます。
Koder.aiのようなプラットフォームはここで役立ちます。Reactアプリ＋Goサービス＋PostgreSQLでOLTP側をプロトタイプし、計画段階でレポーティング／ウェアハウスの境界を設計できます。プロダクトが成長したらソースコードをエクスポートし、スキーマを進化させ、CDC/ELTコンポーネントを追加して「本番でのレポーティング」を恒常的習慣にしないようにできます。
**OLTP（オンライン・トランザクション処理）**は、受注作成、在庫更新、支払い記録など日々の操作を扱います。優先するのは低レイテンシー、高い同時実行性、正確性です。
**OLAP（オンライン分析処理）**は、ダッシュボードやトレンド、コホート分析のような大規模なスキャンや集計で答えを導きます。優先するのはスループット、柔軟なクエリ、集計の高速化であり、ミリ秒応答は必須ではありません。
ワークロードが同じリソースを奪い合うためです：
結果として、コアなユーザー操作でのp95/p99レイテンシーが予測不能になります。
通常は難しいです。ダッシュボードを速くするためにインデックスを増やすと：
分析用途には、パーティショニング、カラムナストレージ、事前集計の方が効果的なことが多いです。
MVCCは読み書きのブロッキングを避けますが、混在ワークロードを“無償”にするわけではありません。実務上の問題は：
目に見えるブロッキングがなくても、分析が長期的に性能を劣化させます。
たとえば次のような兆候です：
ダッシュボード更新中にシステムが「ランダムに遅く」感じるなら、混在ワークロードの典型的な匂いです。
リードレプリカは最初の一歩としてよく使われます：
データ量が控えめで「数分遅れ」が許容される場合の橋渡しとして有効です。
次のような場合にデータウェアハウスが適しています：
通常は分析向けのデータモデル（スター／スノーフレーク）と、データをロードするためのパイプラインが必要です。
**CDC（Change Data Capture）**はOLTPの変更（insert/update/delete）をログ等からストリームして分析側へ送ります。
利点：
代償は、構成要素が増え、スキーマ変更や順序制御を慎重に扱う必要がある点です。
用途と要件次第です：
実務では、まずELTで始めておき、重要な指標が固まってきたらガバナンスやキュレーションを追加する、という流れが多いです。
はい、短期的には許容できます。ただし分析を本当に軽量に保ち、明確なガードレールを設ける必要があります：
レポート実行で定期的にレイテンシースパイクや接続枯渇が起きるようになったら、分離の時期です。