Google BigQuery：慢速流式插入性能

Question

我们正在使用BigQuery作为事件记录平台。

我们遇到的问题是非常慢的insertAll帖子请求（https://cloud.google.com/bigquery/docs/reference/v2/tabledata/insertAll）。 从服务器端或客户端发射它们并不重要。

最小值为900毫秒，平均值为1500秒，连接时间接近1000毫秒。 即使每秒有1个请求（因此这里没有限制）。

我们使用Google Analytics测量协议，同一台计算机的计时时间为50-150毫秒。

BigQuery streaming 'insertAll' performance with PHP中描述的解决方案使用队列，但似乎有点矫枉过正，因为我们每秒发送的请求不超过10个。

问题是流媒体插入是否正常1500ms，如果不正常，如何使它们更快。

附加信息： 如果我们发送格式错误的JSON，响应将在50-100ms内到达。

Answer 1

由于流媒体的有效载荷大小有限，请参阅Quota policy更容易谈论时间，因为有效载荷以同样的方式限制在我们两个人身上，但我也会提到其他副作用。

我们为每个流媒体请求测量1200-2500毫秒，这在过去的一个月中是一致的，如图所示。

我们看到了几种副作用，但是：

• 请求随机失败，类型为“后端错误”
• 请求随机失败，类型为“连接错误”
• 请求随机类型'timeout'随机失败（请注意此处，因为只有部分行失败而不是整个有效负载）
• 其他一些错误消息是非描述性的，而且它们非常模糊，以至于它们无法帮助您，只需重试即可。
• 我们每天都会看到数百起此类故障，因此它们几乎不变，与云健康状况无关。

对于所有这些，我们在付费Google Enterprise支持中打开了案例，但不幸的是他们没有解决它。它接缝推荐的选项，因为这是一个指数退避与重试，甚至支持告诉这样做。哪个人不会让我开心。

此外，失败率符合我们在SLA中的99.9％正常运行时间，因此没有理由反对。

关于SLA需要注意的事项，它是一个非常严格定义的结构，细节是here。 99.9％的正常运行时间未直接转换为失败率。这意味着如果BQ在一个月内有30分钟的停机时间，然后在该时间段内进行10,000次插入但在该月的其他时间没有进行任何插入，则会导致数字被串联。这就是我们建议指数退避算法的原因。 SLA明确地基于正常运行时间而不是错误率，但从逻辑上讲，如果您在不同时间使用退避重试设置在整个月中进行流式插入，则两者之间会密切相关。从技术上讲，如果你已经设置了适当的重试机制，那么如果你在月内进行插入，你应该平均经历大约1/1000次失败的插入。

您可以查看有关项目运行状况的此图表： https://console.developers.google.com/project/YOUR-APP-ID/apiui/apiview/bigquery?tabId=usage&duration=P1D

碰巧我的回复是在链接的其他文章上，我提出了队列，因为它使我们的指数退避很容易，并且使用队列非常容易。我们使用Beanstalkd。

Answer 2

根据我的经验对bigquery的任何请求都需要很长时间。我们已经尝试将其用作性能数据的数据库，但由于响应时间较慢，最终会将其移出。据我所知。 BQ专为在1到10秒的响应时间内处理大请求而构建。这些是BQ归类为交互式的请求。 BQ不会因为做得更少而变得更快。我们将一些记录流式传输到BQ，但始终确保我们将它们分批（每个表）。并异步运行所有请求（或者如果你必须在另一个请求中）。

PS。我可以确认Pentium10对BQ中的faillures有什么看法。确保重试失败的内容，如果再次失败，请将其记录到文件中，以便再次重试。