データベース選択の論点（OLTP／OLAP／整合性モデル）
SAAで問われるワークロード分類、ACIDと整合性モデル、RDBとNoSQL、データモデル別の位置づけを、誤答しやすい比較軸とシナリオで厚く整理します。
このページの狙い
データベース問題はサービス名当てより、ワークロードに合うかの判定が成否を分けます。ここでは教材で扱う「オペレーション向け／分析向け」「集中／分散」「整合性の強さ」「データモデル」を、紛らわしい選択肢・誤答パターンとセットで固定します。数値や料金は変わりうるため、役割とトレードオフを主に覚えてください。
公式ドキュメント（入口）
データベースとストレージ（混同の根）
ストレージはデータを保持する装置・サービスです。データベースは、検索・更新・同時実行制御・障害時の一貫性など、データ操作の語義まで含んだシステムです。
試験では次のような言い換え誘導が出ます。
- 「オブジェクトストアに載せたので、トランザクション境界が自動で付く」→ 誤り。S3 は高耐久のオブジェクトストアであり、RDB のようなトランザクション語義は別物です。
- 「データレイクに流し込んだので、会計の仕訳もそこで完結できる」→ 用途次第。分析・学習用のコピーと、**正規の台帳（OLTP）**は分離するのが一般的です。
CRUD とトランザクション
追加・参照・更新・削除（CRUD）は、業務で信頼して扱うにはトランザクション境界（まとめて成功／まとめて取り消し）とセットで語られます。RDB（RDS／Aurora）で頻出なのは ACID です。
| 性質 | 意味（試験向け一言） | 障害・同時実行で効く場面 |
|---|---|---|
| 原子性（A） | 途中状態を晒さず、全部成功か全部未適用か | 複数行更新の途中で落ちたら全体を戻す |
| 一貫性（C） | 制約を満たす状態だけを辿る | 外部キーや残高非負などの不変条件 |
| 分離性（I） | 同時実行でも論理的に順番が付く | 同じ行を二人が触るときの見え方 |
| 耐久性（D） | コミット後は障害でも失わない | DB プロセスクラッシュや AZ 障害 |
COMMIT とロールバック（ストーリーで押さえる）
書き込み処理の途中でシステムが落ちた場合、COMMIT 前であれば変更はロールバックされ、COMMIT 後であれば結果は耐久性のもとで保護される、という説明が教材に現れます。試験では「クラッシュ直後に読むと必ず途中までの値が見える」など半端な状態が覗くと読ませる文が誤答になりやすいです。
強い整合性と結果整合性（読み取りの見え方）
**強い整合性（strongly consistent read）**は、書き込み結果が読み取りに反映されたことを確認してから返すイメージです。**結果整合性（eventually consistent）**は、しばらく古い値が返る余地があります。
同時更新のストーリーでは、教材はしばしば次の二つを対比します。
- 結果整合性: 更新が完了するまで、別ユーザーには古い値が見えることがある（可用性・レイテンシとのトレードオフ）。
- 強い整合性: 更新が完了するまで、別ユーザーは新しい値を読めない／待つイメージが強い（一貫した見え方を優先）。
DynamoDB では、デフォルトの読み取りと強い整合性読み取りのオプションの組み合わせが試験の定番です。グローバルテーブルなど複製まわりでは、単一リージョンの話と短絡的に同一視しないことが問われます（詳細は DynamoDB の整合性）。
OLTP・OLAP・データレイク（三層の腹落ち）
| 区分 | 主目的 | 典型パターン | AWS での代表 |
|---|---|---|---|
| OLTP | 業務操作を低遅延・高頻度で正確に | 注文／在庫／会計の更新 | RDS、Aurora、DynamoDB |
| OLAP／DWH | 集計・レポート・分析 | 星型スキーマ、大規模スキャン、列指向 | Amazon Redshift |
| データレイク | 多様な形式を低コストで蓄積し後から解釈 | 生ログ・メディア・ランディング | Amazon S3 を中心とした構成 |
シナリオ例（正しい分離）: 注文トランザクションは Aurora、日次売上の多维分析は Redshift（または Redshift＋Spectrum）、クリックストリームの生データは S3 に蓄積し、Glue／Athena で探索、のように役割を分ける選択が王道です。
誤答パターン（一覧で頭に入れる）
- 「ユーザー購入の主ストアは Redshift」→ OLTP 誤用。
- 「在庫の真実は S3 の CSV のみ」→ 同時更新と整合性の主戦場がズレる。
- 「DynamoDB だから RDB の複雑 JOIN がそのまま速い」→ アクセスパターン設計が前提。
- 「Aurora と Redshift はどちらか一方だけあれば足りる」→ 分析と業務を無理に一つに詰めない。
- 「データレイク＝データウェアハウス」→ レイクはスキーマオンリード寄りの柔軟さ、DWH は分析用に整形されたデータのイメージが強い。
RDB と NoSQL（SQL の有無だけで決めない）
| 観点 | RDB（RDS／Aurora） | NoSQL（例: DynamoDB） |
|---|---|---|
| スキーマ | 表＋リレーションが前提 | アクセスパターン駆動の設計が重要 |
| クエリ | 複雑な JOIN・集計に強い | パーティションキー設計が成否を分ける |
| スケール | 垂直スケール＋読み取り分散が基本軸 | 水平分散が前提になりやすい |
| トランザクション | 広い範囲で語られる | DynamoDB はトランザクション API があるが、設計思想は RDB と同一ではない |
NoSQL は「非構造化だから」だけではなく、キーに沿ったアクセスが支配的で極めて大規模なケースで選ばれる、という出題が多いです。
NoSQL の「型」ごとの腹落ち（試験の当てはめ）
教材では、キーの持ち方で NoSQL を分類する説明が出ます。サービス名暗記より「どんな形のデータか」で寄せます。
| データモデル | イメージ | AWS での代表例（教材レベル） |
|---|---|---|
| キーバリュー | キーに値がぶら下がる単純構造 | DynamoDB（ワイドカラム的側面も持つ説明がなされることがある） |
| ワイドカラム | 行ごとに可変の多列を大規模に | Apache Cassandra 系の話 → Keyspaces（別ページ） |
| ドキュメント | JSON／BSON などドキュメント単位 | DocumentDB（Mongo 互換） |
| グラフ | ノードとエッジの関係横断 | Neptune |
詳細は 特殊用途向けマネージドDB を参照してください。
インメモリ・検索・グラフ（位置づけ）
| 種別 | 役割 | AWS の代表例 |
|---|---|---|
| インメモリキャッシュ | ディスクより速い参照先（揮発性に注意） | ElastiCache（Redis と Memcached の比較） |
| 検索・ログ分析 | 全文検索や近リアルタイム検索 | Amazon OpenSearch Service |
| グラフ | 関係の横断・近傍探索 | Amazon Neptune |
まとめ：選定チェックリスト（試験本番用）
- 主目的は OLTP か OLAP か（在庫・決済・予約なら前者寄り）。
- RPO/RTO と整合性（最新必読か、追いつきでよいか）。
- クエリはキー単位か、JOIN 中心か。
- データ寿命（キャッシュでよいか、永続の正が要るか）。
- 運用境界（マネージドに寄せるか、スキーマ自由度を取るか）。
関連トピック（サイト内）
- リレーショナルと DynamoDB の俯瞰: RDS, Aurora, DynamoDB
- DynamoDB のキー・キャパシティ・インデックス: DynamoDB のキー設計とキャパシティ
- Redshift の位置づけ: Redshift と OLAP 設計（SAA）
- キャッシュ全般: ElastiCache, DAX
重要ポイント
- ▸OLTPは一貫した短いトランザクション、OLAP／DWHは集計・分析向け。データレイクは柔軟な蓄積と後処理に強いがOLTP代替ではない
- ▸ACIDは信頼できるトランザクションの性質。COMMIT前の障害はロールバック、COMMIT後は耐久性で保護されるイメージを問われる
- ▸強い整合性と結果整合性は読み取りの見え方の違い。DynamoDBはデフォルトとオプションの組み合わせが試験の定番
- ▸NoSQLは種類（KVS・ワイドカラム・ドキュメント・グラフ）ごとに得意不得意があり、SQLの有無だけで選ばない
- ▸RedshiftをOLTP主DBにする、S3だけで銀行の勘定系を完結させる等は典型的な誤答パターン
このトピックの学習を完了しますか？
完了状態はいつでも切り替えられます
同じサービスの関連トピック
RDS / Aurora / ElastiCache に関連するトピックを続けて確認できます。