优化槽之间的通信

在评估通信吞吐量时,请考虑您的查询所需的数据重排量。暂存区之间要传递多少字节的数据?有多少字节要传递到每个槽?例如,GROUP BY 子句将类似的值传递到相同的槽进行处理。数据重排量会直接影响通信吞吐量,进而影响查询性能。

以下最佳做法提供了有关控制槽间通信的指南。

使用 JOIN 前减少数据

最佳做法:在使用 JOIN 子句之前减少所处理的数据量。

在查询执行 JOIN 前,请尽早在查询中修剪数据。如果您在处理周期中尽早减少数据,则仅会对您所需的数据执行重排和其他复杂操作。

勿将 WITH 子句视为预备的语句

最佳做法:主要使用 WITH 来提高可读性。

由于 WITH 子句是未实体化子句,因此它主要用于提高可读性。例如,将所有查询置于 WITH 子句中然后再运行 UNION ALLWITH 子句的一种误用。如果一个查询出现在多个 WITH 子句中,则该查询会在每个子句中执行。

避免按日期分片的表

最佳做法:请勿使用按日期分片的表(也称为以日期命名的表)代替时间分区表。

分区表的性能优于以日期命名的表。如果您创建按日期分片的表,BigQuery 就必须为每个以日期命名的表保留架构和元数据的副本。此外,如果您使用以日期命名的表,BigQuery 可能需要分别为每个要查询的表验证权限。该做法还会增加查询开销,影响查询性能。

避免对表过度分片

最佳做法:避免创建过多的表分片。如果您要按日期对表分片,请改为使用时间分区表。

表分片指将大型数据集分割为多个单独的表,并向每个表名称添加一个后缀。如果您要按日期对表分片,请改为使用时间分区表

由于 BigQuery 存储空间的费用较低,因此与使用关系型数据库系统不同,您无需出于费用考虑而对表进行优化。任何费用优势均无法弥补因创建大量表分片而造成的的性能影响。

分片表需要 BigQuery 保留每个分片的架构、元数据和权限信息。由于为每个分片保留信息需要增加开销,因此对表过度分片可能会影响查询性能。

此页内容是否有用?请给出您的反馈和评价:

发送以下问题的反馈:

此网页
需要帮助?请访问我们的支持页面