1

我运行了一些 BigQuery DML 测试以更好地了解 BigQuery DML 功能的性能。到目前为止,这里有一些初步的观察结果:1)在一个非常小的表(30K+ 记录)中只更新几条记录时性能很慢

UPDATE babynames.names_2014
SET name = 'Emma B' 
WHERE name = 'Emma';

输出:- 2 行受影响(表中的记录数:33176)- 查询完成(经过 4.5 秒,已处理 621 KB)


2) 从小表中只删除几条记录时性能非常慢

SQL:

DELETE from babynames.names_2014_copy
where gender<>'U'

输出:-2 行受影响。- 查询完成(经过 162.6 秒,已处理 1.21 MB) - 约 3 分钟

问题: 1)这些是已知的行为吗?2)关于如何提高性能的任何建议?

4

2 回答 2

1

(1) 是近似预期的 - 主要 DML 场景是影响许多行(数百万/十亿行)的大型更新/删除。所以延迟不如吞吐量重要。

(2) 看起来不正常——你能再试一次吗?您要更新的表有什么不寻常的地方吗?

关于如何提高性能的任何建议?

优化 DML 语句,每个语句更新多行。例如,您可以使用连接/半连接来指定大量受影响的行。

于 2017-01-17T23:28:20.623 回答
0

我还注意到BigQuery 中UpdateDelete操作可能会非常慢。

有趣的是,使用“创建或替换表”语句覆盖表通常具有明显更好的性能。

所以而不是:

DELETE from babynames.names_2014_copy
where gender<>'U'

考虑只使用:

create or replace table babynames.names_2014_copy
AS
select *
from babynames.names_2014_copy
where not  gender<>'U'

类似的技术也适用于Update; 你只需要写一个case语句来修改你的值。

于 2021-02-06T11:47:06.610 回答