DynamoDB vs Amazon Aurora

自分のワークロードには DynamoDB と Aurora のどちらが適しているか？

Amazon DynamoDB は、あらゆる規模で1桁ミリ秒のパフォーマンスを実現するために構築されたフルマネージドの NoSQL キーバリュー・ドキュメントストアで、固定スキーマを持ちません。Amazon Aurora は MySQL および PostgreSQL と互換性のあるマネージドリレーショナルデータベースで、テーブル、結合、ACID トランザクションを備えた完全な SQL を使用します。高スケールなキーバリューアクセスには DynamoDB を、リレーショナルクエリには Aurora を選びましょう。

DynamoDB vs Amazon Aurora の概要

特性	DynamoDB	Amazon Aurora
データモデル	NoSQL キーバリュー・ドキュメントストア。スキーマレス（必須なのはプライマリキーのみ）	リレーショナル: 定義されたスキーマとリレーションシップを持つ構造化されたテーブル、行、列
クエリ言語	AWS SDK/API 操作に加え、select/insert/update/delete 向けの SQL 互換クエリ言語 PartiQL	完全な SQL。MySQL または PostgreSQL と互換
結合	サーバーサイドの結合なし。アクセスパターンを事前にモデリングする（多くはシングルテーブル設計）	リレーショナルエンジンによるテーブル間のネイティブな SQL `JOIN`
インデックス	ローカルおよびグローバルセカンダリインデックス（LSI / GSI）	MySQL/PostgreSQL が提供する標準的なリレーショナルインデックス（プライマリおよびセカンダリ）
整合性	デフォルトは結果整合性のある読み取り。リクエストごとに強い整合性のある読み取りも利用可能	完全なリレーショナル整合性を伴う強い整合性
スケーリング	パーティションをまたいで水平方向にスケールアウト。テーブルあたりのアイテム数やテーブルサイズに上限なし。オンデマンドまたはプロビジョンドキャパシティ	1つのライターと、3つのアベイラビリティーゾーンにわたる最大15の低レイテンシーリードレプリカからなるクラスター。ストレージは 256 TiB まで自動拡張。Aurora Serverless v2 はキャパシティを自動スケール
トランザクション	単一リージョン内で最大100アイテム（合計 4 MB）の ACID トランザクション	完全なマルチステートメント ACID トランザクション
料金モデル	オンデマンドまたはプロビジョンドキャパシティ（読み取り/書き込みユニット）に加えてストレージ	インスタンスキャパシティ（オンデマンドまたはリザーブド）または Aurora Serverless v2、さらにストレージと I/O
最適な用途	Web スケールのキーバリュー/ドキュメントワークロード、予測可能な低レイテンシー	結合、複雑なクエリ、SQL の親しみやすさを必要とするリレーショナルワークロード

DynamoDB が適している場合

DynamoDB は、アクセスパターンが既知でキーベースであり、トラフィックが増えても予測可能な1桁ミリ秒のレイテンシーが必要な場合に適しています。AWS DynamoDB Developer Guide によると、DynamoDB はアイテム数やテーブル合計サイズに上限を設けず、分散ハードウェア上でスケールアウトするよう設計されており、ソーシャルネットワーク、ゲーム、メディア共有、IoT といった Web スケールのアプリケーションに向いています。サイズ調整するインスタンスが不要なサーバーレスの運用モデルを望む場合や、柔軟で半構造化なアイテム形状（JSON を含む）が利点になる場合にも好適です。ワークロードが断続的、あるいはキーバリューの性質を持つなら、DynamoDB のリクエスト単位のモデルによってコストが利用状況に密接に連動します。

Aurora が適している場合

Aurora はリレーショナルワークロードに適しています。実際のリレーションシップを持つデータ、複雑なアドホッククエリ、結合、集計、そして SQL が自然な道具となるレポーティングなどです。Aurora は MySQL および PostgreSQL 互換であるため、既存の SQL コード、ツール、ORM はほとんど変更なしで動作し、SQL にすでに習熟したチームはそのスキルを活かせます。多数の関連テーブルにまたがる強い整合性とリレーショナル整合性が重要な場合、あるいは豊富なスキーマにまたがるマルチステートメントトランザクションが必要な場合、Aurora は有力な選択肢です。AWS はまた、両者がしばしば補完的であることにも言及しています。たとえば、ホットパスに DynamoDB を、分析やレポーティングのパスに Aurora を用いるといった具合です。

DynamoDB を扱う

DynamoDB を選んだら、DynoTable は AWS コンソールなしでテーブルの参照、編集、クエリを行えるデスクトップ DynamoDB クライアントです。DynamoDB にはサーバーサイドの結合がないため、キーやインデックスに対するクエリの表現が日々の作業の大半を占めます。無料の DynamoDB Expression Builder は、キー条件、フィルター式、プロジェクションを組み立て、それに対応する SDK、CLI、または PartiQL のコードを出力するのに役立ちます。DynoTable はクローズドソースの商用アプリケーションで、標準の AWS 認証情報を読み取って DynamoDB と直接やり取りするため、他のクライアントから乗り換える際に移行するものは何もありません。

よくある質問

DynamoDB は Aurora より安いですか？

ワークロード次第で、どちらかが一律に安いということはありません。DynamoDB はオンデマンドまたはプロビジョンドの読み取り/書き込みキャパシティに加えてストレージに対して課金されるため、コストはリクエスト量に連動し、アイドル時にはほぼゼロに近づきます。Aurora はインスタンスキャパシティ（または Aurora Serverless v2）に加えてストレージと I/O に対して課金されます。断続的でキーバリューなトラフィックには DynamoDB のリクエスト単位モデルが安く済むことが多く、持続的で大量のリレーショナルワークロードにはプロビジョンドの Aurora クラスターの方が経済的な場合があります。判断する前に、自分の読み取り/書き込みパターンをモデリングしましょう。

サーバーレスアプリでは Aurora と DynamoDB のどちらがよいですか？

どちらもサーバーレス的な運用を提供するため、決め手は課金モデルではなくデータモデルです。DynamoDB は設計上サーバーレスで、管理するインスタンスがなく、キャパシティは自動でスケールし、リクエスト単位の料金体系であるため、スケールするキーバリューおよびドキュメントアクセスに適しています。Aurora Serverless v2 はリレーショナルエンジンを自動スケールし（アイドル時にはゼロまでスケール可能）、SQL、結合、リレーショナル整合性を本当に必要とするサーバーレスアプリに適しています。キーバリューのアクセスパターンには DynamoDB を、アプリが本質的にリレーショナルなら Aurora を選びましょう。