使用谷歌应用引擎搜索API时，如果我们有一个返回大结果集（> 1000）的查询，并且需要使用游标进行迭代来收集整个结果集，我们会得到不确定的结果如果number_found_accuracy低于我们的结果大小，则返回文档。
换句话说，相同的查询运行两次，通过游标收集所有文档，不返回相同的文档，除非我们的number_found_accuracy高于结果大小（例如，使用10000最大值）。只有这样我们才能获得相同的文件。
我们对number_found_accuracy如何工作的理解是它只会影响number_found估计。我们假设如果您使用光标来获取所有结果，您将能够获得与运行一个大型查询时相同的结果。
我们是否误解了number_found_accuracy或游标的使用，或者我们发现了错误？
答案 0 :(得分：1)
您对number_found_accuracy的理解是正确的。我认为您观察到的行为是复制查询故障转移与指定number_found_accuracy的查询如何影响使用延续令牌的未来查询之间令人惊讶的相互作用。
使用Search API索引文档时，我们使用与High Replication数据存储区相同的机制（即Megastore）将它们存储在多个不同的副本中。这些文档在每个副本上的生效速度取决于许多因素。它通常是即时的，但如果您正在对单个（索引，命名空间）对进行批量写入，则延迟会变得更长。
可以在任何这些副本上执行搜索。我们甚至可能会在与原始搜索不同的副本上运行使用延续令牌的搜索。如果原始副本和/或继续副本正在追赶其索引工作，则它们可能具有不同的实时文档集。它将变得一致＆＃34;最终＆＃34;但并不总是立竿见影。
如果在查询中指定number_found_accuracy，我们必须运行大部分查询，就好像我们要返回number_found_accuracy结果一样。我们特别需要在发布列表中进一步阅读以查找和计算匹配的文档。读取发布列表会导致其关联的文件块被插入到各种缓存中。
反过来，当您使用光标进行搜索时，我们将能够更快地在同一个副本上阅读文档我们用于原始搜索。因此，您不太可能将延续搜索故障转移到可能尚未完成索引同一组文档的其他副本。我认为您观察到的不一致结果是这种延续查询故障转移的结果。
总之，将number_found_accuracy设置为有效的内容可以有效地预复制副本的缓存。因此，它几乎肯定是继续搜索的最快复制品。面对试图赶上索引的复制品，这会使number_found_accuracy直接影响结果的一致性，但实际上它只是一个副作用。