Google App Engine上的搜索API

Question

我正在使用App Engine和内置的Search API运行概念验证。我们正在测试Search API，假设它提供线性扩展，就像与App Engine捆绑在一起的其他产品和服务一样。

• 规格：约。单个索引中有800万个文档
• 查询类型： 复杂的查询，我们需要基于方形区域的空间查询，而不是 距离（！）。所有查询都包括2个基于纬度和范围的范围 经度。
• 页面大小：介于16和250之间。
• 在所有测试用例中，准确度（结果计数）设置为100.

我们的目标性能（延迟）在100毫秒范围内。

我们正在测试运行多个并发请求的Search API的性能。现在测试结果大约是25个并发请求，但预计这个数字会显着上升。但是，如果Search API可以正确扩展，那么这应该没有意义。

我正在测量Search API处理对Index.search（Query）的调用所花费的时间。 我测量的是以下内容：

1. 搜索方法返回的平均时间约为8000毫秒。在任何情况下，该方法都不会明显更快或更慢地返回。但是，使用包含10个文档的索引会导致延迟测量大约300毫秒（!!!）。这可能表明Search API根本不可扩展。
2. 页面大小似乎没有任何显着差异。也许页面大小为10.000或更高，但这不是我们测试的一部分。
3. 添加一个标准（相等）似乎可以显着加快搜索速度。高达约40％的改善。这似乎是一个很好的改进，但4秒仍然是永恒的。

问题：

1. Search API可以提供的预期延迟（最佳方案/配置）是什么？
2. 哪些参数会影响延迟，包括应用引擎配置。
3. 索引中的文档数量会影响延迟吗？
4. 基于2个范围查询的搜索是否比仅基于相等过滤器的搜索慢？ （因为我们可以预处理数据并向每个文档添加索引数据）。
5. Search API是否真正可扩展？

Answer 1

我们的应用是使用图块服务器在地图上绘制多个标记。然而，区块服务器并行地执行许多查询（即“区块”），每个用户/视图几乎30个。为了使事情变得困难，我们无法使用预先聚合的地图解决此问题，因为我们有太多的参数/维度需要处理（如果是这种情况，请尝试使用：Google Maps Engine）。

因此，我们最终将CloudSQL实例设置为最高层。性能。使用关系数据库的另一个原因是，与Search API或BigQuery相比，索引性能更精确可调。

要回答这些问题，我们发现了这一点：

1. 延迟取决于索引的大小。在每个索引的较低卷时，延迟似乎是合理的。在更高的容量下，这可能成为一个问题。但对于文本搜索，这在大多数情况下可能没问题。
2. 我们没有在较低的音量下测试，但是大约有800万个文档，延迟时间在5000到8000毫秒之间。每个查询。我们没有发现任何减少延迟的参数，我们确实找到了增加延迟的参数。
3. 是
4. 我们没有对此进行测试。
5. 是