OLTPとOLAP

概要

OLTP（Online Transaction Processing）と OLAP（Online Analytical Processing）は、データベースにかかる負荷を性質で二分する古典的な区分です。OLTP は「注文を1件登録する」「残高を更新する」のような、少数の行だけに触れる小さな読み書きが大量に飛んでくる業務処理。OLAP は「過去3年の商品カテゴリ別売上推移を出す」のような、数億行を舐めて集計する重い読み取りが少数飛んでくる分析処理です。

この区分が重要なのは、両者に最適なデータベースの内部構造がほぼ正反対だからです。ECサイトの注文処理を捌く RDBMS に重い集計クエリを流すと、分析が遅いだけでなく、本業の注文処理まで巻き添えで遅くなります。「業務のDBと分析のDBは分ける」という現代のデータ基盤の大原則は、この負荷特性の違いから導かれています。

なぜ生まれたか

リレーショナルデータベースが普及した1980年代、企業はまず業務処理（受発注・会計・在庫）をデータベース化しました。これらはトランザクションの正確さと応答速度が命で、スキーマも更新の整合を保ちやすいよう正規化されています。ところがデータが溜まると、経営層は当然「このデータから傾向を読みたい」と考え始めます。業務システムに分析クエリを流すと、正規化された多数のテーブルを結合しながら全期間のデータを走査することになり、何時間もかかったうえ、その間ロックやI/O競合で業務処理が止まる — 同じデータベースに性質の異なる2種類の仕事をさせることの限界が露呈しました。

1993年、リレーショナルモデルの父 E.F. Codd が分析用途の処理を「OLAP」と名付けて業務処理（OLTP）と区別し、同時期に「業務システムから分析専用のデータベースへデータをコピーして分ける」データウェアハウスの考え方が確立します。つまり OLTP/OLAP という語彙は、「1つのDBに全部やらせる」ことの失敗から生まれた、負荷を分離するための設計語彙なのです。

詳細

負荷特性の対比

両者の違いを並べると、要求がほぼ正反対であることが分かります。OLTP はクエリ1本あたり数行に触れるだけですが、毎秒数千〜数万本が並行して飛び、書き込みも多く、ミリ秒単位の応答と ACID な整合性が求められます。ユーザーはエンドユーザーそのもので、遅延は直接体験を損ないます。OLAP はクエリ1本が数百万〜数十億行を走査しますが、本数は少なく、ほぼ読み取り専用で、応答は秒〜分単位でも許されます。ユーザーはアナリストやBIツールで、問われるのは個々の行ではなく集計値です。データの持ち方も、OLTP が現在の状態を正規化して持つのに対し、OLAP は履歴を長期間、集計しやすい形（スタースキーマなどの非正規化構造）で持ちます。

行指向と列指向 — ストレージ構造が正反対になる理由

この負荷の違いは、ディスク上のデータの並べ方にまで及びます。OLTP 向けデータベース（PostgreSQL、MySQL など）は行指向ストレージを採り、1行の全カラムをディスク上に連続して置きます。「注文ID 42 の行を丸ごと読む・書く」処理が1か所へのアクセスで済むからです。一方 OLAP 向けデータベースは列指向（カラムナ）ストレージを採り、同じカラムの値だけを全行ぶん連続して置きます。「全注文の金額カラムだけを合計する」クエリが、必要な列だけを読み飛ばしなしで走査できるからです。

列指向にはもうひとつ大きな利点があります。同じカラムには型も傾向も似た値が並ぶため（金額なら数値だけ、日付なら単調増加など）、圧縮が極めてよく効きます。データが10分の1に縮めば読むべきI/Oも10分の1になり、集計はさらに速くなります。逆に「1行を丸ごと更新する」処理は全カラムのファイルに書き込みが散らばるため、列指向はOLTPが苦手です。得意・不得意はきれいに裏返しの関係にあります。

DWHへの分離とデータの流れ

実際のシステムでは、OLTP を担う業務データベースから、OLAP を担うデータウェアハウス（DWH）へデータを定期的にコピーして分離します。この転送と変換の工程が ETL です。近年は変更をレプリケーションやCDC（変更データキャプチャ）でほぼリアルタイムに流し込む構成も一般的になりました。OLAP 側の代表的な製品は Snowflake、BigQuery、Amazon Redshift、ClickHouse などで、いずれも列指向ストレージと大規模並列処理を核にしています。より生データ寄りの置き場としてデータレイクを挟む構成や、両特性を1つのエンジンで担おうとする HTAP（Hybrid Transactional/Analytical Processing）という方向性もありますが、負荷特性の違いという原理そのものは変わりません。

実務での判断基準

この語彙の実務的な使いどころは、「そのクエリはどちらの性質か」を見分けて置き場所を決めることです。管理画面の集計が遅いからと業務DBにインデックスを足し続けるより、そのクエリはOLAPの仕事だと見抜いてDWHやマテリアライズドビューへ逃がすほうが筋がよい、という判断ができるようになります。逆にDWHに「1件だけ更新したい」処理を持ち込むのもミスマッチです。また、分析クエリを本番DBのレプリカに流す構成は手軽な第一歩ですが、行指向のままでは大規模集計の遅さは解決しないことも押さえておきたいポイントです。データベースをひとつの箱としてではなく、負荷特性で使い分ける複数の道具として見る — OLTP/OLAP はそのための最初の分類軸です。