批量加载最佳做法

本页面提供了一些准则,旨在帮助您高效地将大量数据批量加载到 Cloud Spanner 中。

您可以通过多种方式将数据批量加载到 Cloud Spanner 中:

批量加载的性能准则

通过遵循以下准则,您可以实现最佳的批量加载性能:

  • 尽可能减少每个写入事务所涉及的分片数量。当事务所涉及的分片数量减少时,写入吞吐量会达到最大,从而实现性能最大化。

  • 最大限度地利用分区功能,以跨越多个工作器任务分配写入分区。

Cloud Spanner 使用基于负载的拆分来跨节点平均分配数据负载。在几分钟的高负载之后,Cloud Spanner 会在非交错表的行之间引入分片边界。一般而言,如果数据负载分布均衡,并且您遵循了架构设计和批量加载的最佳做法,那么在实例中可用的 CPU 资源达到饱和前,写入吞吐量应该每隔几分钟就会增加一倍。

通过主键对数据进行分区

要获得批量加载的最佳写入吞吐量,请使用以下模式通过主键对数据进行分区:

  • 每个分区包含一系列连续的行(由键列确定)。
  • 每个提交包含仅用于单个分区的数据。

我们建议分区数为 Cloud Spanner 实例中节点数的 10 倍。要将行分配给分区,请执行以下操作:

  • 通过主键对数据进行排序。
  • 将数据划分到 10 *(节点数)个独立且大小相等的分区。
  • 为每个分区创建并分配单独的工作器任务。您应该在您的应用中创建工作器任务。Cloud Spanner 不具备该功能。

若遵循这种模式,对于大型加载作业,每个节点的最大整体批量写入吞吐量应该会达到每秒 10-20 MB。

在加载数据时,Cloud Spanner 会创建并更新分片,以平衡实例中节点上的负载。在此过程中可能会出现吞吐量暂时下降的情况。

示例

您有一个包含 3 个节点的区域配置。非交错表的行数为 90000 行。表中的主键范围为 1 到 90000。

  • 行数:90000
  • 节点数:3
  • 分区数:10 * 3 = 30
  • 每个分区的行数:90000 / 30 = 3000。

第一个分区包括键范围 1 到 3000。第二个分区包括键范围 3001 到 6000。第 30 个分区包括键范围 87001 到 90000。(不应在大型表中使用顺序键。此示例仅出于演示目的。)

每个工作器任务都负责发送对单个分区的写入操作。在每个分区中,您应该按主键并按顺序写入行。在分区中随机写入行(就主键而言)也应提供合理的高吞吐量。 通过衡量测试结果,您可以深入了解哪种方法可为数据集提供最佳性能。

如果您决定不使用分区

在提交中写入随机的行(每个变更插入单独一行)可能比一次只写入一行更慢。这可能会涉及多个分片,因为每个随机行可能属于不同的分片。最糟糕的情况是,每次写入都会涉及 Cloud Spanner 实例中的所有分片。如上文所述,当写入涉及更多分片时,写入吞吐量会降低。

避免回退

发送的写请求有可能会多于 Cloud Spanner 能够处理的写请求。 Cloud Spanner 通过中止事务来处理过载,这种情况称作“回退”(pullback)。 对于只写事务,Cloud Spanner 会自动重试事务。在这种情况下,回退表现为高延迟。在高负载期间,回退可能会持续长达一分钟。在严重高负载期间,回退可能会持续几分钟。为了避免回退,您应该限制写入请求,以将 CPU 利用率保持在合理的限制范围内。

每次提交 1 MB 到 5 MB 的变更

无论写入量是大还是小,每次写入 Cloud Spanner 都会产生一些开销。要使吞吐量最大化,应最大限度提高每次写入所存储的数据量。 增加写入量有助于降低每次写入的开销比率。 一种较好的方法是,每个提交都修改数百行。写入相对较大的行时,大小为 1 MB 到 5 MB 的提交通常可提供最佳性能。在写入较小的值或编入索引的值时,最佳做法通常是,在单个提交中最多写入几百行。请注意,不管提交大小和行数是多少,每个提交包含的变更数不得超过 20000。 要确定最佳性能,您应该测试并测量吞吐量。

大于 5 MB 或超过几百行的提交不会带来额外的好处,并且有可能超出 Cloud Spanner 对提交大小以及每个提交包含的变更数的限制

二级索引准则

如果数据库具有二级索引,您必须选择在加载表数据之前还是之后将索引添加到数据库架构。

  • 在加载数据之前添加索引可让架构更改立即完成。但是,影响索引的每次写入将需要更长时间,因为它还需要更新索引。数据加载完成后,所有索引就绪,数据库将立即可用。要同时创建表及其索引,请在一个请求中将添加新表和添加新索引的 DDL 语句一并发送到 Cloud Spanner。

  • 在加载数据后添加索引意味着每次写入都是高效的。但是,每个索引回填的架构更改可能需要较长时间。在所有架构更改完成之前,数据库不是完全可用的。

一般而言,如果数据库的索引少于 40 个,请在加载数据后添加索引。对于索引数量远远超过 40 的数据库,请在加载数据之前添加索引。

测试并测量吞吐量

预测吞吐量可能较为困难。我们建议您在最终加载数据之前先测试批量加载策略。如需查看使用分区和监控性能的详细示例,请参阅最大化数据加载吞吐量

定期批量加载到现有数据库的最佳做法

如果要更新包含数据但没有任何二级索引的现有数据库,本主题中的建议仍然适用。

如果您有二级索引,这些说明可能会帮助您获得合理的性能。性能取决于事务涉及的平均分片数量。如果吞吐量下降至太低的水平,您可以尝试以下方法:

  • 减少每个提交中包含的变更数量,这可能会提高吞吐量。
  • 如果您的上传量大于正在更新的表的当前总大小,请删除二级索引,并在上传数据后重新添加。通常没有必要执行此步骤,但这样做可能会提高吞吐量。

导入 Avro 文件的最佳做法

以下页面提供了有关提升 Avro 文件导入性能的信息:

使用 Dataflow 连接器的最佳做法

如需了解 Dataflow 连接器使用方面的性能提示,请参阅写入 Cloud Spanner 并转换数据