LASSIC Media らしくメディア
OLTPとOLAPの違い｜データ処理の使い分け
LASSIC IT事業部｜元請（プライムベンダー）としてシステム開発・検証を受託
エンジニアやITベンダーとの打ち合わせで、「そこはOLTP向けのDBで受けています」「集計はOLAP側の基盤で行っています」といった言葉を耳にすることがあります。OLTP（オンライントランザクション処理）とOLAP（オンライン分析処理）は、どちらもデータベースが担う処理の分類を表す言葉ですが、目的も、扱うデータの性質も大きく異なるものです。この違いを整理しないまま基盤を設計してしまうと、業務システムの応答が遅くなったり、分析処理が思うように進まなかったりする事態につながりかねません。
本記事では、OLTPとOLAPという二つの処理方式の違いを、処理内容・データ量や更新頻度・レスポンス要件・スキーマ設計といった観点から整理します。特定の製品やDWH（データウェアハウス）の構築手順には深入りせず、発注担当者・PM・設計者が押さえておきたい「処理特性の違いと使い分けの考え方」に焦点を当てて解説します。
この記事のポイント
- OLTPは業務システムを支えるオンライントランザクション処理で、短時間の更新を数多く正確にさばくことに重きを置いた処理方式です。
- OLAPはオンライン分析処理で、蓄積された大量のデータを様々な切り口から集計・分析することに向いており、更新よりも参照や集計の性能が重視されます。
- 処理の性質が大きく異なるため、業務システム（OLTP）と分析基盤（OLAP）を分けて設計する考え方が広く採られています。
目次
OLTPとは（業務系のオンライントランザクション処理）
OLTP（Online Transaction Processing）とは、日々の業務の中で発生する短い取引（トランザクション）を、リアルタイムに近い形で処理する方式のことです。注文の登録、在庫の引き当て、口座残高の更新といった、一件ごとは小さいものの発生頻度の高い処理を、正確かつ迅速に積み重ねていく点に特徴があります。
身近な例：ECサイトの注文処理
ECサイトで買い物をする場面を思い浮かべると分かりやすいでしょう。商品をカートに入れる、注文を確定する、在庫数を減らす、決済結果を記録する――こうした一連の処理は、いずれも数件から数十件程度のレコードを対象にした、短時間で完結する更新です。多くの利用者が同時に注文を行っても、それぞれの注文データが矛盾なく記録されることが求められます。
短時間・高頻度の更新が中心
OLTPが対象とする処理は、一件あたりのデータ量は小さいものの、発生件数が多いという特徴を持ちます。基幹システムや業務アプリケーションの多くは、この種のオンライントランザクション処理を土台に成り立っており、データの整合性を保ちながら更新を積み重ねていくことが設計上の主眼になります。
OLAPとは（分析系のオンライン分析処理）
OLAP（Online Analytical Processing）とは、蓄積された大量のデータを、様々な切り口から集計・分析するための処理方式です。個々のレコードを更新することよりも、多数のレコードを横断的に読み取り、傾向や合計値を導き出すことに重きが置かれます。
身近な例：売上ダッシュボードの集計
「今月の地域別・商品カテゴリ別の売上を確認したい」「四半期ごとの推移を前年と比較したい」といった要望に応えるのが、OLAPの得意とする処理です。数百万件、数千万件といった規模のデータをまとめて集計し、担当者が見たい切り口でグラフや表として提示することが求められます。
大量データを様々な軸で参照する処理
OLAPで扱われるデータの多くは、業務システムで発生した記録を一定の周期でまとめて取り込んだものです。一件ずつの更新はほとんど発生せず、代わりに大量データへの参照と集計が繰り返し実行されます。分析の切り口（時系列、地域、商品、顧客層など）が多岐にわたることも、OLAPの処理を特徴づける要素の一つといえるでしょう。
両者の違い：対比表と構成図
OLTPとOLAPは、どちらも「データベースに対する処理」という点では共通していますが、扱うデータの単位や処理の目的という前提が大きく異なります。主な観点を次の表に整理します。
| 観点 | OLTP（業務系） | OLAP（分析系） |
|---|---|---|
| 主な処理 | 登録・更新・削除など短いトランザクション | 大量データの集計・参照 |
| 一件あたりのデータ量 | 小さい（数件〜数十件規模） | 大きい（数百万件規模の集計対象） |
| 更新頻度 | 高い（常時発生） | 低い（バッチ取り込みが中心） |
| 求められる応答 | ミリ秒〜秒単位の即時応答 | 秒〜分単位でも許容されやすい |
| スキーマ設計 | 正規化されたテーブル構造 | スタースキーマなど非正規化寄りの構造 |
| 主な利用者 | 業務アプリケーションの利用者 | 経営層・分析担当者 |
対比表からも分かるとおり、OLTPとOLAPはどちらか一方が優れているという関係ではなく、目的そのものが異なる処理です。次の図では、業務システムで発生したデータが分析基盤へ流れていく構成の一例を示します。
データ量・更新頻度・レスポンス要件の観点
OLTPとOLAPの違いが最も実務に効いてくるのが、データ量・更新頻度・レスポンス要件という三つの観点です。
一回の処理が扱うデータ量
OLTPの一回の処理は、注文一件、口座一件といった単位のレコードを対象とすることがほとんどです。一方でOLAPの一回の処理は、数十万件から数千万件といった規模のレコードをまとめて読み取り、集計することになります。扱うデータ量の桁が違うため、求められるインデックス設計やクエリの最適化の方向性も自然と変わってきます。
更新頻度とレスポンス要件
OLTPでは、利用者の操作に応じて更新が絶えず発生し、その都度ミリ秒から数秒程度での応答が期待されます。応答が遅れれば、業務アプリケーションの利用者に直接ストレスを与えることになるでしょう。対してOLAPでは、データの取り込みは一定周期のバッチ処理で行われることが多く、集計結果を得るまでに数秒から数分程度かかっても許容されやすい傾向にあります。
データの保持期間という視点
OLTPが扱う業務データは、直近の状態を正確に保つことが優先され、古いデータは別の場所へ移すか、参照頻度の低い形で保管されることも珍しくありません。OLAPで扱うデータは、傾向を分析する目的上、数年単位の履歴をまとめて保持することが求められる場合が多く、この点でもデータの性質が異なっています。
スキーマ設計の違い（正規化 vs スタースキーマ）
処理の目的が異なれば、データベースのテーブル構造（スキーマ）の設計方針も変わってきます。
OLTPにおける正規化設計
OLTPのデータベースは、更新時の矛盾を防ぐために、データを正規化して設計することが基本になります。同じ情報を複数の場所に重複して持たないようにテーブルを分割し、更新は一箇所だけで済むように整理する考え方です。これにより、注文情報や顧客情報を更新した際に、他の場所のデータと食い違ってしまうリスクを抑えられます。
OLAPにおけるスタースキーマなどの非正規化設計
OLAPのデータベースでは、集計のしやすさを優先し、あえて正規化の度合いを緩めた設計が採られることがあります。代表的なものがスタースキーマと呼ばれる構造で、集計の対象となる「ファクトテーブル」を中心に、日付・商品・地域といった分析の軸となる「ディメンションテーブル」を放射状に配置する形です。この構造により、複雑な結合処理を減らし、様々な切り口での集計を扱いやすくする狙いがあります。
設計思想の違いが表す目的の違い
正規化とスタースキーマは、どちらかが優れた設計というわけではありません。更新時の整合性を優先するか、集計時の扱いやすさを優先するかという、目的の違いがそのままスキーマ設計の違いとして表れているものと捉えるとよいでしょう。
なぜ業務DBと分析基盤を分けるのか
OLTPとOLAPは処理特性が異なるため、同じデータベースの上でどちらも動かそうとすると、様々な無理が生じやすくなります。
分析処理が業務システムを圧迫するリスク
業務システムのデータベースに対して、大量データを対象とする集計クエリを直接実行すると、そのクエリが処理している間、他の利用者からの更新や参照の応答が遅くなることがあります。業務時間中に重い分析クエリが走ってしまい、注文処理が滞るといった事態は、実務でもたびたび聞かれる課題です。
参照系と更新系を分離する考え方
こうした問題を避けるため、業務システムのデータを一定周期で分析基盤側へ複製・集約し、分析処理は複製先のOLAP環境で実行するという構成が広く採られています。業務システム側は更新処理に専念でき、分析基盤側は集計しやすい形に整えられたデータを使って、負荷を気にせず様々な分析を行えるようになるという利点があります。
分けることで得られる設計上の余地
業務DBと分析基盤を分離すると、それぞれに適したインデックス設計やハードウェア構成を個別に検討できるようになります。更新の即時性が求められるOLTP側と、大量データの読み取り効率が求められるOLAP側を、同じ制約の中で無理に両立させる必要がなくなる点は、基盤設計における大きな利点といえるでしょう。
使い分けと設計・発注時の確認点
OLTPとOLAPのどちらの設計思想に寄せるべきかは、次のような判断軸を確認すると整理しやすくなります。
- 処理の主目的――一件ずつの正確な更新なのか、大量データの集計・分析なのか
- 求められる応答時間――利用者を待たせない即時応答が必須なのか、多少の待ち時間が許容されるのか
- データの保持期間――直近の状態を保てばよいのか、数年単位の履歴が必要なのか
- 分析の切り口の多さ――特定の集計だけでよいのか、様々な軸で自由に分析したいのか
- 既存システムへの影響――分析処理を業務システムと同じ基盤で行うことが、応答性能にどこまで影響し得るか
発注時に確認しておきたい点
システム開発を発注する際は、業務システム部分がOLTPとしてどのような更新処理を担い、分析部分がOLAP的にどのような集計を担うのかを、要件定義の段階で切り分けて整理しておくと、後の手戻りを抑えやすくなります。分析要件を業務システムのデータベースへそのまま追加してしまうと、後になって性能面の課題が表面化することも少なくありません。あらかじめ、どこまでを業務系のデータベースで完結させ、どこから分析基盤側に任せるのかという役割分担を確認しておくことが望ましいでしょう。
まとめ：処理特性の違いを踏まえた基盤設計
本記事では、OLTPとOLAPという二つの処理方式の違いについて、処理内容・データ量や更新頻度・レスポンス要件・スキーマ設計といった観点から整理しました。OLTPは業務システムを支える短いトランザクション処理、OLAPは蓄積されたデータを様々な軸で集計する分析処理であり、目的も設計の考え方も異なるものです。
データ量・更新頻度・保持期間・分析の切り口の多さといった判断軸を確認しながら、業務システムと分析基盤の役割を分けて設計することが、無理のないシステム構成につながるでしょう。処理の性質を踏まえた役割分担は、発注段階から意識しておきたいポイントです。
よくある質問
1つのデータベースでOLTPとOLAPの両方はできないのですか。
技術的に不可能というわけではありませんが、あまり推奨されません。同じデータベースに大量の集計クエリを流すと、業務システム側の更新や参照の応答が遅くなることがあるためです。小規模なシステムで分析要件も限定的であれば同居させる例もありますが、データ量や分析の頻度が増えるにつれて、分析基盤を分離する構成が選ばれやすくなります。
OLAPを導入するにはDWH（データウェアハウス）は必要ですか。
必須というわけではありません。分析するデータの量や、求められる分析の切り口の多さによっては、業務システムのレプリカや専用の集計テーブルといった軽量な構成で対応できる場合もあります。ただし、複数のシステムにまたがるデータを横断的に分析したい場合や、長期間の履歴を扱いたい場合には、専用の分析基盤を用意する構成が向いていることが多いでしょう。
OLTPとOLAPは、どちらの方が難しい設計ですか。
どちらか一方が一概に難しいとは言えません。OLTPは更新時の整合性を保つための正規化やトランザクション制御の設計が求められ、OLAPは大量データを扱う際の集計効率やスキーマ設計が課題になります。求められる知識や配慮すべき点の種類が異なると捉えるのが実態に近いでしょう。
業務システムのデータをOLAP側にどう反映させればよいですか。
ETL（抽出・変換・格納）と呼ばれる処理を使い、一定の周期で業務システムのデータを分析基盤側へ取り込む方法が広く採られています。取り込みの頻度は、日次でまとめて行う場合もあれば、より短い間隔で反映する場合もあり、求められる分析のタイムリーさに応じて設計されます。
スタースキーマ以外の設計方法もありますか。
あります。スタースキーマを発展させた形として、ディメンションテーブルをさらに分割するスノーフレークスキーマといった構造も知られています。どの設計を選ぶかは、分析したい切り口の複雑さやデータ量、運用のしやすさとのバランスによって判断されるものです。
著者：テレリモ総研編集部 鈴木 亮佑
システム開発・データ基盤のご相談はLASSICへ
元請（プライムベンダー）として、業務システムと分析基盤の役割整理から、基盤構築を含むシステム開発までご提案します。まずはお気軽にご相談ください。
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：IPA（情報処理推進機構）基本情報技術者試験シラバスにおけるデータベース・データ処理方式に関する解説（https://www.ipa.go.jp/shiken/syllabus/index.html）
