web-dev-qa-db-ja.com

頻繁に更新されるフィールドでAzureを使用してデータを格納、インデックス付け、検索する。複数のソース

マルチベンダーマーケットプレイス(eコマース)システムがあり、データ構造をポリグロットアーキテクチャに移動して、読み取り(クリティカル)と書き込み(クリティカルではない)のパフォーマンスを向上させる予定です。

複数のディーラーが製品にオファーを出します。ローカルオファーとオンラインオファーがあり、デフォルトのオファー(結果に最初に表示される)が最も安いオンラインオファーです。

Request types

したがって、図に示すように、通常は2種類のリクエストがあります。 1つはリスト(検索結果)、もう1つはすべてのオファー(ローカルおよびすべて/オンライン)の詳細ビューです。

エンティティの関係:

  • 1オファーには1製品があります
  • 1製品にはN個のオファーがあります
  • 1つのオファーに1つのディーラーがあります
  • 1ディーラーはNオファーを持っています

製品情報はめったに変更されないので、私のアイデアはCosmos Document Storageに製品情報を保存することです。製品エンティティには、キーと値のペアとして検索フィルター(特性)があります。

これがオファーの単純化されたJSONです。

{
 "offerNumber": 1234,
 "dealerId": 1000,
 "price": 19.99,
 "quantity": 5,
 "product" : {
  "title": "My Title",
  "filters": 
  [
   { "key": "value" },
   { "key": "value" }
  ],
  "description": ""
 }
}

モデルに表示されるように、オファーには通常、在庫(数量)と価格があります。私の最初のアプローチは、最も安いオンラインオファーをドキュメントデータベースに格納し、他のすべてのオファーをリレーショナルデータベース(Azure SQL)に格納することでした。

株式と価格の情報は頻繁に変化するため、ドキュメントデータベースは更新用に最適化されていないため、オファーにはリレーショナルデータベースが適しています。製品の場合、頻繁に変更されないため、ドキュメントデータベースの方が適しています。

私の懸念は、株価と価格に加えられた更新の量です。両方のソースを使用して検索インデックスを最適化する方法はありますか?または、Azureで同様のユースケースとさまざまなストレージタイプの経験がある人はいますか?

1
Michael Staples

Azure Searchの標準インデクサーは、この複雑なデータ構造をサポートして、プルアプローチでインデックスを構築できません。構造:1文書データベースの製品n SQLデータベースで提供。より単純な構造の場合、私はこの例を見つけました: https://docs.Microsoft.com/en-us/Azure/search/tutorial-multiple-data-sources これは、コレクションが次のように保存されている場合に正常に動作しますソース内のコレクション。 SQLに関しては、クエリ結果自体はラップされずにコレクションを返しますが、プルを使用した自動マージは失敗します。

Azure Searchは、プッシュとプルの2種類のデータ取り込みをサポートしています。記載されている問題のため、プルアプローチはオプションではないため、データ集約を処理し、それをインデックスにプッシュするためのレイヤー(Webジョブまたは関数)を追加しました。ドキュメントに従って https://docs.Microsoft.com/en-us/Azure/search/search-what-is-data-import

Webjob

マイクロソフト、ありがとうございます。優れたサポートを提供して、可能なオプションを詳細に確認していただきました。

小売シナリオに関連するその他のユースケースについては、ここから始めるのが良いでしょう: https://github.com/AzureCosmosDB/scenario-based-labs/blob/master/Retail/HOL%20step-by-step% 20-%20Cosmos%20DB%20scenario-based%20labs%20-%20Retail.md

0
Michael Staples