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

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

DynamoDBはいつ使うべきか？

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

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

DynamoDBが有利になるシグナル

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

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

不利になるシグナル

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

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

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

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

適合すると判断したら

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

落とし穴と次のステップ

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

アプリを賭ける前にDynamoDBテーブルを探索したいですか? DynoTableをダウンロードして、データに直接接続してください。