DynamoDB vs Amazon Neptune

DynamoDB と Amazon Neptune はどちらも AWS のフルマネージドなデータベースですが、データのモデル化方法は根本的に異なります。DynamoDB はキーで問い合わせるキーバリューおよびドキュメントストアです。Neptune はノードとエッジ（または RDF トリプル）を格納し、グラフクエリ言語で関係を直接たどる、グラフ用途に特化したグラフデータベースです。選択の決め手は、関係そのものが主なクエリ対象かどうかにあります。

DynamoDB と Neptune のどちらを使うべきか

大規模で構造化されたレコードへのキーベースのアクセスがあり、関係が限定的でキーでモデル化できる場合は DynamoDB を選びます。つながりがクエリの中核となる場合 — マルチホップのトラバーサル、最短経路、レコメンデーション、不正リング、ナレッジグラフなど、キーバリューストアなら多数の往復が必要になるものをグラフモデルなら 1 つのクエリで表現できる場合 — は Amazon Neptune を選びます。クエリがどれだけ関係中心かで決まります。

DynamoDB と Amazon Neptune の概要

特性	DynamoDB	Amazon Neptune
データモデル	NoSQL のキーバリューおよびドキュメント。テーブル内で型付きアイテムは最大 400 KB	グラフ — プロパティグラフ（プロパティを持つノード/エッジ）と RDF（主語・述語・目的語のトリプル）
クエリ言語 / API	ネイティブ API（`GetItem`、`Query`、`Scan`）に加え、SQL 互換言語の PartiQL	プロパティグラフ向けの Gremlin と openCypher、RDF グラフ向けの SPARQL
主なアクセス	パーティション/ソートキーによるキーベースのルックアップ。関係はキーでモデル化	関係のトラバーサル — 1 つのクエリで多数のホップにわたってエッジをたどる
関係	ネイティブなトラバーサルはなし。隣接リストやシングルテーブル設計でモデル化	エッジがファーストクラス。マルチホップやパスのクエリがネイティブかつ効率的
整合性	デフォルトは結果整合性。リクエストごとに強い整合性のある読み取りが可能	クラスタ内で読み取りは整合的。リードレプリカがスケールされた読み取りを処理
スケーリングモデル	自動パーティショニング。サーバーレスのオンデマンドまたはプロビジョンドキャパシティ	リードレプリカ付きのプロビジョンド DB インスタンス、または自動スケールする Neptune Serverless（NCU 単位のキャパシティ）
トランザクション	リージョン内の複数アイテムにまたがる ACID トランザクション	グラフの変更にまたがる ACID トランザクション
料金 / 運用モデル	リクエスト課金（オンデマンド）またはプロビジョンドキャパシティ＋ストレージ。サーバーレス	インスタンス時間（プロビジョンド）または NCU 時間（Serverless）に加えてストレージと I/O。AWS 限定
最適なワークロード	プロファイル、セッション、カート、イベントなど — 大規模なキーベースのレコード	ソーシャルグラフ、レコメンデーション、不正検知、ナレッジグラフ、ネットワーク/アイデンティティグラフ

DynamoDB が適している場合

アクセスがキーベースである。 ID による取得、パーティションへのクエリ、パーティション内でのフィルタは DynamoDB に自然にマッピングされ、どんな規模でも高速なままです。
関係が浅いか限定的である。 一対多や多対多のリンクは、グラフエンジンなしでもキー — 隣接リストやシングルテーブル設計 — でモデル化できます。
サーバーレスの手軽さとリクエスト課金が欲しい。 オンデマンドキャパシティはサイズ設定が不要で、アイドル時はゼロまでスケールします。
深いトラバーサルを行わない。 1、2 ホップより先をたどることがめったにないなら、グラフデータベースの強みは活かされません。

Neptune が適している場合

関係こそがクエリである。 マルチホップのトラバーサル — 友達の友達、最短経路、「誰と誰がつながっているか」 — は Gremlin、openCypher、SPARQL でネイティブに扱え、キーバリューストアなら多数の逐次読み取りが必要になります。
プロパティグラフや RDF が必要である。 Neptune は両モデルとその標準クエリ言語をサポートし、ナレッジグラフやリンクトデータの用途に適します。
ドメインがグラフ形状である。 不正検知、レコメンデーションエンジン、ソーシャルネットワーク、アイデンティティ/ネットワークグラフは、ノードとエッジとして自然に表現できます。
トラバーサルのパターンが進化し続ける。 新しい関係の問いは、キーの再設計ではなく新しいグラフクエリになります。

役立つ経験則として、DynamoDB は隣接リストパターンで関係を表現でき、トラバーサルが事前に分かっていて浅いままなら、それで十分です。トラバーサルが深い、深さが可変、またはアドホックな場合は、まさにそのために作られた Neptune のグラフエンジンが適しており、キーバリューストアでエッジをたどる際の多数の往復コストを回避できます。

DynamoDB を扱う

ワークロードがキーベースで、関係を隣接リストでモデル化しているなら、DynoTable は macOS、Windows、Linux で動作する DynamoDB 向けのネイティブなデスクトップクライアントです。標準の AWS 認証情報チェーンを読み取るため、データは DynamoDB に残り、移行するものは何もありません。アイテムの閲覧とインライン編集、キー条件とフィルタのビジュアルな構築を行い、さらに DynamoDB のアクセスパターンのルールの範囲内でリレーショナル形状のクエリを表現する SQL Workbench と、あなた自身の AWS Bedrock 認証情報で動く AI アシスタントを備えています。

無料の DynamoDB Expression Builder は、隣接リストモデルに必要なキー条件、フィルタ、更新式を SDK、CLI、PartiQL の形式で生成します。DynoTable はクローズドソースの商用アプリです。このページはその機能を説明するものであり、どのように作られているかを説明するものではありません。

よくある質問

DynamoDB はグラフデータベースとして使えますか？

部分的には可能です。DynamoDB にネイティブなグラフトラバーサルはありませんが、隣接リストパターンやシングルテーブル設計で関係をモデル化でき、トラバーサルが既知で浅い場合にはうまく機能します。深い、深さが可変、またはアドホックなトラバーサル — 最短経路やマルチホップのレコメンデーション — には、多数の個別読み取りを発行する代わりにエッジをネイティブにたどる、Neptune のような用途特化のグラフデータベースが適しています。

Neptune と DynamoDB はそれぞれどのクエリ言語をサポートしますか？

Neptune はプロパティグラフ向けに Gremlin と openCypher、RDF グラフ向けに SPARQL をサポートします。DynamoDB はネイティブ API（GetItem、Query、Scan と関連する操作）に加えて、SQL 互換言語の PartiQL を使います。クエリ言語に重なりはなく、モデルが異なります。

DynamoDB より Neptune を選ぶべきなのはどんなときですか？

多ホップのトラバーサル、パス探索、あるいは不正検知・レコメンデーション・ナレッジグラフのような関係中心のドメインなど、つながりが最も多くクエリする対象である場合は Neptune を選びます。アクセスが主にキーによるもので、関係がキーでモデル化できる程度に限定的である場合は DynamoDB を選びます。アーキテクチャによっては両方を使い、運用レコードには DynamoDB、その上に広がる連結グラフには Neptune を用いることもあります。