BigQuery检索时间慢

Question

BigQuery正在快速处理大量数据，但从BigQuery中检索大量结果并不快。

例如，我运行了一个查询，该查询在三个HTTP请求中返回了211,136行，总共超过12秒。 查询本身是从缓存返回的，因此没有时间执行查询。主机服务器是在美国东部（弗吉尼亚州）运行的Amazon m4.xlarge。

在制作中，我看到这个过程在返回~120n行时需要大约90秒。显然其中一些可能归结为网络流量......但它似乎太慢而不是唯一原因（那些211,136行只有~1.7MB）。

有没有其他人在返回结果时遇到这么慢的速度，并找到了解决方案？

更新：对Google Cloud中的VM进行Reran测试，结果非常相似。排除Google和AWS之间的网络问题。

Answer 1

此API上的SLO为32秒，通话时间为12秒是正常的。 90秒听起来太长了，它必须达到我们系统的一些尾部延迟。

我明白这是令人尴尬的慢。它有多种原因，我们正致力于改善此API的延迟。到明年第一季度末，我们应该能够推出一项将tabledata.list时间缩短一半的变更（通过将API前端升级到我们新的One Platform技术）。如果我们有更多的资源，我们也会更快地使jobs.getQueryResults。

Answer 2

使用TableData.List的并发请求

这不是很好，但有一个决议。

进行查询，并将最大行数设置为1000.如果没有页面标记，只需返回结果。

如果有页面标记，则忽略结果*，并使用TableData.List API。但是，不是简单地一次发送一个请求，而是在结果中发送每10,000条记录*的请求。为此，可以使用'MaxResults'和'StartIndex'字段。 （注意，即使这些较小的页面也可能被分成多个请求*，因此仍需要分页逻辑。）

这种并发（和较小的页面）可以显着缩短检索时间。不如BigQ简单地流式传输所有结果，但足以开始实现使用BigQ的收益。

潜在的Pitfals：密切关注请求计数，因为较大的结果集可能会有100req / s的限制。值得注意的是，不能保证排序，因此使用StartIndex字段作为伪分页可能并不总是返回正确的结果*。

*任何带有单个星号的东西仍然是一个有根据的猜测，但未被确认为真实/最佳实践。