Bigquery数据集位置上的奇怪行为
在使用Bigquery和VM实例的Google云计算引擎中，我注意到了一种奇怪的行为。
我有一个将数据流到Bigquery中的java进程。
我希望通过为BigQuery数据集和VM实例选择相同的区域来获得更好的性能，但是我的测试显示出了意想不到的行为。
CASE1: VM on US-central1 1-a和dataset位置，US插入Bigquery响应的平均时间: 150毫秒
CASE2: VM on europe-west1-c和dataset位置US插入Bigquery响应的平均时间: 700毫秒
CASE3: VM on us-central1 1-a和dataset位置，插入Bigquery响应的平均时间: 1200毫秒
CASE4: VM on europe-west1-c和数据集位置EU插入Bigquery响应集的平均时间: 1700毫秒
我能理解CASE2和CASE3的性能下降，但是CASE4呢？
测试表明，如果Bigquery数据集的位置是"EU“，那么即使VM区域是europe-west1-c，性能也会下降。
我的结论是:永远不要在EU中使用Bigquery (当然，除了对数据位置的要求)！
我的考虑有什么不对吗？
回答 1
Stack Overflow用户
发布于 2016-06-30 17:30:32
谢谢你的报告。
看起来，post中提到的延迟包括tables.get() + tabledata.insertAll()。延迟差异主要是由tables.get()造成的。
我们知道，从欧盟( EU )调用与元数据相关的API(例如tables.get)比从美国调用慢。它是由一些现有的基础设施限制造成的，不幸的是，它有短期的修复。但是，我们正在积极地进行一些后端更改，以从长远来看尽量减少这种延迟差异。
为了减轻这种情况，您可能会考虑一些事情：
- 提前创建表，因此不需要每次在insertAll之前检查表的存在。
- 如果是每日餐桌，可以试试PartitionTable吗？然后只需要创建一次表。https://cloud.google.com/bigquery/docs/partitioned-tables https://cloud.google.com/bigquery/docs/querying-partitioned-tables
- 如果新创建的表具有与基表相同的架构，请尝试流到模板表。https://cloud.google.com/bigquery/streaming-data-into-bigquery#template-tables
https://stackoverflow.com/questions/37993801
复制相似问题
腾讯云开发者
