注文や会員の情報を記録しているデータベースがあるなら、売上の集計もそこへ SQL を投げれば済みそうに見えます。
それでも多くの構成では、分析のためにデータウェアハウスという別の置き場所を用意し、そこへデータを写してから集計しています。
理由は、データベースへの頼み方が、少ない行を読み書きする OLTP と大量の行を集計する OLAP に分かれていて、得意な作りが逆向きだからです。
この違いが分かると、分析用のサービスが別に用意されている理由と、RDB のまま分析してよい場面の見分け方に説明がつきます。
私は DynamoDB を個人開発で使っていますが、データウェアハウスは運用したことがなく、各社の公式ドキュメントをたどって整理しています。
OLTPとOLAPとは
OLTP は Online Transaction Processing の略です。
支払いの受け付けや在庫の移動、注文の登録のような業務のやり取りを、起きたその場で記録する処理を指します。
1 件のやり取りは全部成功するか全部取り消すかのどちらかで終わる必要があり、途中まで進んだ半端な状態を残してはいけません。
OLAP は Online Analytical Processing の略で、大量のデータに集計や傾向の分析をかけて、判断の材料を作る処理のことです。
Microsoft の OLAP の解説は、OLAP を業務のシステムを乱さずに複雑なクエリを回すための技術と説明しています。
AWS と Microsoft の解説を突き合わせると、両者の違いは次のようになります。
| 観点 | OLTP | OLAP |
|---|---|---|
| 目的 | 業務のやり取りをその場で記録する | 大量のデータを集計して判断の材料にする |
| 1 回に触る範囲 | 少ない行の、ほぼすべての列 | とても多くの行の、一部の列 |
| 読み書き | 書き込みが多い | 読み取りが中心で、書き込みは少ない |
| 応答時間の目安 | ミリ秒 | 数秒〜数分 |
| データ量の目安 | GB 規模 | TB〜PB 規模 |
| データの形 | 正規化した表 | スター・スキーマなど集計向けの形 |
| AWS の代表例 | RDS・Aurora・DynamoDB | Redshift・Athena |
OLTP は少ない行を丸ごと読み書きし、OLAP は大量の行から一部の列だけを読むという差が、この先の話すべての土台になります。
AWS も OLTP と OLAP の比較の中で、Redshift を OLAP のために設計したクラウドのデータウェアハウスと紹介しています。
データベースを「どんな問いに速く答えるか」で分ける見方は、意味の近さで行を引くベクトルデータベースにも当てはまります。
なぜRDBのまま分析しないのか
業務用の RDB で重い集計を回さない理由は、公式ドキュメントを読むと 3 つに分けられます。
行ごとの保存は集計に向かない
一般的な RDB は、1 行分の値をひとまとまりにして、ディスクのブロックへ並べています。
Amazon Redshift の開発者ガイドにある列指向ストレージの説明によると、この行ごとの保存は OLTP に最適です。
OLTP では、1 件か少数のレコードについて、全部の列を読み書きすることが多いからです。
一方で集計は、売上金額の列だけを何百万行ぶん足し合わせるような読み方です。
行ごとに保存されていると、使わない列までブロックごと読み込むことになります。
列指向のストレージは列ごとに値を並べて保存するので、集計に必要な列のブロックだけを読めば済みます。
同じガイドの例では、100 列の表で 5 列だけを使うクエリは、表のデータの約 5% を読むだけで済むとされています。
同じ型の値が並ぶので、列の型に合わせた圧縮が効きやすいのも利点です。
集計が業務の処理を止める
Microsoft の OLTP の解説は、何百万件ものトランザクションをまたぐ集計は、OLTP のシステムにとって資源を大きく食う処理だと書いています。
遅いだけでなく、ほかのトランザクションをブロックして、データベース全体を遅くすることがあるという指摘です。
注文を受け付ける処理と月次の集計が同じデータベースを取り合うと、集計のせいで注文の処理まで詰まることになりかねません。
正規化された表は分析のSQLを難しくする
OLTP の表は、同じ値を何度も持たないように細かく分けて正規化されています。
これは 1 件ずつの書き込みを、整合性を保ったまま速く処理するための工夫です。
ところが分析のときは、ほとんどのクエリが表の結合（JOIN）を重ねて、分けた表を元の形に戻すところから始まります。
同じ解説は、その結果、データベース管理者や開発者の助けがないと、業務の担当者がクエリを書きにくくなると指摘しています。
取引の履歴を無期限にため込むことも、クエリが遅くなる原因になります。
よくある対処として挙げられているのは、業務のデータベースには今期のような直近の期間だけを残し、古い履歴をデータウェアハウスなどへ移す方法です。
なお、Redshift も SQL で問い合わせるリレーショナルデータベースの一種です。
分けているのは RDB かどうかではなく、行と列のどちらで保存し、どんな頼まれ方に合わせて作られているか、という違いにあります。
どこで使われるか
典型的な構成は、アプリが OLTP のデータベースに書き込み、そのデータを分析側へ写してから集計する、という 2 段の形です。
Microsoft の OLAP の解説にある図も、アプリから OLTP、OLTP から OLAP、そこから分析とレポートへ、という流れで描かれています。
AWS でいえば、OLTP 側に来るのは RDS・Aurora・DynamoDB です。
OLAP 側には、Redshift や、S3 に置いたデータへ直接 SQL を投げられる Athena が来ます。
業務の DB から分析側へ写す方法は、代表的なものが 3 つあります。
- Aurora から Redshift へ: zero-ETL 統合で、Aurora に書き込まれたデータをほぼリアルタイムで Redshift に複製する
- DynamoDB から S3 へ: テーブルを S3 へエクスポートし、Athena などで分析する
- RDS からリードレプリカへ: 読み取り専用のコピーを作り、レポートのクエリをそちらへ向ける
Aurora の zero-ETL 統合について、AWS はETL のパイプラインを自分で組んで保守する必要がなくなることを利点に挙げています。
DynamoDB の S3 エクスポートは、読み込みキャパシティを消費せず、テーブルの性能や可用性にも影響しないと公式ドキュメントに書かれています。
業務のシステムからデータを取り出す作業がなぜ失敗しやすく、どう備えるかは、Palantir の資料をもとに FDE のデータ統合を扱った記事で整理しました。
先に知っておく用語
この先の選び分けで出てくる言葉を、短く確かめておきます。
- ETL: Extract（取り出し）・Transform（変換）・Load（読み込み）の頭文字で、複数の元データをまとめて中央のデータウェアハウスに入れる処理
- zero-ETL 統合: その ETL のパイプラインを AWS が用意して管理し、業務の DB から分析側へ自動で複製する仕組み
- データウェアハウス: 複数のシステムから集めたデータを共通の形にそろえ、長い期間保存して分析に使う置き場所
- リードレプリカ: 元の DB の読み取り専用のコピーで、元の DB の更新が非同期で反映される
- スター・スキーマ: 売上のような出来事を記録する中心の表を、商品・店舗・日付といった切り口の表が囲む、集計向けの表の組み方
- HTAP: Hybrid Transactional and Analytical Processing の略で、1 つの基盤で OLTP と OLAP の両方をこなそうとする考え方
いつRDBのまま分析してよいか
ここまで読むと何でも分けたくなりますが、Microsoft の OLTP の解説も、よく計画されたスキーマのような例外はあると書いています。
分けるかどうかは、データの量、集計の重さ、どれだけ新しいデータが要るか、の 3 つで決まります。
私が個人開発している草野球リーグの管理アプリは DynamoDB を使い、打率などの成績はスコアを保存するたびに計算し直して、選手のデータへ書き戻しています。
ランキングはその選手データを読んで並べ替えているだけで、分析用の置き場所は用意していません。
データが小さく、知りたい集計が決まっているなら、このように書き込みのときに集計を済ませておく方法で、OLTP 側に収まります。
状況ごとの選び方を表にすると、次のようになります。
| 状況 | 選ぶもの | 理由 |
|---|---|---|
| データが小さく、集計の種類が決まっている | 業務の DB のまま | 写す仕組みを増やすと、その保守も増える |
| レポートの SQL が本番の DB を圧迫している | RDS のリードレプリカ | 集計を読み取り専用のコピーへ向けられる |
| Aurora のデータをほぼリアルタイムで分析したい | zero-ETL 統合で Redshift へ | 写すパイプラインを自分で組まなくてよい |
| S3 に置いたログなどを、ときどき SQL で調べたい | Athena | サーバーを用意せず、S3 のデータへ直接クエリを投げられる |
| 複数のシステムのデータを集め、長く保存して大きな表を結合する | Redshift | 大きな表を多数結合する複雑なクエリに向けて最適化されている |
| DynamoDB のデータを集計したい | S3 へエクスポートして Athena など | Scan で全件を読むと本番の読み込みキャパシティを使う |
RDS のリードレプリカの説明にも、本番の DB インスタンスの代わりにレプリカでレポートのクエリを動かす使い方が挙がっています。
ただし元の DB の更新は非同期で写るので、レプリカでは少し遅れたデータを読むことになります。
また、レプリカは元と同じエンジンのコピーなので、本番への影響は切り離せても、列指向の読み方に変わるわけではありません。
AWS の Athena の使いどころの説明は、S3 上のデータへのアドホックなクエリには Athena を勧めています。
多数の大きな表を何度も結合する複雑なクエリには、Redshift が向くという整理です。
負荷を逃がすだけならリードレプリカ、読み方ごと変えたいなら Redshift や Athena、と分けて考えると選びやすくなります。
課金と落とし穴
分析側のサービスは、何に対して課金されるかがそれぞれ違うので、構成を決める前に軸だけでも知っておくと安心です。
課金の軸
金額は改定されやすいので、ここでは何に対して払うかだけを挙げます。
- RDS のリードレプリカ: 通常の DB インスタンスと同じ扱いで課金される。同じリージョン内での複製の転送には料金がかからない
- Redshift Serverless: 計算は使った処理能力（RPU）に対して秒単位で課金され、最低は 60 秒ぶん。ストレージは GB 月で別に課金される。無料トライアルがある
- Athena: SQL クエリはスキャンしたデータ量で課金される。テーブルやパーティションを管理する DDL と失敗したクエリは課金されず、途中で取り消したクエリはそれまでにスキャンした分が課金される
- DynamoDB の S3 エクスポート: 全体のエクスポートはテーブルの大きさ、増分のエクスポートは処理したデータ量で課金される。書き出した先の S3 の保存とリクエストは別に課金される。使うにはテーブルのポイントインタイムリカバリ（PITR）を有効にしておく必要がある
Scanで集計すると本番の読み込み枠を食う
DynamoDB の Query と Scan のベストプラクティスによると、Scan は表全体を読んでから、条件に合わない項目を捨てる操作です。
大きな表への Scan は、1 回の操作でプロビジョンドスループットを使い切ることがあります。
そうなると同じ表へのほかのリクエストがスロットリングされる、と注意されています。
分析が目的なら、読み込みキャパシティを消費しない S3 へのエクスポートに切り替えたほうが、本番への影響を避けられます。
列指向でも全部の列を読めば高くつく
Athena の料金ページは、データを Parquet のような列指向の形式に変える例を示しています。
クエリが参照する列だけを読めるので、スキャンするデータ量が減るという説明です。
逆に、CSV のような行ごとの形式のまま置いたり、SELECT * ですべての列を取り出したりすると、必要のない列まで読むことになります。
開いたままの接続も課金される
Redshift Serverless の課金の説明によると、終わらせていないトランザクションがあると、その間も処理能力が使われ続けます。
接続プールが死活確認のために定期的に送る SELECT 1 のような軽いクエリも、課金される利用として扱われます。
予期しない請求を防ぐために、最大 RPU 時間の上限を設定しておくことが勧められています。
写した先の権限は別に設計する
責任共有モデルでいう自分側の仕事として、分析側に写したデータを誰が読めるかの設計も残ります。
Microsoft の OLAP の解説は、利用者を業務の DB に直接つなぐ方法には、権限の管理が難しくなる欠点があると書いていました。
同じ指標でも、人によって違う数字が出やすいとも指摘しています。
代わりに勧められているのは、データウェアハウスの上に分析用のモデルを置き、行単位のセキュリティもそこでかける形です。
他クラウドでは
Google Cloud では、Cloud SQL や Spanner が OLTP 側、BigQuery が OLAP 側にあたります。
BigQuery の概要によると、BigQuery はフルマネージドでサーバーレスのデータウェアハウスで、分析向けに最適化した列指向のストレージを使います。
計算と保存の層が分かれていて、それぞれが相手の性能に影響せずに資源を割り当てられる作りです。
課金はオンデマンドと、処理能力を予約する容量ベースの 2 通りから選べます。
Azure では、Azure SQL Database や Azure Database for PostgreSQL・MySQL、Azure Cosmos DB が OLTP 側です。
OLAP 側の中心は Microsoft Fabric になります。
Microsoft の OLAP の解説は、SQL Server や Azure SQL Database の列ストアインデックスにも触れています。
これを使うと、1 つの基盤で OLTP と OLAP をこなす HTAP の形もとれる、という説明でした。
ここまでに出てきたサービスを 3 社で並べると、次のとおりです。
| 区分 | AWS | Google Cloud | Azure |
|---|---|---|---|
| OLTP（業務の読み書き） | RDS・Aurora・DynamoDB | Cloud SQL・Spanner | Azure SQL Database・Azure Cosmos DB |
| OLAP（分析） | Redshift・Athena | BigQuery | Microsoft Fabric |
参考
本文のリンクで紹介した公式ドキュメントは、いずれも 2026-10-02 に参照しました。
料金や仕様は改定されることがあるので、構成を決める前にはリンク先の最新の記述を確かめてください。
最後に
業務のデータベースは少ない行を速く確実に読み書きするための作りで、大量の行の一部の列を集計する分析とは、得意なことが逆向きです。
分析を切り出すかどうかは、データの量と集計の重さ、どれだけ新しいデータが要るかで決まり、小さいうちは業務の DB のままでも困りません。
資格試験では、AWS の SAA-C03 の試験ガイドのタスク 3.3 が、読み込み中心か書き込み中心かというアクセスパターンとリードレプリカを挙げています。
同じガイドのタスク 3.5 には、Athena と、CSV から Parquet への形式の変換が含まれています。
Azure の DP-900 の学習ガイドでも、トランザクションのワークロードと分析のワークロードの特徴が出題範囲の一つです。
集計を書く前に、どの行のどの列をどれだけ読むのかを数えてみると、置き場所の答えはおのずと絞られてきます。
以上です。
コメントを残す