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 实例设置为最高层的 max。表现。使用关系数据库的另一个原因是，与搜索 API 或 BigQuery 相比，索引性能可以更精确地调整。

为了回答这些问题，我们发现：

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