在 Edm.Int32 和 Collection(Edm.String) 上的 Azure 搜索过滤性能答案

【问题标题】：Azure search filtering performance over Edm.Int32 and Collection(Edm.String)在 Edm.Int32 和 Collection(Edm.String) 上的 Azure 搜索过滤性能
【发布时间】：2017-03-30 05:42:53
【问题描述】：

我在我的电子商务网站上使用 Azure 搜索，现在想要实施过滤。

我遇到了性能问题。我有产品索引。每个产品都属于类别。每个类别都可以有嵌套的子类别。我的业务目的是当客户在类别页面上时，我什至需要从子类别中显示产品，所以我对如何将这种关系（产品到类别）存储在 azure 产品索引中存在疑问。我正在考虑两种可能性：

我只能在 Edm.Int32 类型的字段中存储产品类别 ID。然后，当客户转到此类别时，我查询我的 sql 服务器以获取所有子类别 id，然后构造我的查询以像这样进行索引

categoryId eq 34 或 categoryId eq 36 或 categoryId eq 37 ...

其他方法是创建类型为 Collection(Edm.String) 的字段并将产品类别 ID 和嵌套类别 ID 存储在此字段中，然后我的索引查询将如下所示

categoryIds/any(c: c eq '35')

那么哪种方式会更快？

【问题讨论】：

您在选项 #1 中提到查询 SQL Server。对于选项 #2，您是否也必须这样做？
是的，但这不是重点。我写这个只是为了举例。我可以将类别 id 存储在本地缓存中，因此获取类别 id 或带有子类别 id 的类别 id 不会是性能问题。
谢谢。在尝试回答您的问题之前，我只是想澄清这一点。

标签： azure faceted-search azure-cognitive-search

【解决方案1】：

选项 #2 可能更快，因为索引中的文档数量会少得多，但唯一可以确定的方法是对您的数据和查询进行一些实验。整体查询性能将取决于其他因素，例如您是否在进行全文搜索、分面、地理空间等。

【讨论】：

谢谢。我做了一些测试，结论是这两个选项大约需要相同的时间，大约是 300 毫秒。我没有注意到有很大的不同。
这是有道理的。您的查询的可能过滤器执行是最好的情况，并且与被索引的唯一术语的数量而不是文档的数量成线性关系。