Amazon Web Services ブログ

Amazon DynamoDB のベストプラクティスに従うという 2019 年の計を立てる

 

AWS ではこの 2019 年、DynamoDB での作業時にミッションクリティカルなワークロードのパフォーマンスを最大化して、コストを最適化するために役立つ Amazon DynamoDB のベストプラクティスに従うことをお勧めします。この記事は、このような抱負の維持を助ける DynamoDB のコンテンツに焦点を当てて行きます。

DynamoDB テーブルにある各アイテムを固有に識別するプライマリーキーは、シンプルなキー (パーティションキーのみ) または複合キー (ソートキーと組み合わされたパーティションキー) にすることができます。アプリケーションは、テーブルとそのセカンダリインデックスの論理パーティションキー全体で統一されたアクティビティのために設計してください。これは NoSQL のベストプラクティスですが、バーストキャパシティー、アダプティブキャパシティー、および書き込みシャーディングといった追加のメリットが得られます。

DynamoDB テーブルでは、テーブル内の各アイテムを固有に識別するプライマリーキーを、パーティションキーだけではなく、ソートキーも使って構成することができます。適切に設計されたソートキーは、関連する情報を一か所に集め、それを効率的にクエリすることができます。複合ソートキーは、データで階層 (1 対多) リレーションシップを定義することを可能にし、任意の階層レベルでクエリすることができます。

多くの場合、セカンダリインデックスはアプリケーションが必要とするクエリパターンをサポートするために必須です。その一方、非効率的なセカンダリインデックスの使用は不必要にコストを増加させ、パフォーマンスを低下させます。

DynamoDB では現在、テーブルに保存する各アイテムのサイズが制限されています。お使いのアプリケーションに、サイズ制限の許容範囲を超えるデータをアイテムに保存する、またはそのアイテムをソートキーの効率的な使用によって分類される複数のアイテムに分割する必要がある場合、ひとつ、または複数の大型の属性を圧縮してみる、またはそれらを Amazon S3 内のオブジェクトとして保存して、Amazon S3 オブジェクト識別子を DynamoDB アイテムに保存することができます。

DynamoDB における一般的な設計原則では、使用するテーブルの数を最小限にとどめることが推奨されています。ほとんどのアプリケーションには、単一のテーブルしか必要ありません。しかし、時系列データについては、期間ごとに 1 アプリケーションあたり 1 つのテーブルを使うことができます。

隣接リストは、DynamoDB における多対多リレーションシップのモデル化に有用な設計パターンです。より一般的には、DynamoDB でグラフデータ (ノードとエッジ) を表現する方法を提供します。

状況によっては、ひとつ、または複数のリレーショナルデータベース管理システム (RDBMS) からの DynamoDB への移行が有利ではない場合があります。この場合は、ハイブリッドシステムの作成が望ましいかもしれません。

ビジネスにおいて高トラフィッククエリに対する低レイテンシー応答が必要となる場合は、一般的に NoSQL システムの活用が技術的および経済的な面で理にかないます。DynamoDB は、リレーショナルシステムの拡張性を制限する問題を回避することによって、それらの問題の解決を助けます。

いつスキャンしていつクエリするのか、および並列スキャンを活用する方法についてのヒントに従ってください。

DynamoDB のグローバルテーブルは、マルチリージョンのマルチマスターデータベースを独自のレプリケーションソリューションを構築して維持することなくデプロイするための完全マネージド型ソリューションを提供します。グローバルテーブルを作成するときに、テーブルを使用できるようにしたい複数の AWS リージョンを指定します。DynamoDB は、これらのリージョンに同一のテーブルを作成して、進行中のデータ変更をそれらすべてに伝播するために必要なタスクのすべてを実行します。

今年は、最高のパフォーマンスと最小コストのためにも DynamoDB のベストプラクティスを守りましょう。DynamoDB のベストプラクティスに関するご質問またはフィードバックがおありの場合は、DynamoDB forum をご覧ください。

著者について

Craig LiebendorferCraig Liebendorfer は、アマゾン ウェブ サービスのシニアテクニカルエディターです。