【データベースの使い分けの役割（設計のベストプラクティス）】
目次
🔍 1. 結論
💎 一言でいうと 全てを一つのリレーショナルデータベース（RDB）で処理するのではなく、データの性質やアクセスパターンに応じて 「適材適所の専用データベース（Purpose-built database）」 を使い分ける設計原理です。
- 複雑なトランザクションやJOIN → RDS / Aurora
- マイクロ秒の遅延、キーバリュー型 → DynamoDB
- 大量データの複雑な分析（OLAP） → Redshift
- 高速なキャッシュ、セッションストア → ElastiCache
📈 2. SAAで出やすいポイント
- アンチ・ワンサイズフィッツオール: 従来は「全部MySQLで」だったが、AWSでは「ログ保存はS3」「セッションはElastiCache」「メインデータはAurora」と分割するのがベストプラクティス。
- NoSQLの活用: スキーマレスで、予測不可能なトラフィックに対してミリ秒単位の応答が必要な場合は DynamoDB を選ぶ。
- グラフと時系列: ソーシャルネットワークのつながり検索には Neptune、IoTデータの時系列記録には Timestream など、特化型DBのユースケースが問われる。
🗝 3. キーワードでの判断
| 問題文のキーワード | 疑うDBサービス |
|---|---|
| 🐘 「複雑なJOIN」「ACIDトランザクション」 | Amazon RDS, Aurora |
| ⚡ 「キーバリュー」「ミリ秒の応答」「スキーマレス」 | Amazon DynamoDB |
| 📊 「データウェアハウス」「ペタバイト級の分析」「OLAP」 | Amazon Redshift |
| 🚀 「マイクロ秒のキャッシュ」「セッション管理」 | Amazon ElastiCache |
| 🕸️ 「ソーシャルネットワーク」「レコメンデーション（つながり）」 | Amazon Neptune |
⚠️ 4. ひっかけポイント
🚫 よくある誤答パターン – 「RDBで数十ペタバイトの分析クエリを実行する」 → RDB（RDS）はOLTP（トランザクション）向け。分析（OLAP）は Redshift の仕事。 – 「DynamoDBで複雑なJOINクエリを書く」 → NoSQLであるDynamoDBはJOINが苦手。JOINが必要なら RDS。
💡 5. 覚え方
🧠 暗記ショートカット – 「DBの適材適所」 – RDS/Aurora = 几帳面な経理担当（きっちり表で管理、関連付けが得意） – DynamoDB = 超速の倉庫番（箱（キー）を渡せば中身を一瞬で出すが、中身の複雑な検索はしない） – Redshift = データ分析官（過去の膨大なデータを一気に集計する） – ElastiCache = 机の上のメモ帳（超高速だが、消えてもいい一時データ）
📚 6. 関連サービス
| アイコン | サービス名 | ユースケース |
|---|---|---|
| 🐘 | RDS / Aurora | 従来型のシステム、ECサイトのカート（厳密なトランザクション） |
| 📦 | DynamoDB | ゲームのスコアボード、IoTデータの受け皿、セッション情報 |
| 📊 | Redshift | BIツールと連携した売上分析、データウェアハウス |
| ⚡ | ElastiCache | DBのクエリ結果のキャッシュ、高速セッション管理 |
🗒️ 7. Obsidian管理メモ
- 見返すタイミング: DBサービスの比較問題で迷ったとき
- 関連ノート候補:
AWS_SAA_Database_Comparison
8. HTMLファイル名:
AWS_設計原理_データベース使い分け.html
