DynamoDB vs Amazon RDS

DynamoDB と Amazon RDS はどちらも AWS のマネージドなデータベースですが、2 つの異なる世界を代表します。DynamoDB は、既知のアクセスパターンと水平スケールを中心に設計されたサーバーレスな NoSQL のキーバリューおよびドキュメントデータベースです。Amazon RDS は、インスタンスベースのリレーショナルエンジン — MySQL、PostgreSQL、MariaDB、SQL Server、Oracle、Db2 — をフルの SQL、結合、強制されるスキーマとともに実行するマネージドサービスです。

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

予測可能でキーベースのアクセスを持つ大規模な運用ワークロードで、サーバーレスなスケーリングと管理すべきインスタンスがないことを望む場合は DynamoDB を選びます。使い慣れたリレーショナルエンジン上でフルの SQL — 結合、アドホックなクエリ、正規化されたテーブルにまたがるトランザクション — が必要で、データがリードレプリカで垂直スケールできるインスタンスに収まる場合は Amazon RDS を選びます。クエリの柔軟性か、手のかからないスケールかが中心的なトレードオフです。

DynamoDB と Amazon RDS の概要

特性	DynamoDB	Amazon RDS
データモデル	NoSQL のキーバリューおよびドキュメント。アイテムごとに柔軟なスキーマ、アイテムは最大 400 KB	リレーショナル — 選んだエンジン上で、スキーマが強制されるテーブル・行・列
クエリ言語	ネイティブ API（`GetItem`、`Query`、`Scan`）に加え、SQL 互換言語の PartiQL	基盤エンジンのフルの SQL（MySQL、PostgreSQL、MariaDB、SQL Server、Oracle、Db2）
結合と関係	JOIN 演算子はなし。AWS はアクセスパターンに沿った非正規化を推奨	テーブル間のフルのリレーショナル結合、外部キー、制約
インデックス	代替キー上のグローバル/ローカルセカンダリインデックス	エンジンのインデックス種別（B-tree、hash、エンジン固有のもの）に加え、一部のエンジンでは部分/式インデックス
整合性	デフォルトは結果整合性。リクエストごとに強い整合性のある読み取り。ACID トランザクション	デフォルトで強い整合性。フルの複数ステートメント ACID トランザクション
スケーリングモデル	水平 — 自動パーティショニング。サーバーレスのオンデマンドが上下（ゼロまで）にスケール	垂直 — リサイズするプロビジョンドインスタンスに加え、読み取りスケールアウト向けのリードレプリカ
プロビジョニング / 運用	サーバーレス。サイズ設定やパッチをするインスタンスなし	インスタンスベース。クラスとストレージを選び、AWS がパッチ、バックアップ、フェイルオーバーを管理（Multi-AZ は任意）
料金モデル	リクエスト課金（オンデマンド）またはプロビジョンドキャパシティ＋ストレージ。アイドル時にゼロまでスケール	DB クラスのインスタンス時間＋ストレージ（一部のオプションでは I/O も）。インスタンスの稼働中に課金
最適なワークロード	既知のキーアクセスを持つ大規模な運用アプリ（カート、セッション、イベント、リーダーボード）	結合、アドホックなクエリ、強いデータ整合性を要するリレーショナルおよび分析ワークロード

DynamoDB が適している場合

アクセスパターンが既知でキーベースである。 読み取りに合わせてキーを設計すれば、ユーザーが数百であろうと数億であろうと、一貫した 1桁ミリ秒のレイテンシが得られます。
インスタンスなしのサーバーレスが欲しい。 オンデマンドキャパシティはサイズ設定やパッチをするものがなく、アイドル時にゼロまでスケールします — 24 時間稼働するインスタンスはありません。
書き込みを水平にスケールする必要がある。 DynamoDB は自動的にパーティショニングします。単一のリレーショナルプライマリをスケールする際のようにシャーディングツールを追加する必要はありません。
ワークロードがアイテム指向である（プロファイル、セッション、カート、イベント） — 結合されたテーブルの網ではなく。

Amazon RDS が適している場合

フルの SQL と結合が必要である。 RDS は、結合、集計、外部キー、正規化されたテーブルにまたがるアドホックなクエリを備えた本物のリレーショナルエンジンを実行します。
アクセスパターンが進化し続ける。 柔軟なクエリを備えたリレーショナルスキーマは、キーを再設計することなく新しい問いに適応します。
使い慣れたエンジンが欲しい。 MySQL、PostgreSQL、MariaDB、SQL Server、Oracle、Db2 により、チームは既存のスキル、ツール、SQL を再利用できます。
データセットが垂直スケールされたインスタンスに収まり、リードレプリカを備え、安定したクエリ中心のトラフィックが常時稼働のインスタンスに適する。

DynamoDB を扱う

DynamoDB が分岐の正しい側であるなら、DynoTable は macOS、Windows、Linux 向けのそれ用のネイティブなデスクトップクライアントです。標準の AWS 認証情報チェーンを読み取るため、データは DynamoDB に残り、移行するものは何もありません。RDS から移ってきたチームにとって重要なことに、その SQL Workbench は DynamoDB のアクセスパターンのルールの範囲内でリレーショナル形状のクエリ — 結合、GROUP BY、集計 — を、DynamoDB 自身の Query/Scan 操作にコンパイルすることで表現し、AI アシスタントはあなた自身の AWS Bedrock 認証情報で動作します。

SQL を書けないのが物足りない場合は、SQL for DynamoDB と PartiQL vs SQL のガイドが、何が引き継がれ何が引き継がれないかを説明し、DynamoDB JOIN ガイドはネイティブな結合なしで関係をモデル化する方法を扱います。無料の DynamoDB Expression Builder は、正確なキー条件、フィルタ、更新式を SDK、CLI、PartiQL の形式で生成します。DynoTable はクローズドソースの商用アプリです。このページはその機能を説明するものであり、どのように作られているかを説明するものではありません。

よくある質問

DynamoDB は Amazon RDS を置き換えられますか？

一部のワークロードなら可能です。アクセスパターンが予測可能でキーベースであれば、DynamoDB は RDS インスタンスを置き換え、スケーリングとパッチ作業の大半を取り除けます。結合、アドホックなリレーショナルクエリ、絶えず変化するクエリ対象に依存する場面 — RDS の強み — には不向きです。多くのチームは両方を運用します: リレーショナル作業には RDS、高スループットなキーアクセスには DynamoDB です。

DynamoDB は RDS のように SQL や結合をサポートしますか？

DynamoDB は SELECT、INSERT、UPDATE、DELETE 向けの SQL 互換言語 PartiQL をサポートしますが、JOIN 演算子はありません。AWS は代わりに非正規化を推奨します。RDS の背後にあるエンジンは、テーブル間の結合を含むフルの SQL をサポートします。結合なしで関係をモデル化する方法は DynamoDB での結合を参照してください。

DynamoDB は RDS より安いですか？

ワークロード次第なので、両方をモデル化してください。DynamoDB はリクエスト単位（またはプロビジョンドキャパシティ）＋ストレージで課金され、アイドル時にゼロまでスケールするため、急峻またはベースラインの低いトラフィックに適します。RDS は稼働中のクラスのインスタンス時間＋ストレージで課金され、安定したクエリ中心のワークロードではより費用対効果が高くなりえます。決める前に、実際のアクセスパターンに対して見積もってください。