带有Azure搜索字段的DocumentDB查询

我想执行一个DocumentDB查询，它看起来像SELECT*FROM c，其中c.teams位于（@teamsList）并包含（c.text，“some string”）

问题是上面的查询计算量很大，几乎超过了我们的S3收集限制（此查询耗时2400RU，我们的数据集增长很快，我们很快就会达到包含的扫描限制）

---

我知道Azure搜索是搜索可索引字段更有效的方法。我的问题是如何有效地将Azure搜索结果与其他查询字段合并，在我的示例中，通过团队列表对其进行限制。我们感兴趣的是公开一个“查询生成器”（类似示例可用），其中CONTAINS是任何字段上允许的操作数。

如果要使用DocumentDB进行CONTAINS word搜索并避免扫描（而不是使用Azure搜索），可以执行以下操作：

将

文本

标记为一个单词数组。您可以使用像Lucene.NET这样的现成标记器。假设文本是“这是一个问题”

将单词存储为数组，如

text\u标记

。文本单词的内容是[“this”、“is”、“question”]（规范化为小写，并删除了停止词）

使用ARRAY_CONTAINS（c.text_标记，“word”）查询

text_标记中的值。这将使用索引

---

如果给定查询因超出RU预算而超时，它将返回一个延续令牌，您可以使用该令牌再次返回以获取更多数据。这有用吗？虽然Azure Search在您的CONTAINS子句上会更有效，但我不确定在IN子句上是否会更好/更差。您可能希望为数据集对这两个文档进行基准测试。关于第一个DocumentDB查询，您知道有多少文档与查询中的查询筛选器匹配吗？IN子句将通过索引进行过滤。如果您可以发布活动ID，我们可以调查为什么需要2400 RUs。此外，如果您只需要为查询生成器返回一页结果，您可能可以通过限制默认显示的结果数来显著减少RU。查询从c中选择TOP 100*，其中包含（c.details.title，“test”）返回13个结果，并在Azure门户中使用2409.98 RU。活动id:6d966ad4-a196-4255-a10b-334a753a89e0@LarryMaccherone这可能会起作用，但客户体验会严重退化，因为响应时间会非常长，这是正确的吗？还有一些事情正在发生。2400+RU只有13个结果是疯狂的。让阿拉文调查原因。只有这样，你是否应该考虑我的建议。如果您只需要TOP n，那么使用TOP n是可以的，但是如果您实际上需要它们，但只想显示第一页，那么将maxItemCount设置为页面大小加上一些缓冲区。然后缓存整个集合客户端，一次只显示一个页面。