DynamoDBをいつ使うべきか(そしていつ使うべきでないか)

DynamoDBは、それが作られた対象のワークロードには素晴らしいデータベースであり、それ以外には苛立たしいものです。決め手となる問いは「ウェブスケールか?」ではなく — 「アクセスパターンを前もって把握しているか、そしてそれらはキーベースか?」です。これを正しく押さえればDynamoDBはどんなスケールでも1桁ミリ秒の読み取りを提供します。誤れば、結合やアドホッククエリの欠如と永遠に戦うことになります。

DynamoDBはいつ使うべきか？

アクセスパターンが既知でキーベースかつ大量の場合、そして管理するサーバーなしにどんなスケールでも予測可能な1桁ミリ秒のレイテンシが必要な場合は、DynamoDBを使用してください。アドホッククエリ、豊富な結合、またはデータセット全体の分析が必要な場合、あるいはデータが小さくクエリの形が変わり続ける場合は避けてください。

DynamoDBを使うのは、アクセスパターンが既知で、キーベースで、大量であり — 管理するサーバーなしにどんなスケールでも予測可能なレイテンシが欲しいとき。
避けるのは、アドホッククエリ、豊富な結合、データセット全体にわたる分析が必要なとき、またはデータが小さくクエリの形が変わり続けるとき。
核心的なトレードオフ: DynamoDBはクエリのために前もって設計させます。その見返りに、成長しても決して遅くなりません。
これは構文が違うだけのリレーショナルデータベースではありません — そのようにモデリングすることが苦痛の最大の原因です。

DynamoDBが有利になるシグナル

DynamoDBは、これらの多くが当てはまるときに輝きます:

アクセスパターンを事前に把握している。 アプリが行う正確なクエリ(「idでユーザーを取得」「ユーザーの注文を新しい順に一覧」)を列挙でき、それらが気まぐれに変わらない。 DynamoDBはそれらのクエリを中心にモデリングされます。
アクセスがキーベース。 任意の属性の組み合わせをスキャンするのではなく、既知のパーティションキーでアイテムを参照する。
スケールと予測可能なレイテンシが重要。 DynamoDBは、テーブルが千件でも10億件でも一貫した1桁ミリ秒のパフォーマンスを発揮します。
運用オーバーヘッドをゼロにしたい。 インスタンスもフェイルオーバーもバキューミングもなし — フルマネージドで、オンデマンドならゼロまでスケールします。
書き込みスループットが高く急増する。 イベントログ、IoTテレメトリ、セッション/カートの状態、リーダーボード — 明確なキーを持つ追記中心のワークロード。

不利になるシグナル

代わりにリレーショナルデータベース(または検索/分析エンジン)を選ぶのは、次のときです:

クエリがアドホック。 アナリストが任意のカラムでデータを切り分けたり、要件が毎週変わったりする。SQLの柔軟性が勝ちます。DynamoDBはパターンごとに新しいインデックスが必要になります。
データセット全体にわたる本物の結合と集計が必要。 レポーティング、ビジネスインテリジェンス、「地域別・月別の売上合計」 — これはOLAP/リレーショナルの仕事です。（ライブテーブルへの一度きりの質問は別の話です — DynoTableのSQL WorkbenchはJOIN、GROUP BY、集計をDynamoDBに対してクライアント側で実行します。よそに置くべきなのは常設のBIワークロードのほうです。）
データセットが小さくトラフィックが少ない。 静かな管理アプリの数千行は、DynamoDBのスケールから恩恵を受けず、SQLの利便性を失います。
アクセスパターンをまだ予測できない。 まだ形を模索している初期段階のプロダクト? 自由に再クエリできるリレーショナルなスキーマのほうが、パターンが固まるまでは寛容です。

DynamoDBと他のデータベースの比較

「DynamoDBとXのどちらを使うべきか?」という問いは、たいてい装いを変えた同じ問いです: Xはアクセスパターンの決定を先送りさせてくれるのか、そしてその代償は何か? DynamoDBは、その先送りを断固として許さない選択肢です。以下の比較はすべて、機能のチェックリストではなく、このたった1つのトレードオフを軸にしています。

リレーショナル: PostgreSQL、RDS、Aurora

ここが本当の分かれ道であり、多くのチームが間違えるところです。リレーショナルデータベースではデータを手にした後でクエリを書けます。DynamoDBではそうはいきません — テーブルは、アイテムが1件も書き込まれる前に、クエリによって形が決まります。

リレーショナルを選ぶのは、クエリの形がまだ動いているとき、データセット全体にわたる結合や集計が必要なとき、あるいはデータが十分に小さくスケールが問題になっていないときです。 DynamoDBを選ぶのは、パターンが固まっていてキーベースであり、そのコストが10億件でも千件でも同じであってほしいときです。

RDSとAuroraはこの計算を変えません — どちらもマネージドなリレーショナルエンジンであり、 SQLの柔軟性とそのスケーリングモデルをそのまま受け継ぎます。変わるのは運用面の比較です: Aurora Serverlessがあると、DynamoDBの「管理するサーバーがない」という論拠はかなり弱まり、判断はきれいにアクセスパターンへと戻ってきます。Auroraはコンピュートをスケールさせ、 DynamoDBはその概念そのものをなくします。

ドキュメント: MongoDBとDocumentDB

どちらもJSON風のドキュメントを保存するので、遠目にはDynamoDBと交換可能に見えます。そうではありません。MongoDBは任意のフィールドにインデックスを張り、それに対してアドホックなクエリを実行します。DynamoDBが与えるのは、パーティションキー、ソートキー、そして事前に宣言したインデックスだけです。

そのためMongoDBは変化し続けるクエリの形に、DynamoDBは既知のクエリを大量にさばく用途に向きます。DocumentDBは同じ線のAWS側にいます — MongoDBのAPIを話すので、「MongoDBの柔軟性に AWSの運用モデル」として扱い、DynamoDBとは上と同じ「柔軟性対予測可能性」の軸で比較してください。

ワイドカラム: Cassandra

Cassandraはアーキテクチャ上、DynamoDBに最も近い親戚です: パーティションキー、クラスタリングキー、そして「悪いパーティションキーはインデックスでは抜け出せない設計上のバグだ」という同じ厳しい真実。両者のどちらかを選ぶとき、決め手になるのがデータモデルであることはまれです — 誰が運用し、どう支払うかです。Cassandraは自分で運用します(またはマネージドを買います)。DynamoDBは消費するだけです。Amazon Keyspacesは、マネージドな Cassandraという中間地点です。

モデルがこれほど近いので、このサイトのモデリングの指針はほとんどそのまま通用します。シングルテーブル設計におけるパーティションキーとアクセスパターンの考え方は、Cassandraにもほぼ一行一行そのまま当てはまります。

インメモリ: Redis

これは本当の二者択一ではありません。Redisはメモリ優先で、失っても再構築しても構わないデータへのサブミリ秒アクセスに最適化されています。DynamoDBはデフォルトで永続的です。本番での一般的な答えは両方です — DynamoDBを記録の正本とし、ホットキーの前にRedis(あるいは DynamoDB自身のリードスルーキャッシュであるDAX)を置きます。

Redis単体に手を伸ばすのは、データが本当に一時的なときだけです: レート制限のカウンター、短命なセッション、再計算できるリーダーボードなど。

検索: ElasticsearchとOpenSearch

これも二者択一ではなく、しかもRedisのときよりはっきりした理由があります: DynamoDBには全文検索がそもそもありません。Queryが一致させられるのはキーの等価条件と、限られたソートキー条件だけです。FilterExpression付きのScanはすべてのアイテムを読んでからその大半を捨てます — フィルターを後付けしたテーブルの総なめであって検索ではなく、返ってきたアイテムではなく読んだアイテムの分だけ課金されます。関連度によるランキングも、アナライザーも、あいまい検索も、ファセットもありません。

ですから問いは決して「DynamoDBか検索エンジンか」ではありません。「このワークロードに検索が必要か、必要ならインデックスに何を流し込むのか」です。標準的な構成は両方です: DynamoDBを記録の正本とし、その隣に検索クラスターを置き、DynamoDB Streamsがすべての変更をインデックスへ運びます。これで本物の検索が手に入る代わりに、運用すべき2つ目のシステムと、テーブルに対して結果整合性であるインデックスという代償を払うことになります。

OpenSearchとElasticsearchは同じ判断です。 OpenSearchはAWSによるElasticsearchのフォークで、Elasticのライセンス変更をめぐって2021年に7.10で分岐し、以来2つは離れていきました。その乖離は、この問いには一切関係しません — 「検索をDynamoDBの外に置くべきか」という点では、両者はまったく同じように振る舞います。どちらを選ぶかは、ライセンス、ホスティング、そしてどのマネージドサービスを運用したいかで決めるべきであって、 DynamoDBに関係する何かで決めるべきではありません。

検索エンジンをプライマリのストアに据えるのは、検索が本当にプロダクトそのものであるときだけにしましょう — ログ分析や、主要なアクセスパターンが全文検索であるカタログなど。それでも多くのチームはその背後に永続的なストアを置きます。検索インデックスは派生的なビューであり、再構築できる必要があるからです。

データモデルの比較が隠すコストの軸

ここまでの比較はどれもデータモデルの話ですが、請求書での驚きはたいてい構造的なものです: リレーショナルエンジンはプロビジョニングしたキャパシティに課金し、DynamoDBは 実行したオペレーションに課金します。そのためDynamoDBは、急増するワークロードやアイドル状態のワークロードには安く、持続的なスキャンには高くつきます — まったく同じワークロードが、コードを1行も変えずに、一方のエンジンでは勝ち、もう一方ではひどく負けることがあります。

見落とされがちな乗数がインデックスです。リレーショナルエンジンならインデックスを1つ増やすコストはストレージと多少の書き込みレイテンシですが、DynamoDBではすべてのセカンダリインデックスが、投影された属性のまるまる1回分の追加の書き込みになります。インデックスのガイドで3つの書き込み量について計算を出しました — GSIが1つで書き込みの請求額は2倍、2つで3倍です。どちらかに決める前に、料金計算ツールで実際の読み書きの構成をモデル化しましょう。

採用前にコストを見積もる

DynamoDBの料金は、インスタンス時間ではなく、読み取り・書き込み・ストレージに従います — そのため急増するワークロードやサーバーレスのワークロードには安価で、持続的な重いスキャンには高くつくことがあります。採用する前に DynamoDB料金計算ツールで実際の読み書きの構成をモデル化しましょう。技術的に適合して見えるワークロードは、コスト面でも採算が合うべきです。

適合すると判断したら

作業はモデリングへと移ります。DynamoDBは、クエリを中心にテーブルを設計することに報います — DynamoDBでのデータモデリング方法とシングルテーブル設計、そして明示的にシングルテーブルを選ぶべきでないときを参照してください。

DynoTable のアイテムグリッドでデータの入った DynamoDB テーブルを閲覧する。

落とし穴と次のステップ

DynamoDBをリレーショナルデータベースのようにモデリングしてはいけない — 読み取り時に結合する正規化されたテーブルは、DynamoDBが最も厳しく罰するアンチパターンです。
分析のために選んではいけない — レポーティングにはスキャンする代わりに、分析用ストアと組み合わせる(またはそこへエクスポートする)。
アクセスパターンに自信がない? 待ちましょう。 クエリを把握する前にDynamoDBを採用することは、それを把握していることを要求する唯一のデータベースを選ぶことです。
関連: QueryとScanが、「キーベースのアクセス」が実際に何をもたらすかを示しています。

アプリを賭ける前にDynamoDBテーブルを探索したいですか? DynoTableをダウンロードして、データに直接接続してください — そのSQL Workbenchが、DynamoDB自体は実行しないアドホックなJOINと集計を実行します。