2

誰かが解決策を持っているかどうか、またはAzure Searchで使用するために一部のデータをモデル化するためのガイダンスを提供できるかどうかを確認するために投稿しています。

問題のドメイン

現在 DocumentDB を使用して、検索したいデータをモデル化しています。現時点で「エンティティ A」と​​呼ぶ私のドキュメントは次のようになります。

{
 _id,                          //key - Guid
 name,                         //searchable - String
 description,                  //searchable - String
 tags: [ "T1", "T2", ...]      //facet - Collection(String)
 locations: [
   {
      coordinate,              //filter - GeoLocation (lat & long)
      startDateTime,           //filter - DateTimeOffset
      endDateTime              //filter - DateTimeOffset
   },
   ...
  ]
 ...
},
...

関係: タグ 0...n エンティティ A & 場所 0...n エンティティ A

エンティティ A をフラット化し、タグの名前、説明、ファセットの単純なインデックスとクエリを設定することは問題なく、うまく機能します。

問題は、場所をインデックスに追加しようとすることにあります。事実上、私が検索したいのは（自然言語で）次のとおりです。特定の用語について、x開始日とy終了日と重なる座標の近くにあるすべてのEntity Asを見つけます

私がオンラインで見つけることができるものから-場所を平坦化することは、それらが文字列になる場合にのみ機能します。

https://blogs.msdn.microsoft.com/kaevans/2015/03/09/indexing-documentdb-with-azure-seach/ https://docs.microsoft.com/en-us/azure/search/search- howto-index-json-blobs

これは、ジオディスタンスと日付範囲のクエリを実行できる能力を失っているようです。

現在の考え

エンティティ A ドキュメントを 2 つのコレクションに分割する

新しいエンティティ A のドキュメント:

   {
     _id,                          //key - Guid
     name,                         //searchable - String
     description,                  //searchable - String
     tags: [ "T1", "T2", ...]      //facet - Collection(String)
     ...
    },

および複数のロケーション エンティティ

{
  _id,
  documentId,                     //relates to Document._id
  coordinate,
  startDate,
  endDate
}

質問:

新しいエンティティ A 用と場所用の 2 つのインデックスを作成し、結果を結合した方がよいでしょうか?

これはマルチテナント検索だと思い ます https://docs.microsoft.com/en-us/azure/search/search-modeling-multitenant-saas-applications

これを実装する例を知っている人はいますか?

長所

  • うまくいくと思う

短所

  • クエリごとに 2 つの検索ヒットが必要になり、結果をマージする必要があります (これは理想的である場合とそうでない場合があります)。

また

エンティティ A とロケーション エンティティを完全に「反転」することをお勧めします。

{
  _id,
  documentDBId,                     //relates to Document._id
  coordinate,
  startDate,
  endDate,
  name,
  description,
  tags: []
  ...
}

長所

  • すでにかなりフラットなので、インデックスとクエリが簡単になるはずです
  • 1 回の検索ヒットでマージなし

短所

  • 名前、説明、タグなどが変更された場合、複数の更新が必要になります。
  • 日付が複数の開始日と終了日にまたがる場合、同じ「エンティティ A」に対して複数の結果が得られます

また

別のオプションはありますか？

ありがとうございます。必要に応じて明確にさせていただきます

4

1 に答える 1

0

私はあなたの2番目の完全に平らなまたは反転したオプションに傾倒します

{
  _id,
  documentDBId,                     //relates to Document._id
  coordinate,
  startDate,
  endDate,
  name,
  description,
  tags: []
  ...
}

これに対する私の主な議論はページングです。2 つの検索があり、1 ページに 10 件の結果を返したい場合、各検索でいくつの結果を求めますか? さらに重要なことに、2 ページ目の検索はどこから開始しますか?

結果のランク付けの問題もありますが、それらはページングよりも扱いやすいものです。

于 2017-02-14T16:41:37.240 に答える