Purpose-built Databaseの選択

ゴール

次のような要件から、中心となるデータストア候補を判断できるようにします。

リレーショナル
→ Amazon RDS / Amazon Aurora

キーバリュー
→ Amazon DynamoDB

MongoDB互換のドキュメント
→ Amazon DocumentDB

グラフ
→ Amazon Neptune

Cassandra互換のワイドカラム
→ Amazon Keyspaces

時系列
→ Amazon Timestream

インメモリ
→ Amazon ElastiCache

全文検索 / 関連度検索
→ Amazon OpenSearch Service

ただし、データ形式だけでは最終決定しません。

同じJSONデータでも、

主キー中心に取得
→ DynamoDBが有力

MongoDB互換APIで
ドキュメント内部を柔軟に検索
→ DocumentDBが有力

全文検索や関連度ランキング
→ OpenSearch Serviceが有力

のようにアクセスパターンで候補が変わります。

1. 最初にデータアクセスパターンを見る

データアクセスパターン（Data Access Pattern）とは、アプリケーションがデータをどのように取得・更新・検索するかという利用方法です。

データベースを選ぶときは、保存形式だけでなく「アプリケーションがどうデータへアクセスするか」を確認します。

例えば、顧客データがJSON形式だからといって、それだけでDocumentDBを選ぶことはできません。

顧客データ（JSON）
      │
      ├─ customerIdで高速取得
      │        ↓
      │    DynamoDB候補
      │
      ├─ 属性の組み合わせで
      │  ドキュメント検索
      │        ↓
      │    DocumentDB候補
      │
      └─ 自然文 / キーワードで
         関連度検索
               ↓
         OpenSearch Service候補

判断するときは、最低でも次を確認します。

ここで重要なのは、

ACIDトランザクションが必要
=
必ずリレーショナル

ではないことです。

Amazon DynamoDBは複数アイテムに対するACIDトランザクションをサポートし、Amazon DocumentDBも複数ドキュメントなどにまたがるトランザクションをサポートします。

したがって、トランザクションの有無だけでリレーショナルと非リレーショナルを分けません。

2. リレーショナルならAmazon RDS / Amazon Auroraを評価する

次のような要件では、まずリレーショナルデータベースを評価します。

表 / 行 / 列
+
SQL
+
複数テーブルの結合
+
リレーショナルなデータモデル
+
トランザクション

AWSでは代表的な候補が、

Amazon RDS
Amazon Aurora

です。

3. Amazon RDSは必要なデータベースエンジンが決定条件になる

Amazon RDSはフルマネージドのリレーショナルデータベースサービスです。

現在のAmazon RDSでは、

PostgreSQL
MySQL
MariaDB
Microsoft SQL Server
Oracle
Db2

などのデータベースエンジンを利用できます。

例えば、

既存業務アプリケーション
↓
Microsoft SQL Server固有機能を利用
↓
SQL Server互換性を維持したい
↓
Amazon RDS for SQL Server

というように、既存エンジンとの互換性そのものが決定条件になる場合があります。

つまり、

リレーショナルだからRDS

だけではなく、

必要なデータベースエンジン
+
アプリケーション互換性

まで確認します。

4. Amazon AuroraはMySQL / PostgreSQL互換のリレーショナル候補

Amazon Auroraは、MySQLおよびPostgreSQLと互換性を持つフルマネージドのリレーショナルデータベースです。

Auroraでは、データベースエンジンと分散されたストレージサブシステムを組み合わせたアーキテクチャを使用します。

例えば、

リレーショナルモデル
+
SQL / 結合
+
MySQL互換性
+
Auroraアーキテクチャを利用したい

なら、

Amazon Aurora MySQL-Compatible Edition

を評価します。

同様にPostgreSQL互換要件ならAurora PostgreSQLを評価できます。

Amazon RDSとの最初の切り分けは、

Oracle / SQL Server / Db2 / MariaDB等
特定エンジンが必要
        ↓
Amazon RDSを評価

MySQL / PostgreSQL互換
+
Aurora固有のアーキテクチャを利用したい
        ↓
Amazon Auroraを評価

と考えると整理しやすくなります。

可用性構成、レプリカ、フェイルオーバーなどは、データベースの種類を決めた後に別途設計します。

5. Amazon DynamoDBはキー中心のアクセスで考える

Amazon DynamoDBは、サーバーレスのNoSQLデータベースです。

大規模なワークロードでも一貫した1桁ミリ秒性能を提供するよう設計されています。

代表的な判断は、

アクセスパターンを事前に把握
+
パーティションキー / ソートキーで取得
+
結合不要
+
大規模な読み書き
+
低レイテンシー
        ↓
Amazon DynamoDB

です。

例えば、

ユーザーID
↓
ショッピングカート取得

セッションID
↓
セッション取得

デバイスID + タイムスタンプ
↓
対象範囲取得

のように、キーを中心としてアクセス方法を設計できるワークロードと相性がよくなります。

DynamoDBでは、GetItemなどで主キーを指定してアイテムを取得します。

一方、

多数のテーブルを自由に結合
+
実行時に予測していなかった検索条件を
大量に組み合わせる

というリレーショナルなクエリモデルを、そのまま持ち込むサービスではありません。

6. DynamoDBは「NoSQLだから整合性が弱い」と決めつけない

DynamoDBはデフォルトで結果整合性のある読み取りを使用しますが、テーブルとローカルセカンダリインデックスでは強い整合性のある読み取りも選択できます。

一方、グローバルセカンダリインデックスでは強い整合性のある読み取りを利用できません。

さらにDynamoDBはACIDトランザクションもサポートします。

したがって、

NoSQL
↓
トランザクション不可

という判断は誤りです。

重要なのは、

アクセスパターン
+
データモデル
+
クエリモデル

です。

7. Amazon DocumentDBはドキュメント + MongoDB互換性で判断する

Amazon DocumentDBはMongoDB互換のフルマネージドドキュメントデータベースです。

JSONライクなドキュメントを保存し、その内部のフィールドに対して柔軟なクエリを行うワークロードが代表的な候補です。

判断例：

既存MongoDBアプリケーション
+
MongoDBドライバー / API
+
JSONライクなドキュメント
+
ドキュメントのフィールド検索
        ↓
Amazon DocumentDB

ここでは、

JSON
=
DocumentDB

ではありません。

例えばJSON形式でも、

ユーザーIDによる既知のキー検索が中心
        ↓
DynamoDB候補

ドキュメント内部の複数フィールドを
MongoDB互換APIで検索
        ↓
DocumentDB候補

全文検索 / 関連度検索
        ↓
OpenSearch Service候補

となります。

また、Amazon DocumentDBはMongoDB互換ですが、MongoDBそのものと完全に同一ではありません。

既存MongoDBから移行する場合は、利用しているコマンド、演算子、インデックス、クエリパターンなどの互換性を確認します。

8. Amazon Neptuneは関係探索で判断する

Amazon Neptuneは、関連性の高いデータセットを扱うためのフルマネージドグラフデータベースです。

数十億規模の関係を保存し、グラフをたどるクエリ向けに最適化されています。

代表例は、

不正検知
レコメンデーション
ナレッジグラフ
ソーシャルネットワーク
ネットワーク上の関係

などです。

例えば不正検知で、

口座
  │
  ├─ 端末
  │    │
  │    └─ IPアドレス
  │
  └─ 取引
       │
       └─ 別の口座

という関係を、

この口座と3ホップ以内で
関連している口座は何か

のように探索するなら、単純な主キー検索ではなく、

関係
+
関係をたどる探索

が主要アクセスパターンになります。

この場合、Amazon Neptuneを評価します。

Neptuneはプロパティグラフ向けにGremlinとopenCypher、RDF向けにSPARQLをサポートします。

9. Amazon KeyspacesはCassandra / ワイドカラムが決定条件

Amazon KeyspacesはApache Cassandra互換のマネージドデータベースサービスです。

サーバーレスで、サーバーのプロビジョニングやパッチ適用を行わずにCassandra互換ワークロードを実行できます。

代表的な判断は、

既存Cassandraワークロード
+
ワイドカラムのデータモデル
+
CQL
+
高い読み書きスループット
+
低レイテンシー
        ↓
Amazon Keyspaces

です。

既存CassandraアプリケーションをAWSへ移行するとき、

既存CQL
既存Cassandraドライバー
既存データモデル

を活用したいことが強い決定条件になります。

単に、

NoSQLだからKeyspaces

と選ぶのではありません。

DynamoDBとの違いも、

DynamoDB
→ AWS独自API / キー中心のアクセスパターン

Keyspaces
→ Cassandra互換性 / CQL / ワイドカラム

という互換性とアクセス方法から切り分けます。

10. Amazon Timestreamは時系列アクセスで判断する

時系列データでは、

タイムスタンプ
+
メトリクス / 測定値
+
時間範囲
+
時間窓集計
+
傾向

がアクセスパターンの中心になります。

Amazon Timestream for LiveAnalyticsは、時系列データ向けに設計されたマネージド時系列データベースで、SQLと時系列分析関数を利用できます。

代表例：

IoTセンサーデータ
アプリケーションメトリクス
産業機器のテレメトリ
資産追跡

です。

つまり、

デバイスID
+
タイムスタンプ
+
測定値
        ↓
過去1時間の平均
過去24時間の最大値
時間変化
傾向

のようなアクセスで時系列データベースを評価します。

ただし、

created_at列がある

だけで時系列データベースを選ぶわけではありません。

業務上の主要クエリが、

顧客IDで注文取得
注文IDで更新
複数テーブルを結合

なら、タイムスタンプ列が含まれていてもリレーショナルやキーバリューなど別のデータモデルが中心になる可能性があります。

11. Timestream for LiveAnalyticsの新規利用可否に注意する

2025年6月20日以降、Amazon Timestream for LiveAnalyticsは新規顧客からの利用開始を受け付けていません。

既に利用している支払いアカウントでは継続して利用できます。

AWSは新規顧客に対して、類似機能の候補としてAmazon Timestream for InfluxDBを評価するよう案内しています。

したがって、2026年時点の新規設計では、

時系列
↓
無条件に
Timestream for LiveAnalytics

とは判断しません。

時系列要件
↓
利用中のAWSアカウントで
LiveAnalyticsを利用可能か
↓
利用不可なら
現在提供されている代替候補を評価

とします。

12. Amazon ElastiCacheは超低レイテンシーのインメモリデータストアとして評価する

Amazon ElastiCacheはValkey、Redis OSS、Memcachedを利用できるマネージドインメモリデータストアです。

判断の中心は、

インメモリのデータ構造
+
非常に低いレイテンシー
+
Valkey / Redis OSS / Memcachedとの互換性

が必要かどうかです。

例えば、

Key / Value
Set
Sorted Set
Hash

などのインメモリデータ構造を利用し、

マイクロ秒級の読み取り

を必要とするワークロードではAmazon ElastiCacheを評価できます。

DynamoDBとの切り分けは、

DynamoDB
→ サーバーレスNoSQL
→ キー中心の大規模アクセス
→ 1桁ミリ秒級

ElastiCache
→ インメモリデータ構造
→ マイクロ秒級のアクセス
→ Valkey / Redis OSS / Memcached互換

のように、アクセスモデルとレイテンシー要件から考えます。

Amazon ElastiCacheをキャッシュとして利用する場合のTTL、キャッシュヒット、無効化方式などは、データストアの種類を選んだ後に別途設計します。

13. Amazon OpenSearch Serviceは検索アクセスパターンで判断する

Amazon OpenSearch Serviceは、OpenSearchクラスターのデプロイ、運用、スケーリングをAWSが管理するサービスです。

OpenSearchは検索および分析エンジンで、

全文検索
ログ分析
アプリケーション監視
クリックストリーム分析

などに使用できます。

特に、

キーワード
+
全文検索
+
関連度ランキング
+
フィルタ / 集計

が中心なら、通常の主キー検索とはアクセスパターンが異なります。

例えば、

商品データ
↓
「ワイヤレス メカニカル キーボード」
のような文字列で検索
↓
関連度順に結果表示

なら、

主キー検索

ではなく、

検索インデックス

が必要になります。

この場合、Amazon OpenSearch Serviceが候補になります。

Amazon OpenSearch Serviceでは現在、キーワード検索だけでなくベクトル検索も利用できます。

ただし、OpenSearch Serviceはトランザクションシステムの正規データベースと、検索用インデックスを同じものとして考えないことが重要です。

14. 主要サービスをデータアクセスパターンで比較する

15. 「データ形式」ではなく「操作」を見る

最も混同しやすいのが、

保存されているデータの見た目

だけでサービスを決めることです。

例えばJSONでも、

JSON
│
├─ ID指定で取得
│    ↓
│  DynamoDB候補
│
├─ MongoDB互換APIで
│  フィールド検索
│    ↓
│  DocumentDB候補
│
└─ テキストを全文検索
     ↓
   OpenSearch Service候補

となります。

時刻を含むデータも同様です。

タイムスタンプあり
│
├─ 注文IDで取得
│    ↓
│  時系列DBとは限らない
│
└─ 時間窓 / 傾向を中心に分析
     ↓
   時系列DB候補

つまり、

データ形式
だけを見る
        ×

データ形式
+
アクセスパターン
を見る
        ○

です。

16. 既存アプリケーションとの互換性も重要な決定条件

完全な新規開発ではデータモデルを自由に選べても、既存システムの移行では互換性が強い制約になります。

例えば、

既存SQL Server
→ Amazon RDS for SQL Server

既存MongoDBアプリケーション
→ Amazon DocumentDBを評価

既存Cassandraアプリケーション
→ Amazon Keyspacesを評価

のように、

ドライバー
プロトコル
クエリ言語
データベースエンジン
アプリケーションの動作

が選択条件になります。

マネージドサービスへ移行する場合でも、互換性があるというサービス名だけで決めず、実際に使用している機能まで確認します。

17. 1つのアプリケーションで1種類だけを使う必要はない

目的別データストアでは、

アプリケーション
      │
      ├─ トランザクション
      │      ↓
      │   RDS / Aurora
      │
      ├─ インメモリ処理
      │      ↓
      │   ElastiCache
      │
      └─ 検索
             ↓
          OpenSearch Service

のように、アクセスパターンごとに異なるサービスを組み合わせることがあります。

これは、

どれが最も優れたデータベースか

を選ぶ問題ではありません。

この処理では
何が最も適切か

を選びます。

ただし、複数サービスをどのように接続し、キャッシュ、バッファ、レプリカなどを含めた全体アーキテクチャへ組み立てるかは、個々のサービス選択とは別に考えます。

18. 混同ポイント

19. SAP-C02での判断フロー

データ要件
      ↓
主要なデータモデルは？
      │
      ├─ リレーショナル
      │     ↓
      │  必要なエンジン / 互換性
      │     ↓
      │  RDS / Aurora
      │
      ├─ キーバリュー
      │     ↓
      │  DynamoDB
      │
      ├─ ドキュメント
      │     ↓
      │  MongoDB互換性が必要？
      │     ↓
      │  DocumentDB
      │
      ├─ グラフ
      │     ↓
      │  関係探索が中心？
      │     ↓
      │  Neptune
      │
      ├─ ワイドカラム
      │     ↓
      │  Cassandra / CQL？
      │     ↓
      │  Keyspaces
      │
      ├─ 時系列
      │     ↓
      │  タイムスタンプ + 時間窓クエリ？
      │     ↓
      │  Timestream候補
      │  ※利用可否も確認
      │
      ├─ インメモリ
      │     ↓
      │  超低レイテンシーと
      │  インメモリデータ構造？
      │     ↓
      │  ElastiCache
      │
      └─ 検索
            ↓
         OpenSearch Service

      ↓

主要なアクセスパターンと一致するか？

      ↓

既存エンジン / APIとの互換性は？

      ↓

レイテンシー / スケール / 整合性要件を満たすか？

      ↓

目的に合ったデータストアを選択

最初からサービス名を決めるのではなく、

データモデル
↓
データアクセスパターン
↓
クエリ要件
↓
互換性
↓
性能要件
↓
サービス選択

の順で絞り込みます。

まとめ

目的別データベース選択で最も重要なのは、

データの種類
ではなく

データを
どう扱うか

まで見ることです。

代表的な判断は、

リレーショナル / SQL / 結合
→ Amazon RDS / Amazon Aurora

既知のキーによるアクセス
→ Amazon DynamoDB

MongoDB互換ドキュメント
→ Amazon DocumentDB

高度に接続された関係
→ Amazon Neptune

Cassandra / CQL / ワイドカラム
→ Amazon Keyspaces

時系列
→ Amazon Timestream

インメモリ
→ Amazon ElastiCache

全文検索 / 検索
→ Amazon OpenSearch Service

です。

そして、

JSONだからDocumentDB
ACIDだからRDS
タイムスタンプがあるからTimestream
高速だからDynamoDB

のような単独条件で決めません。

データモデル
+
データアクセスパターン
+
互換性
+
クエリ要件
+
性能要件

を合わせて判断します。

主要AWS公式資料

AWS Certified Solutions Architect - Professional試験ガイドでは、タスク2.5の対象知識として「目的別データベース」、対象スキルとして必要なタスクに特化したサービスを選択するための方法論が明記されています。

AWS Database Decision Guideでは、Amazon RDS、Amazon Aurora、Amazon DynamoDB、Amazon DocumentDB、Amazon Neptune、Amazon Keyspaces、Amazon ElastiCache、Amazon Timestreamなどをデータモデルやデータアクセスの観点から比較しています。