データを埋め込む場合または参照する場合
前のユニットでは、顧客の住所とパスワードのデータを新しい顧客ドキュメントに埋め込みました。 そのアクションによって、要求数が減り、パフォーマンスが向上し、コストが削減されます。 ただし、常にデータを埋め込めるわけではありません。 データをドキュメントに埋め込む方がよい場合と、別の行で参照する方がよい場合については、規則があります。
データを埋め込む方がよい場合
次の条件に当てはまるデータの場合は、データをドキュメントに埋め込んでください。
- 一緒に読み取られるまたは更新される: 一緒に読み取られたり更新されたりするデータは、ほぼ常に 1 つのドキュメントとしてモデリングされます。 これにより、効率化の目的である要求数の削減を実現します。 今回のシナリオでは、すべての顧客エンティティが一緒に読み書きされています。
- 1 対 1 のリレーションシップ: たとえば、Customer と CustomerPassword には 1 対 1 のリレーションシップがあります。
- 1 対少数のリレーションシップ: NoSQL データベースの場合、1 対多リレーションシップを上限ありか上限なしかで区別する必要があります。 Customer と CustomerAddress には上限ありの 1 対多のリレーションシップがあります。なぜなら、eコマース アプリケーションの顧客は、通常、出荷先の住所が少数だからです。 リレーションシップが上限ありの場合、これは 1 対少数のリレーションシップです。
データを参照する方がよい場合
次の条件に当てはまるデータの場合は、データを別のドキュメントとして参照してください。
独立した読み取りまたは更新: これは特に、エンティティを組み合わせると大きなドキュメントになる場合に当てはまります。 Azure Cosmos DB の更新には、項目全体を置き換える必要があります。 頻繁に更新されるいくつかのプロパティと、ほとんど静的な多数のプロパティがドキュメントにある場合、ドキュメントを 2 つに分割する方がはるかに効率的です。 そのため、1 つのドキュメントには、頻繁に更新されるプロパティの小さなセットが含まれています。 もう 1 つのドキュメントには、静的で不変の値が含まれています。
1 対多のリレーションシップ: これは特に、リレーションシップが上限なしの場合に当てはまります。 未知または無制限にサイズが増加するドキュメントがある場合、それらの更新にかかるコストと待ち時間は増加し続けることになります。 これは、更新プログラムのサイズが大きくなると、RU/s のコストが増加し、ネットワーク上を通過するペイロードそれ自体も非効率的になるためです。
多対多のリレーションシップ: このリレーションシップの例については、製品タグを使用する後のユニットで説明します。
これらのプロパティを分離することで、スループットの消費が抑えられるため、効率が高まります。 また、待機時間が減るので、パフォーマンスが向上します。