【问题标题】:Strange behavior on Bigquery dataset locationBigquery 数据集位置上的奇怪行为
【发布时间】:2016-07-01 01:30:32
【问题描述】:

我注意到使用 Bigquery 和 VM 实例的 Google 云计算引擎有一个奇怪的行为。

我有一个将数据流式传输到 Bigquery 的 java 进程。

我希望通过为 BigQuery 数据集和 VM 实例选择相同的区域来获得更好的性能,但我的测试显示出意外的行为。

案例 1:us-central1-a 上的虚拟机和数据集位置 US 插入 Bigquery 响应的平均时间:150 毫秒

案例 2:欧洲西部 1-c 上的虚拟机和数据集位置美国 插入 Bigquery 响应的平均时间:700 毫秒

案例 3:us-central1-a 上的 VM 和数据集位置 EU 插入 Bigquery 响应的平均时间:1200 毫秒

案例 4:europe-west1-c 和数据集位置 EU 上的 VM 插入 Bigquery 响应的平均时间:1700 毫秒

我可以理解 CASE2 和 CASE3 的性能下降,但 CASE4 呢?

测试表明,如果 Bigquery 数据集位置为“EU”,即使 VM 区域为 europe-west1-c,性能也会下降。

我的结论是:永远不要在欧盟使用 Bigquery(当然,对数据位置的要求除外)!

我的考虑有什么问题吗?

【问题讨论】:

  • 能否请您提供您的项目ID、数据集ID、平板电脑ID?所以我们可以看看发生了什么?我们的服务器端统计数据显示延迟远低于 1700 毫秒。好像不太正常……
  • 我可以私下给你代码。可能吗?然后我们可以在这里继续对话。你还好吗?
  • 好的~我的邮箱:chengz@google.com 谢谢!
  • 我的身份证发给你了。提前致谢!

标签: google-bigquery google-compute-engine


【解决方案1】:

感谢您的报告。

看起来帖子中提到的延迟包括tables.get() + tabledata.insertAll()。延迟差异主要是由 tables.get() 引起的。

我们知道从欧洲调用元数据相关 API(例如 tables.get)比美国慢。它是由一些现有的基础设施限制引起的,不幸的是,它有短期的解决方案。但我们正在积极进行一些后端更改,以最大限度地减少这种延迟差异。

您可以考虑采取一些措施来缓解这种情况:

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2020-05-05
    • 1970-01-01
    • 1970-01-01
    • 2019-06-14
    • 1970-01-01
    相关资源
    最近更新 更多