導入
「とりあえず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（複数データベースの併用）」も設計として自然な選択です。
読んでみよう
「なぜRDSではなくDynamoDBなのか」を機能の丸暗記でなく、**アクセスパターン（JOINが要るか、主キー一発で引けるか）**から説明できるようにしておくことが重要です。次のレッスンからは、まずリレーショナル側の代表であるAuroraのスケール手法を見ていきます。