導入
「とりあえずRDS」で済んでいた小規模システムと違い、SAPでは扱うデータの形・アクセスパターンに応じて複数のデータベースを使い分ける発想（Purpose-built Database、目的別データベース）が問われます。
説明
AWSは「1つの万能データベース」ではなく、データの性質ごとに最適化された複数のマネージドデータベースを提供しています。
| データベース | データの形 | 得意なアクセスパターン |
|---|---|---|
| RDS / Aurora | リレーショナル（表・JOIN） | 複雑なクエリ、強いトランザクション整合性 |
| DynamoDB | キーバリュー / ドキュメント | 主キーでの超高速な読み書き、予測可能なレイテンシー |
| ElastiCache | インメモリのキーバリュー | ミリ秒未満の読み取り、セッション/キャッシュ |
| Amazon Neptune | グラフ | 関係性の探索（友人の友人、レコメンド） |
| Amazon DocumentDB | ドキュメント（MongoDB互換） | 柔軟なスキーマのJSONドキュメント管理 |
| Amazon Timestream | 時系列 | IoTセンサーやメトリクスの時系列データ蓄積・分析 |
flowchart TD
Q["どんなデータで、<br/>どうアクセスされるか？"] --> R["表とJOINで<br/>複雑な問い合わせ"]
Q --> D["主キーで<br/>高速な読み書き"]
Q --> C["1ミリ秒未満の<br/>キャッシュ"]
Q --> N["「つながり」を<br/>たどる問い合わせ"]
Q --> T["時刻順に増え続ける<br/>センサーデータ"]
R --> RDS["RDS / Aurora"]
D --> DDB["DynamoDB"]
C --> EC["ElastiCache"]
N --> NEP["Neptune"]
T --> TS["Timestream"]
SAPの設問では、「注文とその明細をJOINして集計したい」ならリレーショナル、「ユーザーIDだけで爆速に1件取得したい」ならDynamoDB、というように問い合わせの形そのものからデータベースを逆引きさせる出題が多く見られます。1つのシステムの中で複数のデータベースを使い分ける「Polyglot Persistence（複数データベースの併用）」も設計として自然な選択です。
具体例
1つの配車アプリの中で、機能ごとに「問い合わせの形」が違うため、複数のDBが役割分担します。
| アプリの機能 | 問い合わせの形 | 選ぶDB |
|---|---|---|
| 乗車・料金・請求の記録 | 複数テーブルをJOINし整合性が要る | RDS / Aurora |
| ドライバーの現在地を主キーで即更新・取得 | キー一発の超高速読み書き | DynamoDB |
| 進行中のセッション・待ち行列 | ミリ秒未満のインメモリ | ElastiCache |
| 「近くで評価の高いドライバー」の関係探索 | つながりをたどる | Neptune |
| 車載センサーの走行データ蓄積 | 時刻順に増え続ける | Timestream |
「万能な1つのDB」に全部押し込むと、どこかで無理が出ます。アクセスパターンごとに得意なDBへ振り分ける（Polyglot Persistence）のが自然な設計。SAPは「注文明細をJOIN集計」ならリレーショナル、「ユーザーIDで爆速取得」ならDynamoDB、と問い合わせの形から逆引きさせます。
読んでみよう
「なぜRDSではなくDynamoDBなのか」を機能の丸暗記でなく、アクセスパターン（JOINが要るか、主キー一発で引けるか）から説明できるようにしておくことが重要です。次のレッスンからは、まずリレーショナル側の代表であるAuroraのスケール手法を見ていきます。