Google BigQuery:慢速流式插入性能

Question

我们使用BigQuery作为事件记录平台.

我们遇到的问题是非常慢的insertAll帖子请求(https://cloud.google.com/bigquery/docs/reference/v2/tabledata/insertAll).它们被解雇的位置并不重要 - 从服务器端或客户端.

最小值为900毫秒,平均值为1500秒,连接时间接近1000毫秒.即使每秒有1个请求(因此这里没有限制).

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

使用PHP的BigQuery流'insertAll'性能描述的解决方案使用队列,但它似乎有点过分,因为我们每秒发送的请求不超过10个.

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

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

Answer 1

由于流式传输的有效载荷大小有限,请参阅配额策略,因为有效载荷以同样的方式限制在我们两个人身上,因此更容易讨论时间,但我也会提到其他副作用.

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

我们看到了几个副作用,但:

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

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

此外,故障率符合我们在SLA中99.9%的正常运行时间,因此没有理由反对.

关于SLA需要注意的事项,它是一个非常严格定义的结构,细节在这里.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，但始终确保我们对它们进行批处理（每个表）。并异步运行所有请求（或者如果您必须在另一个剧院中运行）。

附言。我可以证实 Pentium10 所说的 BQ 失败。确保重试失败的内容，如果再次失败，请将其记录到文件中以便下次重试。