OLTP vs OLAPの違いとは？クラウドDB選定でエンジニアが知るべきデータ処理の基礎ガイド

「OLTPとOLAPの違いって説明できる？」と聞かれて、自信を持って答えられなかった経験はないでしょうか。オンプレ時代はOracleやSQL Serverを一台のDBサーバーで何でも賄ってきたエンジニアにとって、この区別は意外と意識する機会がありません。ところがクラウドへ移行するとき、この違いを理解していないと「分析クエリが重くて本番DBが落ちそう」「Amazon RedshiftとRDSをどう使い分ければいい?」という問題に直面します。

この記事では、OLTPとOLAPの本質的な違いを整理したうえで、クラウド上での具体的なサービス選定基準を解説します。AWS・Azureを中心に、料金感覚や設計の落とし穴まで現場目線でカバーします。

なぜOLTPとOLAPの区別がクラウド移行で重要になるのか

オンプレ環境では、よくある構成として「高スペックなOracleサーバーに業務DBと分析クエリを同居させ、夜間バッチで集計する」というやり方をしてきた方も多いはずです。機材が手元にあるため、CPUやメモリを増強することでなんとか乗り切ってきました。

クラウドに移行すると、コンピュートリソースはその使い方に応じて課金されます。分析用の大量データスキャンと、業務トランザクションのリアルタイム処理を同じDBインスタンスで動かすのは、コストと性能の両面で非効率です。ワークロードの特性に合ったサービスを使い分けることが、クラウドコスト最適化の基本原則です。

OLTPとOLAPを明確に分けることで、以下が実現できます。
・本番DBへの影響ゼロ: 夜間バッチの分析クエリが業務トランザクションを妨げない
・コスト最適化: 分析用はコンピュートを止めれば課金されないDWHサービスに寄せられる
・スケールの柔軟性: 分析基盤だけを需要に応じてスケールアップできる

OLTPとOLAPの基本的な違い

1. OLTP（Online Transaction Processing）とは

OLTPは、日常業務のトランザクション処理を指します。受注、在庫引当、会計仕訳、ユーザー登録など、「1件ずつ素早く処理する」操作の集合です。

OLTPシステムの特徴はこの通りです。
・操作単位: 数行～数十行のINSERT / UPDATE / DELETE
・同時接続数: 数百～数千の同時セッション
・応答時間の要件: ミリ秒～数十ミリ秒
・データ鮮度: 常に最新のトランザクションデータを反映
・インデックス戦略: 主キー・外部キー中心の細粒度インデックス

オンプレ環境でOLTPを担ってきたのは、Oracle Database、Microsoft SQL Server、MySQL、PostgreSQLといった行指向のRDBMSです。

2. OLAP（Online Analytical Processing）とは

OLAPは、蓄積された大量データを分析・集計する処理を指します。「先月の商品カテゴリ別売上を地域ごとに集計する」「過去3年のユーザー行動パターンをセグメント分析する」といった操作が典型例です。

OLAPシステムの特徴はこの通りです。
・操作単位: 数億行規模のフルスキャン + GROUP BY / JOIN
・同時接続数: 数人～数十人のアナリスト・BIツール
・応答時間の要件: 秒～分単位でも許容されることが多い
・データ鮮度: 日次・週次のバッチ取込も許容される場合が多い
・インデックス戦略: 列指向ストレージ・パーティション・カラムナインデックスが中心

OLAPを専門に扱うシステムはデータウェアハウス（DWH）と呼ばれます。オンプレでは Oracle Exadata、Teradata、IBM Netezzaなどが代表的でした。

3. 一目でわかる比較表

列指向ストレージがOLAPを速くする理由

OLTPのRDBMSは行単位でデータをストレージに格納します。「顧客ID＝1001の全カラムをまとめて1レコードとして保存する」イメージです。1行の読み書きが速い一方、「全レコードの売上金額カラムだけを集計する」場合は不要なカラムも読み込むため非効率です。

OLAPのDWHが採用する列指向ストレージは、カラムごとにまとめてデータを格納します。「売上金額」カラムだけをスキャンする分析クエリでは、他のカラムを一切読み込まずに済むため、I/Oを大幅に削減できます。

さらに列指向は同じ種類の値が連続するため圧縮率も高く、ストレージコストの削減にも貢献します。Amazon Redshiftがカラムナーストレージ＋圧縮エンコーディングを売りにしているのは、この原理に基づいています。

クラウドでのサービス対応表

1. OLTPに対応するクラウドDBサービス

・Amazon RDS: MySQL / PostgreSQL / Oracle / SQL Server / MariaDBをフルマネージドで提供。オンプレのRDBMSをほぼそのままリフト＆シフトできる。マルチAZ構成で高可用性を確保。
・Amazon Aurora: MySQL / PostgreSQL互換。RDSより最大5倍（MySQL比）の書き込み性能。ストレージは自動拡張（最大128TiB）。
・Azure SQL Database: SQL Serverのフルマネージド版。オンプレSQL Serverからの移行が最も容易。DTU / vCoreの2種類の購入モデルがある。
・Azure Database for PostgreSQL: PostgreSQLのフルマネージドサービス。Flexible Serverが現在の推奨オプション。
・Google Cloud SQL: MySQL / PostgreSQL / SQL Serverに対応するGCPのマネージドRDB。

2. OLAPに対応するクラウドDWHサービス

・Amazon Redshift: AWSのクラウドDWH。列指向ストレージ＋MPP（大規模並列処理）。Redshift Serverlessでコンピュートを使った分だけ課金も可能。S3上のデータをRedshift Spectrumで直接クエリできる。
・Azure Synapse Analytics: AzureのDWH＋データ統合基盤。SQL Pool（旧Azure SQL DW）でRedshift同等のMPP処理。Spark Poolでビッグデータ処理も統合できる。
・BigQuery（Google Cloud）: GCPのサーバーレスDWH。クエリ実行ごとにスキャンしたデータ量で課金。テーブル定義なしでJSONをネイティブに扱える。
・Snowflake: AWS / Azure / GCPのいずれにも対応するマルチクラウドDWH。コンピュートとストレージが独立してスケールするアーキテクチャが特徴。

3. クラウドサービス選定の対応表

料金の仕組みとコスト感覚（2026年6月時点）

1. OLTPサービス（Amazon RDS）の料金構造

Amazon RDSはインスタンスの稼働時間に対して課金されます。db.r6g.largeインスタンス（PostgreSQL、東京リージョン〈ap-northeast-1〉）の場合、オンデマンドで約0.48 USD/時間（2026年6月時点）です。1か月24時間稼働で約345 USDになります。

リザーブドインスタンスを1年前払いで購入すると最大40%前後の割引が適用されます。本番環境で常時稼働するOLTPのDBには、リザーブドインスタンスの活用が基本です。

マルチAZ構成にすると料金がほぼ2倍になりますが、可用性の観点から本番環境では必須と考えてください。シングルAZは開発・検証環境に限定するのが実務上の鉄則です。

2. OLAPサービス（Amazon Redshift）の料金構造

Amazon Redshiftはノードタイプに応じた時間課金です。ra3.xplusノード（東京リージョン）の場合、オンデマンドで約0.95 USD/時間（2026年6月時点）です。

分析クエリが常時走るわけでないなら、**Redshift Serverless**が有力な選択肢です。実際のクエリ実行に消費したRPU（Redshift Processing Units）時間分だけ課金されます（0.45 USD/RPU時間、2026年6月時点）。週数回のレポート集計など、断続的なワークロードではServerlessが大幅にコストを下げられます。

BigQueryはスキャンしたデータ量に応じた課金（1TBあたり5 USD、2026年6月時点）が基本です。パーティション設計とクラスタリングを正しく設定すれば、同じクエリのスキャン量を劇的に減らせます。逆に設計が甘いと想定外の請求になるため注意が必要です。

設計判断の実務Tips

1. OLTPのDBに分析クエリを直接投げない

「開発者がProductionのRDSに直接SELECT * FROM orders GROUP BY…」という状況は、多くのオンプレ現場で見られた光景です。クラウドでも同じことをやると、本番トランザクションがロック待ちで詰まるリスクがあります。

Aurora MySQL / PostgreSQLには**Auroraリードレプリカ**が用意されています。分析クエリ専用のリードレプリカを別途作成し、BI ツールやアドホッククエリはそちらに向けるのが最小コストの対策です。ただしリードレプリカでもヘビーなフルスキャンは本番DBへの間接的な影響（レプリケーション遅延）を起こすことがあります。本格的な分析基盤が必要なら、RedshiftやSynapse Analyticsへのデータ移送ワークフローを検討してください。

2. ETLパイプラインでOLTPとOLAPをつなぐ

実務でよく使われるのはETL（Extract / Transform / Load）パイプラインです。OLTPのRDSからデータを抽出し、S3などのステージング領域を経由して、RedshiftやBigQueryへ取り込む設計です。

AWSであれば以下の組み合わせが一般的です。
・AWS Database Migration Service（DMS）: RDSからS3への継続的なデータレプリケーション
・AWS Glue: S3上のデータを変換してRedshiftへロード
・Amazon EventBridge + Step Functions: パイプライン全体のオーケストレーション

小規模であれば、RDSのスナップショットを定期エクスポートしてS3に置き、Athenaで分析するシンプルな構成でも十分なケースもあります。

3. HTAP（Hybrid Transaction/Analytical Processing）という第3の選択肢

OLTPとOLAPを完全に分離するとデータ鮮度の問題が生じます。「リアルタイムで業務トランザクションを処理しながら、同時に秒単位で集計結果も確認したい」という要件では、従来のOLTP/OLAP分離では対応しきれません。

この問題へのアプローチがHTAPです。
・Amazon Aurora Zero-ETL for Redshift: AuroraのデータをほぼリアルタイムでRedshiftに同期。ETLパイプライン不要で分析基盤に取り込める（2024年GA）
・Azure Synapse Link for Azure SQL Database: SQL Databaseの変更をSynapse Analytics分析ストアへリアルタイム連携
・TiDB / SingleStore: 行指向と列指向ストレージを同一エンジンに統合したHTAP専用DBが選択肢に入るケースもある

ただしHTAPは構成が複雑になりがちです。最初から完璧を目指さず、まずシンプルなOLTP/OLAP分離からはじめ、リアルタイム要件が明確になってからHTAPに移行する段階的アプローチを推奨します。

よくある誤解とトラブル

1. 「RDSとRedshiftはどちらも”データベース”だから同じでいいよね」

これが最も多い誤解です。Amazon RDSはOLTP向けの行指向RDBMSです。RedshiftはOLAP向けの列指向DWHです。RDSにBIツールを大量接続してレポートを生成しようとすると、OLTPのトランザクション性能が劣化します。逆にRedshiftで1件ずつのINSERT/UPDATEを頻発させると、MPP処理の恩恵を受けられず逆に遅くなります。「何が得意か」を理解して使い分けることが前提です。

2. DWHへの移行でスキーマをそのまま持ってきてしまう

オンプレの正規化されたRDBMSスキーマ（3NF）をそのままRedshiftやBigQueryに持ち込むと、集計クエリで大量のJOINが発生して性能が出ません。DWHでは、あえて非正規化したスタースキーマ（ファクトテーブル＋ディメンションテーブル）に設計し直すことが基本です。オンプレ時代にOracleで使っていた高度なインデックス戦略も、列指向DWHではそのまま通用しません。

3. 開発環境でもマルチAZを有効にしてコストが膨らむ

RDSのデフォルト設定でマルチAZが有効になっているケースがあります。開発・検証環境ではシングルAZ＋t3系のburstableインスタンスタイプで十分です。本番環境のみマルチAZ＋r6g系のメモリ最適化インスタンスを使うことで、コストを半分以下に抑えられます。環境ごとに設定を見直すことがクラウドコスト管理の第一歩です。

本記事のまとめ

OLTPとOLAPの違いを整理します。

クラウド移行では、オンプレで「なんでも1台のOracleに任せていた」構成を見直し、ワークロードの特性に合ったサービスを選ぶことが重要です。OLTPはRDS / Aurora、OLAPはRedshift / Synapse / BigQueryに分離する設計を基本とし、リアルタイム性が必要な場合にZero-ETLやHTAPの活用を検討してください。

Linuxサーバー上でのDB構築・チューニングの基礎については、姉妹サイトLinuxMaster.JPでも詳しく解説しています。