小売業者の成長のためのリアルタイムでのコマンドをされること

スキーマ設計プロセス

アプリの規模が大きくなるにつれてスキーマとパフォーマンスの問題が生じるのを防ぐには、 健全なデータ モデリング から始めてください。

このソリューションでは、4 つのコア コレクションの周囲の統合データレイヤーをモデル化します。

• products: 製品カタログ（名前、説明、カテゴリ、識別子）。

• inventory: 在庫レベル、再追加データ、予測メトリクス。

• stores:メタデータの保存（名前、場所、運用の詳細）。

• brandAmplification: 店舗ごとのブランド/カテゴリのブースト ルール。

このプロセスに沿って、会社のエンタープライズと増やすを確実に実装します。

1. アプリケーションのワークロードを特定する

   最も頻繁に使用する操作を特定します。

   トップ クエリを使用して、効果的なインデックスを選択し、データベースの呼び出しを減らします。

   ｅコマースと店舗の両方が同じ運用データを消費するとします。

   カスタマー意向をリアルタイムでで返し、チャネル全体で在庫の一貫性を確保します。

   次の表を使用して、リージョン関連付けのワークロードを見積もり、この推定値を読み取り/書込み優先順位のベースラインとして扱います。

   アクション	クエリ タイプ	ターゲット コレクション	頻度	優先順位	ノート
   ストア内の製品検出。カスタマーのリクエストに一致する製品を検索し（テキスト / 意向 / ハイブリッド検索）、このストアに現在在庫があるかどうかを示します。 （50 店舗）	読み取り	Products, inventory	～500K/日	重要です	メインフローを関連付けます。 $lookup を回避するために、各製品に店舗ごとの在庫概要フラグを埋め込みます
   eコマース 検索。仕様、意向、またはハイブリッドで検索（6 K 製品）	読み取り	Products	～1M/日	重要です	オンライン検出をドライバーし、 低レイテンシ を維持する必要があります。専用検索ノードまたは読み取り分離検索ノードを検討してください
   ランキングのための製品ブーストの適用	読み取り	brandAmplification	～300k/日	高	ランキング時に適用される店舗レベルの製品ブースト、製品の更新は必要ありません
   ライブ在庫と予測メトリクス（Ingest）の更新	書込み	inventory	～700k/日	重要です	レコードの在庫システム（店舗および倉庫）からの単一ビュー。小規模で頻繁な書込み
   在庫のある最も近い代替店舗の検索	読み取り	inventory, stores	～100k/日	低	距離順の地理空間ランク
   マーケットプレイス 機能の設定（アップデート ブースト戦略）	書込み	brandAmplification	>500/日	低	任意のカテゴリ スコープを持つ店舗ごとのモデル ブースト。ランタイムは調整可能で、製品の書き換えはありません。

2. スキーマの関係をマッピングする

   識別するワークロードは、スキーマの設計方法に影響します。

   マーケットプレイスでは、関係モデルによって Leafy As associated とｅコマースアプリの読み取りレイテンシが決定され、在庫システムの書込み操作のコストに影響します。

   クエリの最適化

   inventorySummary[]店舗内の商品検出を向上させるには、埋め込みパターンを使用して商品内に を埋め込みます。このアプローチでは、1 回の読み取り操作で製品の詳細と可用性が返され、コストのかかる $lookup 操作が回避されます。このコード スニペットは、products コレクション内の例ドキュメントを示しています。

   { "_id": "685bfe2b3d832cf7e1614577",
     "productName": "Onion",
     "brand": "Fresho",
     "price": { "amount": 31.02, "currency": "USD" },
     "category": "Fruits & Vegetables",
     "subCategory": "Potato, Onion & Tomato",
     "aboutTheProduct": "Onion is a versatile vegetable used in salads and curries.",
     "embeddingText": "Onion | Fresho | 5 kg | Fruits & Vegetables | ...",
     "multimodalEmbeddingVector": [0.03, 0.12, 0.07, "..."],
     "inventorySummary": [
       {
         "storeId": "store-019",
         "sectionId": "S01",
         "aisleId": "I11",
         "shelfId": "SH111",
         "inStock": true,
         "nearToReplenishmentInShelf": false
       },
       {
         "storeId": "store-027",
         "sectionId": "S02",
         "aisleId": "I21",
         "shelfId": "SH213",
         "inStock": true,
         "nearToReplenishmentInShelf": true
       }
     ]
   }

   最適化された運用インベントリのシングルビュー クエリでは、詳細な在庫 データを別のコレクションに保存し、製品を参照。製品ごとに 1 つのドキュメントを保存して、チャネルと店舗全体で単一のビューを維持し、在庫を 1 つの場所で更新します。次のコード スニペットは、inventory コレクション内のドキュメントの例を示しています。

   { "_id": "6863fc8057105b3a8ccb57cd",
     "productId": "685bfe2b3d832cf7e1614577",
     "storeInventory": [
       {
         "storeId": "store-015",
         "storeName": "Trikasemmart - Chiang Mai",
         "coordinates": [98.985583, 18.7929],
         "shelfQuantity": 22,
         "backroomQuantity": 0,
         "inStock": true,
         "predictedStockDepletion": "2025-10-23",
         "nextRestock": "2025-10-19"
       },
       {
         "storeId": "store-006",
         "storeName": "Vinyuvanichkul - Nakhon Ratchasima",
         "coordinates": [102.104829, 14.964336],
         "shelfQuantity": 27,
         "backroomQuantity": 49,
         "inStock": true,
         "nextRestock": "2025-10-21"
       }
     ],
     "updatedAt": "2025-10-17T00:00:01Z"
   }

   利用可能な在庫がある近くの店舗を見つけるには、 GeoJSON ポイント に店舗座標を保存して、地理空間クエリを実行します。次のコード スニペットは、stores コレクション内のドキュメントの例を示しています。

   {
     "_id": "684aa28064ff7c785a568aca",
     "storeId": "store-001",
     "storeName": "Chaihirankarn, Bunlupong and Chomsri - Surat Thani",
     "location": {
       "type": "Point",
       "coordinates": [
         99.317989,
         9.133786
       ],
       "address": "3597 Methavorakul Tunnel Suite 886",
       "city": "Surat Thani"
     },
      …
   }

   データの整合性

   Atlas triggers を使用して、 から必要なフィールドを同期し、inventory products.inventorySummary[]の一貫性を維持します。

   各検索での製品ランキング ルールの最適化

   ランキング時に「」を適用し、ルールを brandAmplification に保存するようにします。製品データを書き換えずに、戦略的コマンドを プロンプトします。

   {
     "_id": "68e43c6865c4a374ea78b4b0",
     "storeId": "store-015",
     "brandName": "Teamonk",
     "categories": ["Beverages", "Gourmet & World Food"],
     "boostLevel": 1,
     "effectiveFrom": "2025-10-01",
     "effectiveTo": "2025-10-31"
   }

3. インデックスの作成

   最も一般的なクエリ フィールドにインデックスを作成します。詳細については、「ソリューションをビルドする」セクションを表示してください。を増やすに応じてインデックスの使用状況を監視および調整します。

アーキテクチャフロー

アーキテクチャ図を表示して、製品を起動するソリューションがどのように動作するかを理解します。

図の 2。このアーキテクチャは、MongoDB の ODL が Leafy 関連アプリケーション、高度な検索マイクロサービス、および投票AI埋め込みを統合する方法を示しています。統合された最新のデータプラットフォームにリアルタイムでの商品構成とカスタマー意向を組み合わせて、単一の集計パイプライン内で全文検索、ベクトル、ハイブリッド検索を実行します。

0. Siloed data

運用データは、多くの場合、ポイント オブジェクト リリース（POS）、エンタープライズ リソース プランニング（ERP）、マーケティングなどのサイロに存在します。それを統合して、一貫したリアルタイムエクスペリエンスを提供します。

1。統合データを MongoDB の運用データ層（ODL）に保存

ODL は MongoDB の 柔軟なドキュメントモデルのフル機能を使用して、構造化データ、半構造化データ、非構造化データを 1 つの場所にまとめて保存します。

最新のデータプラットフォームは、パフォーマンス、 水平スケーラビリティ、高度な機能を提供します。これにより、高速統合、低レイテンシのクエリ、大増やすなリアルタイム操作が可能になります。

この統合アプローチにより、 ｅコマースから店舗内アプリまでのすべてのシステムが、同じ信頼できる最新情報で実行中続けます。

2。店舗関連付けは検索クエリーを入力します

店舗の関連付けは、 Leafy 関連アプリケーションを使用してクエリを入力します。 [ MongoDB Atlas Search ]、全文（ MongoDB Atlas Search ）、意向（ ベクトル検索 ）、またはハイブリッド（ランク 統合、スコア 統合）を選択します。

並行: リアルタイムのブランド展開構成

ストア マネージャーと権限のある担当者は、 Leafy 関連アプリケーション を使用して、バックエンドで使用するために brandAmplificationコレクションに店舗ごとのブースト ルールを作成します。

マーケットプレイスを構成する際に、各カテゴリにある製品の数とその数を示すメタデータをリアルタイムで観察できます。この情報は、 $searchMetaパイプラインステージから取得されます。

3。と 4 Leafy ア関連付けはAPIリクエストをビルドします

Leafy 関連アプリケーションは、完全なコンテキストを持つ検索リクエストを作成します。フロントエンドでランタイム パラメータを直接構築し、 MongoDBからそのストアのアクティブなブランド構成を検索します。 Advanced Search マイクロサービスにリクエストを送信します。

POST /api/v2/search
{ "query": "green tea skin care",
  "storeObjectId": "684aa28064ff7c785a568aca",
  "option": 4,
  "page": 1,
  "page_size": 20,
  "weightVector": 0.5,
  "weightText": 0.5,
  "fusionMode": "rrf",// you can also use "scoreFusion"
   "brandAmplification": [
    { "name": "Innisfree", "boostLevel": 1 },
    { "name": "Olay", "boostLevel": 2, "categories": ["Face Care", "Skincare"] },
    { "name": "The Body Shop", "boostLevel": 3 }
  ]
}

5。投票AIによる埋め込みサービス

検索タイプがベクトルまたはハイブリッド検索の場合、マイクロサービスは 投票AIを使用してカスタマークエリ埋め込みを生成します。

6。と 7 Advanced Search マイクロサービスが集計パイプラインを構築

Advanced Search マイクロサービスは実行時に集計パイプラインをビルドし、 MongoDB内で実行します。このマイクロサービスは、単一のパイプラインと単一のラウンドトリップを使用して、パフォーマンスと効率 を向上させます。

$search を使用してテキスト関連性を高めるために、パイプラインは must、should 、filter 句とファジー一致とフィールドのブーストを組み合わせた複合構造を適用し、結果を絞り込みます。

$vectorSearch を使用するセマンティックの目的で、パイプラインはカスタマークエリを製品データの事前計算された埋め込みと比較します。

ハイブリッド検索では、マイクロサービスはテキストとベクトルの結果を統合します。これはランクベースのレプリカ ランク統合（RRIF）を適用する $rankFsion 、または実行時に調整可能な重みと正規化されたスコアを組み合わせた $scoreField を使用します。

MongoDB Atlas は、2 つの補完的なパスを通じて結果の関連性を向上させます。

1. 統合テキスト ブースト（ $search 内）

   複合ルールとして入力します。 shouldとscore 句。各モデルと （任意）カテゴリのブーストが表示されます。

2. $set + $multiply を使用した後統合乗算

マイクロサービスは、上位の を$filterで直接フィルタリングすることで、$lookupを使用して他のコレクションをマージすることなくストアコンテキストを維持します。最後に、 Products.inventorySummary[]$ファセットによってUI対応の 応答が生成され、結果のドキュメントと合計数の両方が返されます。

8。信頼性、スケーラビリティ、セキュリティ、リアルタイム整合性

MongoDB はレプリカセット によって高可用性を維持し、シャーディングによって水平方向にスケーリングします。低レイテンシ読み取りには専用の検索ノードを使用します。 Change Streams と Atlas Triggers を使用して、データの一貫性をリアルタイムで維持します。 MongoDB は、組み込みのアクセス制御、 ネットワーク分離、および保管中、転送中、使用中のデータ全体の暗号化により、包括的なエンドツーエンドのセキュリティを提供します。