本页面提供了一些准则,帮助您高效批量加载大量数据 Spanner。
您可以通过多种方式将数据批量加载到 Spanner 中:
当然,您也可以 使用 Google Cloud CLI 插入行 我们不建议您使用 gcloud CLI 进行批量加载。
批量加载的性能准则
为了实现最佳的批量加载性能,请充分利用分区功能 在工作器任务之间分配写入数据。
Spanner 使用基于负载的拆分来均匀分布数据 跨实例的计算资源进行负载 在几分钟的高负载之后,Spanner 会引入 分块边界。一般而言,如果数据负载分布均衡,并且您遵循了架构设计和批量加载的最佳做法,那么在实例中可用的 CPU 资源达到饱和前,写入吞吐量应该每隔几分钟就会增加一倍。
通过主键对数据进行分区
Spanner 会将表动态划分为更小的范围。主 行的键决定了该行的分区位置。
要获得批量加载的最佳写入吞吐量,请使用以下模式通过主键对数据进行分区:
- 每个分区包含一系列连续的行(由键列确定)。
- 每个提交包含仅用于单个分区的数据。
我们建议分区数量是 Spanner 实例。要将行分配给分区,请执行以下操作:
- 通过主键对数据进行排序。
- 将数据划分到 10 *(节点数)个独立且大小相等的分区。
- 为每个分区创建并分配单独的工作器任务。您应该在您的应用中创建工作器任务。这不是 Spanner 的功能。
若遵循这种模式,对于大型加载作业,每个节点的最大整体批量写入吞吐量应该会达到每秒 10-20 MB。
在加载数据时,Spanner 会创建并更新分块,以平衡 您实例中的节点上在此过程中可能会出现吞吐量暂时下降的情况。
示例
您有一个包含 3 个节点的区域配置。非交错表的行数为 90000 行。表中的主键范围为 1 到 90000。
- 行数:90000
- 节点数:3
- 分区数:10 * 3 = 30
- 每个分区的行数:90000 / 30 = 3000。
第一个分区包括键范围 1 到 3000。第二个分区包括键范围 3001 到 6000。第 30 个分区包括键范围 87001 到 90000。(不应在大型表中使用顺序键。此示例仅出于演示目的。)
每个工作器任务都负责发送对单个分区的写入操作。在每个分区中,您应该按主键并按顺序写入行。在分区中随机写入行(就主键而言)也应提供合理的高吞吐量。 通过衡量测试结果,您可以深入了解哪种方法可为数据集提供最佳性能。
如果您决定不使用分区
在提交中写入随机行可能比写入 提交中的一组连续行,并且可能涉及不同位置中的 分区。分块越多,提交延迟时间和开销就越大 写入到提交中,因为服务器之间的协调增强。多个 都可能涉及分块 因为每个随机行可能属于不同的分块。在最糟糕的情况下 则每次写入都会涉及 Spanner 实例中的每个分块。如 如上文所述,涉及的分块越多,写入吞吐量会降低。
在不进行分区的情况下批量加载
在提交中写入一组连续的行可能比写入随机行更快 行。随机行还可能包含来自不同分区的数据。
当一个提交中写入的分区越多, 而增加提交延迟时间和开销。
可能涉及多个分区,因为每个随机行都可以属于 不同的分区在最糟糕的情况下,每次写入都会 Spanner 实例中的每个分区。如上所述,将 涉及的分区更多时,吞吐量会降低。
避免过载
发送的写入请求有可能会多于 Spanner 能够处理的写入请求。 Spanner 通过取消事务来处理过载,这称为 回复。对于只写事务,Spanner 会自动重试 交易。在这种情况下,回退表现为高延迟。在高负载期间,回退可能会持续长达一分钟。在严重高负载期间,回退可能会持续几分钟。为避免回推, 写入请求,将 CPU 利用率保持在合理范围内 限制。或者,用户可以 增加节点数,使 CPU 利用率不超出限制。
每次提交 1 MB 到 5 MB 的变更
每次写入 Spanner 都会产生一些开销,无论写入是否很大 或小。要使吞吐量最大化,应最大限度提高每次写入所存储的数据量。 增加写入量有助于降低每次写入的开销比率。 一种较好的方法是,每个提交都修改数百行。写入相对较大的行时,大小为 1 MB 到 5 MB 的提交通常可提供最佳性能。在写入较小的值或编入索引的值时,最佳做法通常是,在单个提交中最多写入几百行。请注意,不管提交大小和行数是多少, 您最多只能设置 80,000 每个提交包含的更改数。 要确定最佳性能,您应该测试并测量吞吐量。
大小超过 5 MB 或超过几百行的提交不能 可带来额外的好处,并且存在超出 Spanner 限制的风险 以及每个提交的更改数量
二级索引准则
如果数据库具有二级索引,您必须选择在加载表数据之前还是之后将索引添加到数据库架构。
在加载数据之前添加索引可让架构更改立即完成。但是,影响索引的每次写入将需要更长时间,因为它还需要更新索引。数据加载完成后,所有索引就绪,数据库将立即可用。要创建表及其 同时为新表和新表发送 DDL 语句, 向 Spanner 发出的单个请求即可增加新索引。
在加载数据后添加索引意味着每次写入都是高效的。但是,每个索引回填的架构更改可能需要很长时间。 数据库无法完全使用,在下列日期之前,查询无法使用索引 所有架构更改都已完成数据库仍可以处理写入 但速度较慢
我们建议您添加对业务应用至关重要的索引 然后再加载数据对于所有非关键索引,请将它们添加到 数据。
测试并测量吞吐量
预测吞吐量可能较为困难。我们建议您在最终加载数据之前先测试批量加载策略。如需查看使用分区和监控性能的详细示例,请参阅最大化数据加载吞吐量。
定期批量加载到现有数据库的最佳做法
如果要更新包含数据但没有任何二级索引的现有数据库,本主题中的建议仍然适用。
如果您有二级索引,这些说明可能会帮助您获得合理的性能。性能取决于事务涉及的平均分片数量。如果吞吐量下降至太低的水平,您可以尝试以下方法:
- 减少每个提交中包含的变更数量,这可能会提高吞吐量。
- 如果您的上传量大于正在更新的表的当前总大小,请删除二级索引,并在上传数据后重新添加。通常没有必要执行此步骤,但这样做可能会提高吞吐量。