google-app-engine - Google App Engine 上的搜索 API

Question

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

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

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

我们正在测试运行多个并发请求的搜索 API 的性能。测试结果现在是在大约 25 个并发请求下测得的，但这个数字预计会大幅上升。但是，如果 Search API 具有适当的可扩展性，那么这应该毫无意义。

我正在测量搜索 API 处理对 Index.search(Query) 的调用所花费的时间。 我测量的是以下内容:

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

问题:

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

Answer 1

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

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

为了回答问题，这是我们发现的:

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