google-app-engine - Number Found 准确性影响游标结果的搜索 API

Question

当使用 google app engine 搜索 API 时，如果我们有一个返回大型结果集(>1000)的查询，并且需要使用游标进行迭代以收集整个结果集，我们将得到不确定的文档结果如果 number_found_accuracy 低于我们的结果大小，则返回。

换句话说，同一查询运行两次，通过游标收集所有文档，不会返回相同的文档，除非我们的 number_found_accuracy 高于结果大小(例如，使用 10000 最大值)。只有这样，我们才能始终获得相同的文档。

我们对 number_found_accuracy 应该如何工作的理解是它只会影响 number_found 估计。我们假设如果您使用游标获取所有结果，您将能够获得与运行一个大型查询相同的结果。

我们是否误解了 number_found_accuracy 或游标的使用，或者我们发现了错误？

Answer 1

您对 number_found_accuracy 的理解是正确的。我认为您观察到的行为是复制查询故障转移与指定 number_found_accuracy 的查询如何影响 future 使用延续标记的查询之间令人惊讶的相互作用。

当您使用搜索 API 为文档编制索引时，我们使用与 High Replication Datastore 相同的机制(即 Megastore)将它们存储在几个不同的副本中。这些文档在每个副本上生效的速度取决于许多因素。它通常是即时的，但如果您对单个(索引、命名空间)对进行批量写入，延迟可能会变得更长。

可以在这些副本中的任何一个上执行搜索。我们甚至可能会在与原始搜索不同的副本上运行使用延续标记的搜索。如果原始副本和/或延续副本正在 catch 他们的索引工作，他们可能有不同的实时文档集。它“最终”会变得一致，但并不总是立竿见影。

如果您在查询中指定 number_found_accuracy，我们必须运行大部分查询，就像我们要返回 number_found_accuracy 结果一样。我们特别需要深入阅读发布列表以查找和计算匹配的文档。读取发布列表会导致其关联的文件 block 被插入到各种缓存中。

反过来，当您使用游标进行搜索时，我们将能够在我们用于原始搜索的相同副本上更快地阅读真正的文档。。因此，您不太可能将继续搜索故障转移到可能尚未完成对同一组文档的索引的不同副本。我认为您观察到的不一致结果是这种连续查询故障转移的结果。

总而言之，将 number_found_accuracy 设置为较大的值可以有效地预热该副本的缓存。因此，它几乎肯定是连续搜索的最快副本。面对试图 catch 索引的副本，这会让人觉得 number_found_accuracy 对结果的一致性有直接影响，但实际上它只是一个副作用。