本页面提供了一些准则，帮助您高效批量加载大量数据 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 发出单个请求即可添加新索引。
在加载数据后添加索引意味着每次写入都是高效的。但是，每个索引回填的架构更改可能需要很长时间。 数据库无法完全使用，在下列日期之前，查询无法使用索引 所有架构更改都已完成数据库仍可以处理写入 但速度较慢
我们建议您添加对业务应用至关重要的索引 然后再加载数据对于所有非关键索引，请将它们添加到 数据。
测试并测量吞吐量
预测吞吐量可能较为困难。我们建议您在最终加载数据之前先测试批量加载策略。如需查看使用分区和监控性能的详细示例，请参阅最大化数据加载吞吐量。
定期批量加载到现有数据库的最佳做法
如果要更新包含数据但没有任何二级索引的现有数据库，本主题中的建议仍然适用。
如果您有二级索引，这些说明可能会帮助您获得合理的性能。性能取决于事务涉及的平均分片数量。如果吞吐量下降至太低的水平，您可以尝试以下方法：
- 减少每个提交中包含的变更数量，这可能会提高吞吐量。
- 如果您的上传量大于正在更新的表的当前总大小，请删除二级索引，并在上传数据后重新添加。通常没有必要执行此步骤，但这样做可能会提高吞吐量。