9日目: データベースとデータウェアハウスの決定的な違いを理解する（OLTP vs OLAP）
はじめに：OLTPとOLAP、似て非なる2つの世界
昨日の記事では、データウェアハウス（DWH）がなぜ必要になったのか、その歴史的な背景を学びました。今日はその核心に迫ります。
データベースとデータウェアハウスの根本的な違いは、それぞれが担う処理の種類にあります。それが「OLTP（On-Line Transaction Processing）」と「OLAP（On-Line Analytical Processing）」です。この2つの概念を深く理解することが、適切なデータ基盤を設計するための鍵となります。
1. OLTP：日々の業務を高速に処理する「トランザクション」
OLTPは「On-Line Transaction Processing」の略で、日本語では「オンライン取引処理」と訳されます。これは、1週目で私たちが扱ってきたデータベースが得意とする分野です。
特徴：
- 目的: リアルタイムのトランザクション処理。ECサイトでの注文、銀行のATMでの入出金、顧客情報の登録など、個々の取引を高速かつ確実に実行します。
- データの操作: 書き込み（INSERT, UPDATE, DELETE） が中心となります。ユーザーが操作するたびに、少量のデータが頻繁に更新されます。
- データ構造: データの一貫性を保ち、冗長性（重複）をなくすために「正規化」された設計が採用されます。複数のテーブルにデータを細かく分割し、外部キーで関連付けます。
- 応答速度: ユーザーの操作を妨げないよう、ミリ秒単位での高速な応答が求められます。
- 代表例: Oracle Database、MySQL、PostgreSQLなど。
レストランの例で言えば、お客様からの注文を記録するPOSシステムがOLTPです。1つの注文という小さなトランザクションを、リアルタイムに処理することに特化しているわけです。
【なぜ正規化が必要なのか？】
OLTPにおいて、正規化は非常に重要な概念です。たとえば、顧客情報、注文情報、商品情報がすべて1つの巨大なテーブルにまとめられていると想像してみてください。
- データの更新: ある顧客の住所が変更になった場合、その顧客の過去すべての注文レコードの住所を更新する必要が出てきます。これは非効率で、更新漏れのリスクも高まります。
- データの整合性: 間違って顧客IDと異なる住所が登録されるなど、データの不整合が発生しやすくなります。
- データ量の増加: 同じ情報（例：商品名）が何度も重複して保存され、無駄にディスク容量を消費します。
正規化は、このような問題を解決するために、データを複数のテーブルに分割し、重複をなくすためのルールです。たとえば、customersテーブルとordersテーブルを分け、ordersテーブルにはcustomer_idだけを持たせることで、顧客の住所変更はcustomersテーブルの1レコードを更新するだけで済みます。
この設計は書き込み処理を効率化しますが、分析時にデータを取得する際には、複数のテーブルを結合（JOIN）する必要があり、複雑で時間がかかります。
2. OLAP：大量データを分析する「アナリティクス」
一方、OLAPは「On-Line Analytical Processing」の略で、「オンライン分析処理」を意味します。これは、データウェアハウスが最も得意とする分野です。
特徴：
- 目的: 大量の過去データに対する分析。経営者が売上トレンドの分析、市場予測、顧客行動のセグメンテーションなど、ビジネスの意思決定を支援するためのインサイト（洞察）を得ることが目的です。
- データの操作: 読み取り（SELECT） が中心となります。データの更新や削除はほとんど行われず、主に過去のデータを集計したり、スライス＆ダイス（多角的な切り口で分析）します。
- データ構造: 分析クエリを高速化するため、非正規化された設計が採用されます。複数のテーブルをあらかじめ結合した「ファクトテーブル」と「ディメンションテーブル」で構成される「スタースキーマ」などが代表的です。
- 応答速度: クエリが複雑で大量のデータを扱うため、応答には数秒から数分かかることもあります。しかし、日々の業務に影響を与えることはありません。
- 代表例: Snowflake、Google BigQuery、Amazon Redshiftなど。
レストランの例では、「過去1年間で最も売れたメニューは何だったか？」「どの曜日が最も客足が多かったか？」といった問いに答えるための分析レポートを作成するのがOLAPです。膨大な過去データを、多角的に集計・分析することに特化しています。
【なぜ非正規化が必要なのか？】
OLAPでは、正規化とは逆の「非正規化」が一般的です。これは、分析の効率を最優先するためです。
たとえば、OLTPではsalesテーブル、productsテーブル、customersテーブルが分かれている場合、商品の売上を顧客属性別に分析するには、3つのテーブルを複雑にJOINする必要があります。
しかし、OLAPでは、分析に必要な情報をあらかじめ結合したテーブル（ファクトテーブル）を用意します。これにより、多くの分析クエリが1つの巨大なテーブルにアクセスするだけで済み、JOINのオーバーヘッドが大幅に削減され、クエリが劇的に高速化されます。
この非正規化されたテーブル群の代表的な設計モデルが「スタースキーマ」です。
- ファクトテーブル: 売上、注文数など、ビジネスの事実（ファクト）を記録したテーブル。大量のデータが含まれます。
- ディメンションテーブル: 日付、顧客、商品など、ファクトを多角的に分析するための切り口（ディメンション）を記録したテーブル。データ量は比較的少ないです。
このスタースキーマ構造は、分析の柔軟性とクエリパフォーマンスを両立させるための、OLAPにおける重要な設計思想です。
3. OLTPとOLAPのアーキテクチャの違い
この2つの違いを決定づけるのは、根本的な**アーキテクチャ（設計思想）**の違いです。
- OLTP: データは主に「行（Row）」単位でディスクに保存されます。これにより、1つのトランザクションで1つの行を素早く読み書きする操作に適しています。
-
OLAP: データは主に「列（Column）」単位でディスクに保存されます。これを「カラムナー型ストレージ」と呼びます。分析クエリでは、特定の列（例：
salesテーブルのprice列）だけを対象に集計することが多いため、列ごとにデータがまとまっていると、必要なデータだけを効率的に読み込めます。これがOLAPの高速な分析を支える技術の根幹です。
| 比較項目 | OLTP（データベース） | OLAP（データウェアハウス） |
|---|---|---|
| 主な目的 | 日々の業務処理 | 大規模なデータ分析 |
| 主な操作 | INSERT, UPDATE, DELETE | SELECT, 集計 |
| データ構造 | 正規化された構造 | 非正規化された構造 (スタースキーマなど) |
| データ量 | ギガバイト（GB）〜テラバイト（TB） | テラバイト（TB）〜ペタバイト（PB） |
| 応答時間 | ミリ秒単位 | 秒〜分単位 |
| ストレージ | 行指向 | 列指向（カラムナー型） |
| 代表製品 | Oracle, MySQL | Snowflake, BigQuery |
【具体的なクエリの比較】
-
OLTPクエリ:
SELECT * FROM orders WHERE order_id = 12345;(単一のレコードを素早く検索) -
OLAPクエリ:
SELECT customer_age, SUM(total_price) FROM sales_fact GROUP BY customer_age;(数百万行を対象に特定の列を集計)
OLTPの行指向ストレージでは、2番目のクエリを実行する際に、customer_ageとtotal_price以外の列も読み込む無駄が発生します。一方、OLAPのカラムナー型ストレージでは、必要な2つの列だけを読み込めば良いため、圧倒的に高速に処理が完了します。
4. 2つのシステムの共存：モダンデータアーキテクチャの基本
現代のデータ基盤では、OLTPとOLAPのどちらか一方だけを選ぶわけではありません。両者が連携して機能します。
- OLTPデータベースで、顧客の注文や取引といったビジネスの事実を正確に記録。
- ETL/ELT（抽出、変換、ロード）プロセスを通じて、OLTPデータベースからデータを定期的に抽出し、OLAPデータウェアハウスに格納。
- OLAPデータウェアハウスに蓄積されたデータを、BIツールや機械学習モデルで分析し、ビジネスのインサイトを獲得。
- そのインサイトを基に、マーケティング施策の改善や新商品の開発といった、新たなビジネスアクションにつなげる。
このサイクルを回すことで、企業はデータに基づいた意思決定を迅速に行えるようになります。データエンジニアは、このサイクルの流れを設計し、構築し、運用する役割を担います。
まとめ：目的と役割に応じた使い分け
データベースとデータウェアハウスは、どちらもデータを扱うシステムですが、その目的、設計、そしてパフォーマンス特性はまったく異なります。OLTPとOLAPというキーワードは、これらの違いを明確に理解するための強力なツールです。
「OLTPでデータを効率的に記録し、そのデータをOLAPで深く分析する」というこの関係性を理解すれば、なぜ両方のシステムが現代のビジネスにとって不可欠なのかが分かります。
明日からは、このOLAPの世界を代表する最新のクラウドデータウェアハウス、Snowflakeに焦点を当て、その革新的なアーキテクチャを具体的に解説します。
- 明日（10日目）: クラウドDWの先駆者！Snowflakeのアーキテクチャを徹底解説