設計なしSQLの主な違いと設計原則

Amazon Keyspaces のようなデータベースシステムでは、キーと値のペアやドキュメントストレージなどのデータ管理に代替モデルを使用しませんSQL。リレーショナルデータベース管理システムから Amazon Keyspaces SQLなどのデータベースシステムを使用しないに切り替える場合は、主な違いと特定の設計アプローチを理解することが重要です。

リレーショナルデータ設計と No の違いSQL

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

• ではRDBMS、データは柔軟にクエリできますが、クエリは比較的高価で、トラフィックの多い状況ではうまくスケーリングされません (「」を参照データモデリングのベストプラクティス: データモデルの設計に関する推奨事項）。

• Amazon Keyspaces などの NoSQL データベースでは、限られた数の方法でデータを効率的にクエリできますが、その外部ではクエリが高価で低速になる可能性があります。

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

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

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

設計なしの 2 SQLつの重要な概念

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

設計の相違点SQL

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

• Amazon Keyspaces アプリケーションでは、できるだけ少ないテーブルで済ませる必要があります。テーブルの数が少なければ、スケーラビリティが向上し、必要な権限の管理業務が減少し、Amazon Keyspaces アプリケーションのオーバーヘッドが削減されます。また、バックアップコストを全体的に低く抑えるのにも役立ちます。

設計なしSQLに近づく

Amazon Keyspaces アプリケーション設計の最初のステップでは、システムで対応すべき具体的なクエリパターンを見極めます。

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

• データサイズ: 一度に収容されて、リクエストされるデータの量を把握できれば、最も効果的なデータパーティションの方式を決定できます。

• データシェイプ : クエリが処理されたときに (RDBMSシステムと同様に) データを再形成する代わりに、データベースなしはSQLデータを整理して、データベース内のシェイプがクエリ対象に対応するようにします。これは、スピードとスケーラビリティを向上させる重要な要素です。

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

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

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

  原則として、Amazon Keyspaces アプリケーションではできるだけテーブル数を少なくする必要があります。

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

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

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

このような一般原則は、Amazon Keyspaces でデータを効率的にモデル化するための一般的なデザインパターンに書き換えられます。