c# - Azure 搜索的文档设计

Question

关闭。这个问题是opinion-based .它目前不接受答案。












想改进这个问题？更新问题，以便 editing this post 可以用事实和引用来回答它.

4年前关闭。




Improve this question




我发帖是想看看是否有人有解决方案，或者可以提供一些关于建模某些数据的指导，以便在 azure 搜索中使用。

问题域

我目前正在使用 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 结束日期重叠的坐标附近的所有实体 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 文档拆分为两个集合

新的 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，一个用于位置，然后加入结果？

我认为这是 Multi-Tenancy 搜索
https://docs.microsoft.com/en-us/azure/search/search-modeling-multitenant-saas-applications

有谁知道实现这个的例子？

优点

认为它会起作用

缺点

每个查询都需要两次搜索命中，然后合并结果(这可能是理想的，也可能不是理想的)。

或

最好完全“反转”实体 A 和位置实体，即类似

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

优点

已经很平坦了，应该很容易索引和查询

一搜不合

缺点

对于名称、描述、标签等，需要多次更新
如果这些改变。

将获得相同“实体 A”的多个结果
如果日期跨越多个开始和结束日期

或

还有其他选择吗？

谢谢，如果需要，我很乐意澄清

Answer 1

我倾向于你的第二个完全扁平或倒置的选项

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

我对此的主要论点是分页。如果您有两次搜索，并且希望在一个页面上返回 10 个结果，那么每次搜索您要求多少个结果，更重要的是，您从哪里开始搜索第 2 页？

也存在对结果进行排名的问题，但这些问题比分页更易于管理。