外側のパターンでデータをグループ化する

始める前に

アウトバウンドを処理するようにスキーマを変更する前に、アウトバウンド パターンの長所と懸念事項を検討してください。

このタスクについて

書籍の売上を追跡するスキーマを考えてみましょう。 コレクション内の通常のドキュメントは次のようになります。

db.sales.insertOne(
   {
      "_id": 1,
      "title": "Invisible Cities",
      "year": 1972,
      "author": "Italo Calvino",
      "customers_purchased": [ "user00", "user01", "user02" ]
   }
)

customers_purchased配列は無制限であるため、書籍を購入する顧客が多いほど配列は大きくなります。 ほとんどのドキュメントでは、店舗では特定の書籍の数倍の売上が予想されているため、問題にはなりません。

新しい人気の書籍が大量に購入されるとします。 現在のスキーマ設計ではドキュメントが肥大化し、パフォーマンスに悪影響が生じます。 この問題に対処するには、通常の販売額がないドキュメントに対して 外側のパターン を実装します。

手順

db.sales.insertOne(
   {
      "_id": 2,
      "title": "The Wooden Amulet",
      "year": 2023,
      "author": "Lesley Moreno",
      "customers_purchased": [ "user00", "user01", "user02", ... "user49" ],
      "has_extras": true
   }
)

db.extra_sales.insertOne(
   {
      "book_id": 2,
      "customers_purchased_extra": [ "user50", "user51", "user52", ... "user999" ]
   }
)

結果

The outlier pattern prevents atypical documents from impacting query performance. 結果として得られるスキーマは、販売の完全なリストを維持しながら、 コレクション内の大きなドキュメントを回避します。

書籍とその書籍を購入したすべてのユーザーに関する情報を表示するアプリケーション ページを考えてみましょう。 外側のパターンを実装すると、ページにはほとんどの書籍（一般的なドキュメント）の情報がすばやく表示されます。

一般的な書籍（アウトバウンド）の場合、アプリケーションはbook_idのextra_salesコレクションで追加のクエリを実行します。 このクエリのパフォーマンスを向上させるには、 book_idフィールドにインデックスを作成します。

詳細

• バケット パターンでデータをグループ化する

• 無制限の配列を避ける

• 埋め込みデータと参照の比較

• モデル計算データ