特殊用途向けマネージドDB（DocumentDB／Neptune／Keyspaces ほか）
MongoDB互換、グラフ、Cassandra互換、時系列、台帳型ストアの用途・誤答・RDSやDynamoDBとの距離をサービスごとに厚く整理します。
学習順Step 52 / 77サービスDB試験ドメインパフォーマンス
このページの狙い
SAA では RDS／Aurora／DynamoDB／Redshift が主役になりやすい一方、要件文に Mongo／Cassandra／グラフ／時系列／台帳 のキーワードが埋め込まれたとき、特殊用途向けマネージド DB が正解になることがあります。ここでは サービスごとに「何が得意で、何を誤選しやすいか」 を厚くします。
公式ドキュメント（入口）
使い分け早見（キーワード → サービス）
| キーワード | 第一候補 | よくある誤答 |
|---|---|---|
| JSON ドキュメント／Mongo 互換 | DocumentDB | DynamoDB を「JSON だから Mongo の完全代替」と同一視 |
| ノードとエッジ、グラフ横断、経路 | Neptune | RDS で多対多を自己 JOIN だらけにして凌ぐ |
| Cassandra／CQL／ワイドカラム | Keyspaces | DynamoDB と「分散 NoSQL」という語だけで混同 |
| 時系列、メトリクス、IoTセンサー | Timestream | RDS に時系列を無制限に溜め、インデックス地獄にする |
| 改ざん検知可能な完全な変更履歴、監査台帳 | QLDB | 分散合意が前提のパブリックブロックチェーンと同一視 |
Amazon DocumentDB
MongoDB 互換 API を提供するマネージドのドキュメントデータベースです。
向きやすい要件
- 既存の MongoDB ドライバ・ツール・クエリ を活かして AWS へ移したい。
- 柔軟なドキュメントスキーマ（カタログ、CMS、ユーザープロファイル）で、RDB の厳密スキーマが重い。
誤答の型
- 「JSON を保存するなら必ず DocumentDB」→ 誤り。DynamoDB や S3＋Athena など別解があり得る。
- 「Mongo 互換だから DynamoDB の GSIs と同じ設計で無双できる」→ API とデータモデルが別物。
Amazon Neptune
プロパティグラフと RDF の両系統を扱えるマネージド グラフ DB です。
向きやすい要件
- ソーシャルグラフ（フォロー、ブロック、共通の友達）。
- 推奨（類似ユーザー、関連商品）。
- 経路探索（配送網、ネットワークトポロジ）。
- 不正検知（取引とアカウントのリンク分析）。
誤答の型
- 「Neptune だから OLTP の勘定系がすべて楽になる」→ 用途の主役は関係の横断。日次の総勘定元帳の集計だけなら Redshift 寄りの話になることもあります。
Amazon Keyspaces（for Apache Cassandra）
Apache Cassandra と互換の CQL を使うマネージドサービスです。
向きやすい要件
- すでに Cassandra ベースのアプリ を持ち込みたい。
- 高スループットと マルチ AZ の記述が要件に含まれる。
DynamoDB との距離
- どちらも分散系ですが、クエリ言語・ドライバ・運用モデルが異なります。「名前に key が付くから同じ」は誤答になりやすいです。
Amazon Timestream
時系列データに特化したサービスです。
特徴として試験に出やすい説明
- 直近データはメモリ寄りの高速層、古いデータは 低コストストレージへ移行する二層構造のイメージ。
- IoT や DevOps メトリクスの 高カーディナリティな書き込み。
誤答の型
- 「時系列だから常に Timestream」→ 誤り。DynamoDB＋TTL、Kinesis＋S3、OpenSearch など別解があり得ます。
Amazon QLDB
イミュータブル（追記のみ）なジャーナルにトランザクションを記録し、暗号学的検証で改ざん検知に耐える台帳型ストアです。
向きやすい要件
- 監査証跡が法的・業務的に厳しい（誰がいつ何を変えたかを完全に説明したい）。
- 中央管理者が信頼できる前提で、分散合意までは要らない。
ブロックチェーンとの違い（試験の分岐）
- 複数組織が合意形成なしには進めないワークフローなら、Managed Blockchain など別カテゴリの話に寄ることがあります。
- QLDB は 中央台帳として 改ざん検知可能なログを提供する、という位置づけです。
まとめ：選定のための追加チェック
- 互換 API の有無（Mongo／Cassandra／Gremlin／SPARQL 等）が要件に明示されているか。
- データの主目的が「関係の横断」「時系列」「台帳」か。
- OLTP の主記録として無理に載せていないか（多くは補助的ストア）。
関連トピック
重要ポイント
- ▸DocumentDBはMongoDB互換APIのドキュメントDB。CMSやプロファイル等、既存Mongo資産の移行文脈で選ばれやすい
- ▸NeptuneはグラフDB。RDBの多段JOINが苦しい関係横断・経路・不正検知で有利が語られる
- ▸KeyspacesはCassandra互換（CQL）。高スループットとマルチAZの記述が試験の手がかり
- ▸Timestreamは時系列特化。メモリ層と低コスト層の二段が特徴として出る
- ▸QLDBは改ざん検知可能なジャーナル型台帳。分散合意が要るブロックチェーンと短絡的に同一視しない
このトピックの学習を完了しますか？
完了状態はいつでも切り替えられます
この試験ドメイン内で次の学習に進む
同じサービスの関連トピック
RDS / Aurora / ElastiCache に関連するトピックを続けて確認できます。