翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
Amazon Keyspaces などの NoSQL データベースシステムでは、キーと値のペアやドキュメントストレージなど、データ管理に代替モデルを使用します。リレーショナルデータベース管理システム (RDBMS) から Amazon Keyspaces のような NoSQL データベースシステムに切り替えるときは、他のシステムとの主な違いと独自の設計アプローチを理解することが重要です。
リレーショナルデータ設計と NoSQL の相違点
リレーショナルデータベースシステム (RDBMS) と NoSQL データベースにはそれぞれ異なる長所と短所があります。
-
RDBMS では、データは柔軟にクエリできますが、クエリは比較的コストが高く、トラフィックが多い状況ではスケールがうまくいかない場合があります (データモデリングのベストプラクティス: データモデル設計時の推奨事項 参照)。
-
一方、Amazon Keyspaces のような NoSQL データベースでは、一定の方式では、データを効率的にクエリできますが、それ以外の方式では、クエリのコストが高くなり、処理速度が遅くなりがちです。
これらの相違点により、2 つのシステム間でデータベース設計が異なるものになります。
-
RDBMS では、実装の詳細やパフォーマンスを気にせずに柔軟に設計できます。クエリの最適化は一般的にスキーマ設計には影響しませんが、正規化は重要です。
-
Amazon Keyspaces では、最も一般的で重要なクエリをできるだけ速く、経済的に処理するために、具体的にスキーマを設計します。データ構造は、ビジネスユースケースの特定の要件に合わせて調整されています。
NoSQL 設計の 2 つの重要な概念
NoSQL 設計では、RDBMS 設計とは異なる考え方が必要です。RDBMS の場合は、アクセスパターンを考慮せずに正規化されたデータモデルを作成できます。その後、新しい課題とクエリの要件が発生したら、そのデータモデルを拡張することができます。各タイプのデータを独自のテーブルに整理できます。
NoSQL の設計の違い
-
Amazon Keyspaces の場合は対照的に、答えが必要な疑問点が分かるまで、スキーマの設計を開始しないでください。ビジネス上の問題とアプリケーションのユースケースを理解することが不可欠です。
-
Amazon Keyspaces アプリケーションでは、できるだけ少ないテーブルで済ませる必要があります。テーブルの数が少なければ、スケーラビリティが向上し、必要な権限の管理業務が減少し、Amazon Keyspaces アプリケーションのオーバーヘッドが削減されます。また、バックアップコストを全体的に低く抑えるのにも役立ちます。
NoSQL 設計へのアプローチ
Amazon Keyspaces アプリケーション設計の最初のステップでは、システムで対応すべき具体的なクエリパターンを見極めます。
始める前に、特にアプリケーションのアクセスパターンの 3 つの基本的な特性を理解することが重要です。
-
データサイズ: 一度に収容されて、リクエストされるデータの量を把握できれば、最も効果的なデータパーティションの方式を決定できます。
-
データシェイプ: クエリが処理される際 (RDBMS システムのように) データを再形成するのではなく、データベースの形状がクエリ処理に対応するように、NoSQL データベースでデータを整理します。これは、スピードとスケーラビリティを向上させる重要な要素です。
-
データ速度: Amazon Keyspaces では、クエリ処理に使用できる物理パーティションの数を増やし、それらのパーティション間で効率的にデータを分散させてスケーリングします。ピーク時のクエリのロードを事前に把握することは、I/O キャパシティを最大限に活用するためにデータを分割する方法を決定する上で役立ちます。
特定のクエリ要件を特定したら、パフォーマンスを管理する一般的な原則に従ってデータを整理できます。
-
関連データをまとめて保存します。 20 年前のルーティングテーブルの最適化に関する研究では、関連するデータをまとめて 1 つの場所にまとめておく「参照の局所性」が、応答時間を短縮する上で最も重要な要素であることがわかりました。これは、今日の NoSQL システムにも同様に当てはまります。関連するデータを近くに置くことはコストとパフォーマンスに大きな影響を与えます。関連するデータ項目を複数のテーブルに分散するのではなく、NoSQL システム内の関連項目を可能な限り近くにまとめる必要があります。
原則として、Amazon Keyspaces アプリケーションではできるだけテーブル数を少なくする必要があります。
例外として、大キャパシティの時系列データが必要な場合や、データセットのアクセスパターンが大きく異なる場合などがあります。反転されたインデックスを含む単一のテーブルでは通常、シンプルなクエリを使用してアプリケーションで必要とされる複雑な階層データ構造を構築および取得できます。
-
ソート順を使用します。 キーの設計が原因でソートされている場合は、関連項目をグループ化して、効率的にクエリできます。これは重要な NoSQL 設計方法です。
-
クエリを分散します。 大キャパシティのクエリがデータベースの一部に集中しないことも重要です。I/O キャパシティを超えるおそれがあります。その代わり、「ホットスポット」を避け、できるだけ多くのパーティションにトラフィックを均等に分散するように、データキーを設計する必要があります。
このような一般原則は、Amazon Keyspaces でデータを効率的にモデル化するための一般的なデザインパターンに書き換えられます。