在对我们的模块进行负载测试期间，我们发现 bigquery 插入调用需要时间（3-4 秒）。我不确定这是否可以。我们正在使用 java biguqery 客户端库，平均每个 api 调用我们推送 500 条记录。我们预计每秒有 100 万条记录流向我们的模块，因此 bigquery 插入是处理此流量的瓶颈。目前，推送数据需要数小时。 如果我们需要有关代码或场景或任何内容的更多信息，请告诉我。
谢谢 潘卡伊
【问题讨论】：
标签： google-bigquery
由于流的有效负载大小有限，请参阅Quota policy 更容易谈论时间，因为有效负载对我们双方的限制方式相同，但我也会提到其他副作用。
我们测量每个流式传输请求的时间在 1200-2500 毫秒之间，这在上个月是一致的，如图所示。
虽然我们看到了一些副作用：
对于所有这些，我们在付费的 Google 企业支持中打开了案例，但不幸的是，他们没有解决问题。接缝推荐的选项是重试的指数退避，即使是被告知这样做的支持。就个人而言，这并不让我高兴。
如果您选择的方法需要几个小时，这意味着 it does not scale，并且不会扩展。您需要重新考虑使用async processes 的方法。为了更快地完成，您需要并行运行多个工作人员，流式传输性能将是相同的。只要有 10 个并行工作人员，就意味着时间将减少 10 倍。
在后台处理 IO 绑定或 cpu 绑定任务现在是大多数 Web 应用程序的常见做法。有很多软件可以帮助构建后台作业，其中一些基于 Beanstalkd 这样的消息传递系统。
基本上，您需要在封闭的网络中分配插入作业，确定它们的优先级，并使用（运行）它们。嗯，这正是 Beanstalkd 提供的。
Beanstalkd 提供了在管中组织作业的可能性，每个管对应于一种作业类型。
您需要一个 API/生产者，可以将作业放在管子上，比方说行的 json 表示。这是我们用例的杀手级功能。所以我们有一个 API 可以获取行并将它们放置在管上，这只需几毫秒，因此您可以实现快速响应时间。
另一方面，您现在在一些电子管上有很多工作。你需要一个代理。代理/消费者可以预订工作。
它还可以帮助您进行作业管理和重试：成功处理作业后，消费者可以从试管中删除该作业。在失败的情况下，消费者可以埋葬工作。这项工作不会被推回试管，但可供进一步检查。
消费者可以发布一个工作，Beanstalkd 会将这个工作推回管中，并使其可供另一个客户端使用。
Beanstalkd 客户端可以在大多数常用语言中找到，web interface 可用于调试。
【讨论】：