# DynamoDB 用の NoSQL
<a name="bp-general-nosql-design"></a>

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

**Topics**
+ [リレーショナルデータ設計と NoSQL の相違点](#bp-general-nosql-design-vs-relational)
+ [NoSQL 設計の 2 つの重要な概念](#bp-general-nosql-design-concepts)
+ [NoSQL 設計へのアプローチ](#bp-general-nosql-design-approach)
+ [DynamoDB 用の NoSQL Workbench](#bp-general-nosql-workbench)

## リレーショナルデータ設計と NoSQL の相違点
<a name="bp-general-nosql-design-vs-relational"></a>

リレーショナルデータベースシステム (RDBMS) と NoSQL データベースにはそれぞれ異なる長所と短所があります。
+ RDBMS では、データは柔軟にクエリできますが、クエリは比較的コストが高く、トラフィックが多い状況ではスケールがうまくいかない場合があります ([DynamoDB でリレーショナルデータをモデル化するための最初のステップ](bp-modeling-nosql.md) 参照)。
+ 一方、DynamoDB のような NoSQL データベースでは、データは限られた数の方法で効率的にクエリできますが、その範囲外では、クエリは高コストで低速になりがちです。

これらの相違点により、2 つのシステム間でデータベース設計が異なるものになります。
+ RDBMS では、実装の詳細やパフォーマンスを気にせずに柔軟に設計できます。クエリの最適化は一般的にスキーマ設計には影響しませんが、正規化は重要です。
+ DynamoDB では、最も一般的で重要なクエリをできるだけ速く、安価にするために、具体的にスキーマを設計します。データ構造は、ビジネスユースケースの特定の要件に合わせて調整されています。

## NoSQL 設計の 2 つの重要な概念
<a name="bp-general-nosql-design-concepts"></a>

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

**NoSQL の設計の違い**
+ 対照的に、DynamoDB の場合は答えが必要な質問が分かるまで、スキーマの設計を開始すべきではありません。ビジネス上の問題とアプリケーションのユースケースを理解することが不可欠です。
+ DynamoDB アプリケーションで維持するテーブルはできるだけ少なくする必要があります。テーブルの数が少なくなると、スケーラビリティが向上し、必要なアクセス権限の管理が少なくなり、DynamoDB アプリケーションのオーバーヘッドが削減されます。また、バックアップコストを全体的に低く抑えるのにも役立ちます。

## NoSQL 設計へのアプローチ
<a name="bp-general-nosql-design-approach"></a>

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

始める前に、特にアプリケーションのアクセスパターンの 3 つの基本的な特性を理解することが重要です。
+ **データサイズ**: 一度に格納され、リクエストされるデータの量を把握することで、データパーティションの最も効果的な方法を決定できます。
+ **データシェイプ**: クエリが処理される際 (RDBMS システムのように) データを再形成するのではなく、データベースの形状がクエリ処理に対応するように、NoSQL データベースでデータを整理します。これは、スピードとスケーラビリティを向上させる重要な要素です。
+ **データ速度**: DynamoDB では、クエリを処理するために使用可能な物理パーティションの数を増やし、それらのパーティション間で効率的にデータを分散させることでスケーリングします。ピーク時のクエリのロードを事前に把握することは、I/O 容量を最大限に活用するためにデータを分割する方法を決定する上で役立ちます。

特定のクエリ要件を特定したら、パフォーマンスを管理する一般的な原則に従ってデータを整理できます。
+ **関連データをまとめて保存します。**   調査により、関連データを 1 か所にまとめて保存する「参照の局所性」の原則は、NoSQL システムのパフォーマンスと応答時間を向上させる重要な要素であることが判明しています。これは、何年も前にルーティングテーブルを最適化するために重要であることが判明したのと同じです。

  一般的なルールとして、DynamoDB アプリケーションでは維持するテーブルをできるだけ少なくする必要があります。

  例外として、大キャパシティの時系列データが必要な場合や、データセットのアクセスパターンが大きく異なる場合などがあります。反転されたインデックスを含む単一のテーブルでは通常、シンプルなクエリを使用してアプリケーションで必要とされる複雑な階層データ構造を構築および取得できます。
+ **ソート順を使用します。**   キーの設計が原因でソートされている場合は、関連項目をグループ化して、効率的にクエリできます。これは重要な NoSQL 設計方法です。
+ **クエリを分散します。**   大量のクエリがデータベースの一部に集中しないことも重要です。集中すると、I/O キャパシティを超えるおそれがあります。代わりに、パーティション間でトラフィックをできるだけ均等に分散するようにデータキーを設計し、ホットスポットを避ける必要があります。
+ **グローバルセカンダリインデックスを使用します。**   特定のグローバルセカンダリインデックスを作成することで、メインテーブルでサポートできるクエリとは異なるクエリを有効にすることができ、このクエリは高速で比較的安価です。

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

## DynamoDB 用の NoSQL Workbench
<a name="bp-general-nosql-workbench"></a>

 [DynamoDB 用の NoSQL Workbench](workbench.md) は、最新のデータベース開発および運用で使用できるクロスプラットフォームのクライアント側 GUI アプリケーションです。Windows、macOS、Linux で使用できます。NoSQL Workbench は、DynamoDB テーブルの設計、作成、クエリ、管理に役立つデータモデリング、データ可視化、サンプルデータ生成、クエリ開発といった特徴を提供する視覚的開発ツールです。DynamoDB 用の NoSQL Workbench を使用すると、アプリケーションのデータアクセスパターンを満たす既存のデータモデルから新しいデータモデルを構築したり、既存のデータモデルに基づいてモデルを設計したりできます。プロセスの最後に、設計されたデータモデルをインポートおよびエクスポートすることもできます。詳細については、「[NoSQL Workbench を使用したデータモデルの構築](workbench.Modeler.md)」を参照してください。