OLTPとOLAP
トランザクションデータベースと分析データベースを比較します
「OLTPとOLAP」はCoddyKit上の無料SQL Academyレッスンです。 これはレッスン1/4です。 下記で完全なレッスンを無料で読むことができます。その後、ブラウザ内の組み込みコードエディタと24時間対応のAIチューターでハンズオン演習できます。 これはSQL Academy学習パスの一部であり、ウェブとCoddyKitアプリ全体で進捗が同期されます。 SQL Academyコースには全4レッスンが含まれています。
OLTPとOLAPとは
データベースは、どの用途にも同じように使えるわけではありません。データベースの設計と運用方法を形作ってきた、根本的に異なる2種類のワークロードがあります。それがOLTP(Online Transaction Processing)とOLAP(Online Analytical Processing)です。
この違いを理解することは、データに関わるすべての専門家にとって重要です。OLTPとOLAPのどちらを選ぶかによって、クエリ速度、ストレージコスト、そしてデータシステム全体のアーキテクチャが決まります。
OLTP:トランザクション向け
OLTPシステムは、リアルタイムのビジネスイベントを反映する、短時間で完了する高速な操作を大量に処理します。操作には、挿入、更新、削除などがあります。注文の登録、決済の処理、顧客情報の更新などがその例です。
OLTPの主な特性は、操作ごとの低レイテンシ、高い同時実行性、強い整合性です。データの完全性を守るため、すべてのトランザクションはACIDに準拠する必要があります。
-- OLTP example: inserting a new order
INSERT INTO orders (customer_id, product_id, quantity, order_date)
VALUES (1042, 88, 3, CURRENT_DATE);
-- Immediately update inventory
UPDATE inventory
SET stock = stock - 3
WHERE product_id = 88;OLAP:分析向け
OLAPシステムは、大量の過去データをスキャンして傾向、パターン、集計結果を明らかにする複雑なクエリに最適化されています。ビジネスアナリストやデータサイエンティストは、OLAPを使って「前四半期の地域別の総売上はいくらだったか」のような問いに答えます。
OLAPクエリでは、数百万行を集計したり、ファクトテーブルとディメンションテーブルをまたいで複数の結合を実行したりすることがよくあります。個々の書き込み速度は二次的な要素であり、重要なのは読み取りスループットとクエリの柔軟性です。
-- OLAP example: total sales by region for Q1 2024
SELECT
d.region,
SUM(f.sales_amount) AS total_sales,
COUNT(f.order_id) AS order_count
FROM fact_sales f
JOIN dim_date dd ON f.date_key = dd.date_key
JOIN dim_store d ON f.store_key = d.store_key
WHERE dd.year = 2024
AND dd.quarter = 1
GROUP BY d.region
ORDER BY total_sales DESC;2つの方式を並べて比較する
この違いを覚える最も簡単な方法は、それぞれのシステムを誰が、どのように使うかを考えることです。
- OLTP:アプリケーションのバックエンドで使用されます。同時に利用するユーザーが数千人いて、各クエリが扱う行は数行です。
- OLAP:アナリストやレポートツールで使用されます。同時に実行されるクエリは少ないものの、各クエリが数百万行をスキャンします。
このようにアクセスパターンが異なるため、スキーマ設計、インデックス戦略、さらにはハードウェアの選択も大きく異なります。
-- OLTP: lookup a single customer's latest order (row-level access)
SELECT o.order_id, o.order_date, o.total_amount
FROM orders o
WHERE o.customer_id = 1042
ORDER BY o.order_date DESC
LIMIT 1;
-- OLAP: monthly revenue trend over the past year (aggregate scan)
SELECT
DATE_TRUNC('month', order_date) AS month,
SUM(total_amount) AS revenue
FROM orders
WHERE order_date >= CURRENT_DATE - INTERVAL '12 months'
GROUP BY 1
ORDER BY 1;スキーマ設計:正規化と非正規化
OLTPデータベースでは、冗長性を排除し、書き込みを効率化するため、正規化スキーマ(3NF以上)が好まれます。各エンティティを独自のテーブルに格納することで、トランザクションごとに処理するデータ量を減らせます。
OLAPデータベースでは、非正規化スキーマ、特にスタースキーマやスノーフレークスキーマが好まれます。これらではデータがあらかじめ結合され、冗長性も持たせています。そのため、クエリ実行時の高コストな結合が不要になり、列指向ストレージエンジンでデータをより高速にスキャンできます。
-- Normalized OLTP design (3NF)
CREATE TABLE customers (
customer_id SERIAL PRIMARY KEY,
name VARCHAR(100),
email VARCHAR(150) UNIQUE
);
CREATE TABLE orders (
order_id SERIAL PRIMARY KEY,
customer_id INT REFERENCES customers(customer_id),
order_date DATE,
total NUMERIC(10,2)
);
-- Denormalized OLAP fact table (star schema)
CREATE TABLE fact_sales (
sale_id BIGINT PRIMARY KEY,
customer_key INT,
date_key INT,
product_key INT,
region VARCHAR(50),
category VARCHAR(50),
amount NUMERIC(12,2)
);インデックス戦略の違い
OLTPシステムでは、トランザクション内で単一行を高速に検索し、効率的に結合できるよう、主キーと外部キーに対するB-treeインデックスを多用します。
OLAPシステムでは、ビットマップインデックス、列指向ストレージ、パーティショニングが効果を発揮します。データが行単位ではなく列単位で格納されていれば、列全体(例:すべての売上金額)をスキャンする処理をはるかに効率化できます。
-- OLTP: B-tree index for fast order lookup by customer
CREATE INDEX idx_orders_customer
ON orders (customer_id);
-- OLTP: compound index for range queries
CREATE INDEX idx_orders_date_customer
ON orders (order_date, customer_id);
-- OLAP: partition fact table by year to prune scan
CREATE TABLE fact_sales_2024
PARTITION OF fact_sales
FOR VALUES FROM ('2024-01-01') TO ('2025-01-01');同時実行性とロック
OLTPシステムでは、競合を起こさずに数千件の同時書き込みを処理する必要があります。データベースは行レベルロックとMVCC(多版型同時実行制御)を使用し、読み取りが書き込みをブロックせず、その逆も起きないようにします。
OLAPクエリはほとんどが読み取り専用です。ロックが問題になることはまれですが、長時間実行されるスキャンは大量のCPUとI/Oを消費する可能性があります。多くのデータウェアハウスでは、OLTPのソースからバッチETLまたはCDC(変更データキャプチャ)でデータを投入した別のシステム上でOLAPを実行します。
-- OLTP: explicit transaction with row-level lock
BEGIN;
SELECT balance
FROM accounts
WHERE account_id = 7
FOR UPDATE;
UPDATE accounts
SET balance = balance - 200
WHERE account_id = 7;
COMMIT;ETL:OLTPとOLAPをつなぐ
OLTPとOLAPでは設計が互換性を持たないため、組織ではETL(抽出、変換、ロード)パイプラインを実行し、トランザクションデータベースのデータを分析用データウェアハウスへ定期的(毎晩、毎時、またはほぼリアルタイム)にコピーして再構成します。
ETLプロセスでは、正規化されたOLTPの行を非正規化されたファクトおよびディメンションのレコードに変換し、その過程でビジネスロジック(例:通貨換算、顧客セグメンテーション)も適用します。
-- Simplified ETL INSERT from OLTP orders into OLAP fact table
INSERT INTO fact_sales (
customer_key,
date_key,
product_key,
amount
)
SELECT
dc.customer_key,
dd.date_key,
dp.product_key,
o.total_amount
FROM orders o
JOIN dim_customer dc ON dc.source_customer_id = o.customer_id
JOIN dim_date dd ON dd.calendar_date = o.order_date
JOIN dim_product dp ON dp.source_product_id = o.product_id
WHERE o.order_date = CURRENT_DATE - INTERVAL '1 day'
AND o.order_id NOT IN (SELECT source_order_id FROM fact_sales);典型的なOLAPクエリパターン
OLAPクエリでは、ほぼ必ず集計(SUM、COUNT、AVG)、複数のディメンションにまたがるグループ化、日付範囲やカテゴリによるフィルタリングを行います。これらはダッシュボードや業務レポートの基本要素です。
ウィンドウ関数は、OLAPワークロードで特に強力です。自己結合を使わずに、各期間の数値を前の期間と比較できます。
-- Year-over-year revenue comparison using a window function
SELECT
dd.year,
dd.quarter,
SUM(f.amount) AS revenue,
LAG(SUM(f.amount)) OVER (PARTITION BY dd.quarter
ORDER BY dd.year) AS prev_year_revenue,
ROUND(
100.0 * (SUM(f.amount) -
LAG(SUM(f.amount)) OVER (PARTITION BY dd.quarter
ORDER BY dd.year))
/ NULLIF(LAG(SUM(f.amount)) OVER (PARTITION BY dd.quarter
ORDER BY dd.year), 0)
, 2) AS yoy_pct_change
FROM fact_sales f
JOIN dim_date dd ON f.date_key = dd.date_key
GROUP BY dd.year, dd.quarter
ORDER BY dd.quarter, dd.year;HTAP:境界をなくす
TiDB、SingleStore、PostgreSQL + 列指向拡張機能などの最新システムは、HTAP(ハイブリッドトランザクション/分析処理)を実装しています。これらは1つのエンジンで両方のワークロードを処理し、OLTPシステムとOLAPシステムを別々に運用する複雑さを解消することを目指しています。
HTAPでは、データを2つの形式で同時に保存することでこれを実現します。トランザクションの書き込みには行ストアを、分析の読み取りには列ストアを使用し、両者を自動的に同期します。
-- PostgreSQL with cstore_fdw (columnar extension) example
-- Analytical table stored in columnar format
CREATE FOREIGN TABLE fact_sales_columnar (
date_key INT,
product_key INT,
region VARCHAR(50),
amount NUMERIC(12,2)
)
SERVER cstore_server
OPTIONS (filename '/data/fact_sales_columnar');
-- Regular OLTP table remains row-based
-- Both can be queried in the same SQL statement
SELECT f.region, SUM(f.amount)
FROM fact_sales_columnar f
GROUP BY f.region;適切なシステムの選択
OLTP、OLAP、HTAPのどれを選ぶかは、主なワークロードによって決まります。
- リアルタイムでイベントを記録するアプリケーションを構築する場合は、OLTPデータベース(PostgreSQL、MySQL、SQL Server)を使用します。
- 履歴データを基にしたレポート層を構築する場合は、OLAPデータウェアハウス(BigQuery、Redshift、Snowflake、ClickHouse)を使用します。
- 両方が必要で、運用をシンプルにしたい場合は、HTAPの選択肢を評価します。
本番環境のアーキテクチャでは、OLTPデータベースを正本となる記録システムとして使用し、ETLパイプラインで接続した別のデータウェアハウスを分析に使用する構成が多く採用されています。
-- Quick diagnostic: check table access pattern
-- High seq_scan relative to idx_scan = analytical (OLAP-like) load
SELECT
relname AS table_name,
seq_scan,
idx_scan,
n_live_tup AS live_rows
FROM pg_stat_user_tables
ORDER BY seq_scan DESC
LIMIT 10;理解度チェック
OLTPシステムとOLAPシステムの主な違いについて、理解度を確認しましょう。
レッスンのまとめ
OLTPとOLAP — 主なポイント:
- OLTPはリアルタイムのトランザクションワークロードを処理します。ACID保証のもとで、高速かつ同時実行可能な行レベルの書き込みを行います。
- OLAPは分析ワークロードを処理します。非正規化スキーマを使用し、大規模な履歴データセットに対して複雑な集計を行います。
- スキーマ設計はワークロードに応じて決まります。OLTPでは正規化(3NF)、OLAPではスタースキーマまたはスノーフレークスキーマを使用します。
- ETLパイプラインが2つのシステムをつなぎ、変換したOLTPデータを分析用データウェアハウスにロードします。
- HTAPシステムは、行ストレージと列ストレージを二重に使用し、1つのエンジンで両方のワークロードに対応しようとします。
最初から適切なアーキテクチャを選択すれば、後の困難な移行を防ぎ、ユーザーが期待する速度でクエリを実行できます。
よくある質問
「OLTPとOLAP」レッスンは無料ですか?
はい。「OLTPとOLAP」の完全なテキストはこのウェブで無料で読めます。インタラクティブに演習し(組み込みコードエディタと24時間対応のAIチューター)、SQL Academyコースの残りをアンロックするには、CoddyKit PROにアップグレードしてください。 SQL Academyコースには全4レッスンが含まれています。
「OLTPとOLAP」で何を学びますか?
トランザクションデータベースと分析データベースを比較します ブラウザで直接実行するハンズオンコードでSQL Academyを演習し、24時間対応のAIチューターがレッスンを進める中での質問に答えます。
SQL Academyを始めるのに経験は必要ですか?
事前経験は必要ありません。CoddyKitのSQL Academyは初級者から上級者向けに構成されているため、ここから始めるか最初から始めて、自分のペースで進むことができます。 これはレッスン1/4です。
「OLTPとOLAP」レッスンにはどのくらい時間がかかりますか?
ほとんどのCoddyKitレッスンは約5~10分かかります。各レッスンはコンパクトでインタラクティブなので、着実に進歩し、ウェブとアプリ全体で正確に前回の場所から再開できます。
このSQL Academyレッスンでコードを書いて実行できますか?
はい。すべてのSQL Academyレッスンに組み込みコードエディタが含まれているため、ブラウザでリアルコードを書いて実行し、即座のAIフィードバックを取得できます。ローカル設定は不要です。