Amazon DynamoDB
開発者ガイド (API バージョン 2012-08-10)

DynamoDB に合わせた NoSQL 設計

NoSQL データベースシステム (例: Amazon DynamoDB) では、キーと値のペアやドキュメントストレージなど、データ管理のための代替モデルを使用します。 リレーショナルデータベース管理システム (RDBMS) から DynamoDB のような NoSQL データベースシステムに切り替えるときは、主な相違点と特定の設計アプローチを理解することが重要です。

リレーショナルデータ設計と NoSQL の相違点

リレーショナルデータベースシステム (RDBMS) と NoSQL データベースにはそれぞれ異なる長所と短所があります。

  • RDBMS では、データは柔軟にクエリできますが、クエリは比較的コストが高く、トラフィックが多い状況ではスケールがうまくいかない場合があります (DynamoDB でリレーショナルデータをモデル化するための最初のステップ 参照)。

  • 一方、NoSQL データベース (例: DynamoDB) では、データは限られた数の方法で効率的にクエリできますが、その範囲外では、クエリは高コストで低速になりがちです。

これらの相違点により、2 つのシステム間でデータベース設計が非常に異なるものになります。

  • RDBMS では、実装の詳細やパフォーマンスを気にせずに柔軟に設計できます。クエリの最適化は一般的にスキーマ設計には影響しませんが、正規化は非常に重要です。

  • DynamoDB では、最も一般的で重要なクエリをできるだけ速く、安価にするために、具体的にスキーマを設計します。データ構造は、ビジネスユースケースの特定の要件に合わせて調整されています。

NoSQL 設計の 2 つの重要な概念。

NoSQL 設計では、RDBMS 設計とは異なる考え方が必要です。RDBMS の場合は、アクセスパターンを考慮せずに正規化されたデータモデルを作成できます。その後、新しい質問とクエリの要件が発生したら、そのデータモデルを拡張することができます。各タイプのデータを独自のテーブルに整理できます。

NoSQL 設計は異なります。

  • DynamoDB の場合は対照的に、答えが必要な質問が分かるまで、スキーマの設計を開始しないでください。ビジネス上の問題とアプリケーションのユースケースを理解することが不可欠です。

  • DynamoDB アプリケーションではできるだけ少ないテーブルを維持する必要があります。設計が優れたアプリケーションでは、必要なテーブルは 1 つのみです。

NoSQL 設計へのアプローチ

DynamoDB アプリケーションを設計する最初のステップは、システムが満たす必要がある特定のクエリパターンを見極めることです。

特に、始める前に、アプリケーションのアクセスパターンの 3 つの基本的な特性を理解することが重要です。

  • データサイズ: 一度に格納され、リクエストされるデータの量を把握することは、データを分割する最も効果的な方法を決定するのに役立ちます。

  • データシェイプ: クエリが処理される際 (RDBMS システムのように) データを再形成するのではなく、NoSQL データベースでデータを整理することで、データベース内の形状が、クエリされるものと一致するようにします。これは、スピードとスケーラビリティを向上させる重要な要素です。

  • データ速度: DynamoDB では、クエリを処理するために使用可能な物理パーティションの数を増やし、それらのパーティション間で効率的にデータを分散させることでスケーリングします。ピーク時のクエリの負荷を事前に把握することは、I/O キャパシティーを最大限に活用するためにデータを分割する方法を決定する上で役立ちます。

特定のクエリ要件を特定したら、パフォーマンスを管理する一般的な原則に従ってデータを整理できます。

  • 関連するデータをまとめてください。 20 年前のルーティングテーブルの最適化に関する研究では、関連するデータをまとめて 1 つの場所にまとめておく「参照の局所性」が、応答時間を短縮する上で最も重要な要素であることが分かりました。これは、今日の NoSQL システムにも同様に当てはまります。関連するデータを近くに置くことはコストとパフォーマンスに大きな影響を与えます。関連するデータ項目を複数のテーブルに分散するのではなく、NoSQL システム内の関連項目を可能な限り近くにまとめる必要があります。

    一般的なルールとして、DynamoDB アプリケーションはできるだけ少ないテーブルを維持する必要があります。先に強調したように、複数のテーブルを使用する特定の理由がない限り、優れた設計のアプリケーションで必要なテーブルは 1 つのみです。

    例外には、大容量の時系列データが必要な場合や、データセットのアクセスパターンが非常に異なる場合などがあります。ただし、これらは例外です。反転されたインデックスを含む単一のテーブルでは通常、シンプルなクエリを使用してアプリケーションで必要とされる複雑な階層データ構造を作成および取得できます。

  • ソート順を使用します。 キーの設計が原因でソートされている場合は、関連項目をグループ化して、効率的にクエリできます。これは重要な NoSQL 設計戦略です。

  • クエリを分散します。大容量のクエリがデータベースの一部に集中しないようにすることも重要です。ここでは、I/O キャパシティーを超えることができます。その代わり、「ホットスポット」を避け、できるだけ多くのパーティションにトラフィックを均等に分散するように、データキーを設計する必要があります。

  • グローバルセカンダリインデックスを使用します。 特定のグローバルセカンダリインデックスを作成することで、メインテーブルでサポートできるクエリとは異なるクエリを有効にすることができます。これは、まだ高速で比較的安価です。

このような一般原則は、DynamoDB でデータを効率的にモデル化するために使用できる一般的なデザインパターンに変換されます。