本頁提供相關指南，說明如何有效率地大量載入資料至 Spanner。
您可以採取下列幾種做法來將大量資料載入 Spanner：
雖然您也可以使用 Google Cloud CLI 插入資料列，但我們不建議您使用 gcloud CLI 進行大量載入作業。
大量載入的效能指南
為獲得最佳大量載入效能，請充分利用分區功能，將資料寫入作業分散到多個工作站工作。
Spanner 會依負載進行分割，在執行個體的運算資源間平均分配資料負載。高負載情形出現幾分鐘後，Spanner 就會在資料列之間建立分割界限。一般而言，如果資料負載均勻分布，且您有遵循結構定義設計和大量載入的最佳做法，寫入總處理量應該每隔幾分鐘就會倍增，直到執行個體中可用的 CPU 資源飽和為止。
按主鍵將資料分區
Spanner 會自動將資料表分割成較小的範圍。資料列的主鍵會決定資料列的分割位置。
若要取得大量載入的最佳寫入總處理量，請使用下列模式按主鍵將資料分區：
- 視索引鍵資料欄而定，每個分區皆含有特定範圍的連續資料列。
- 每個修訂版本只含有單一分區的資料。
分區數量最好是 Spanner 執行個體中節點數量的 10 倍。您可以採取下列做法，指派資料列給各分區：
- 按主鍵排序資料。
- 將資料分割為 10 * (節點數量) 個獨立且大小相等的分區。
- 建立不同的工作站工作，並將這些工作指派給每個分區。請在應用程式中建立工作站工作，這不是 Spanner 功能。
如果按照這個模式進行，您應該會發現每個節點每秒的大量寫入總處理量整體高達 10 至 20 MB。
載入資料的同時，Spanner 會建立分割並予以更新，藉此平衡執行個體中的節點負載。在這個過程中，總處理量可能會暫時下降。
範例
您的地區性設定具備 3 個節點，而非交錯資料表中有 90,000 個資料列。資料表中的主鍵範圍則介於 1 至 90,000 之間。
- 資料列數量：90,000 列
- 節點數量：3 個
- 分區數量：10 * 3 = 30 個
- 每個分區的資料列數量：90,000 / 30 = 3,000 個
第一個分區包含的索引鍵範圍為 1 至 3,000，第二個分區涵蓋的索引鍵範圍則為 3,001 至 6,000。第 30 個分區包含的索引鍵範圍落在 87,001 至 90,000。(連續索引鍵不得用於大型資料表；本範例僅供示範之用。)
每個工作站工作都會傳送單一分區的寫入操作。在各個分區內，您應按主鍵依序寫入資料列。但您若根據主鍵隨機寫入資料，系統應該也能提供相當高的總處理量。評估測試執行結果可讓您深入瞭解系統狀況，找出能為資料集提供最佳效能的方法。
不分區的大量載入
在修訂版本中寫入連續的資料列組，比寫入隨機資料列更快。隨機資料列也可能包含來自不同區隔的資料。
當更多區隔寫入修訂版本時，就需要在伺服器之間進行更多協調，導致修訂版本的延遲時間和額外負擔增加。
每個隨機資料列皆可能屬於不同的分區，因此這項作業可能會用到多個分區。最糟的情況是，每次寫入都會用到 Spanner 執行個體中的每個分區。如前所述，寫入總處理量會隨著分割區數量的增加而降低。
避免過載
系統傳送的寫入請求可能會超過 Spanner 可處理的上限。Spanner 會取消交易以處理超載的情況，這就是所謂的「回拒」(pushback)。如果您是執行唯寫交易，Spanner 會自動重試該交易。在這些情況下，回拒會導致高延遲狀況發生。在高負載量期間，回拒程序可能會持續一分鐘的時間；在負載量特別高的期間，回拒程序則可能持續數分鐘。如要避免回拒，您應調節寫入請求的次數，以將 CPU 使用率維持在合理的限制範圍內。或者，使用者也可以增加節點數量，讓 CPU 使用率維持在限制範圍內。
一次修訂 1 MB 至 5 MB 的異動事件
無論寫入的資料量大小，每次寫入 Spanner 都會造成一些負擔。如要大幅提高總處理量，請將每次寫入作業儲存的資料量最大化。增加寫入的資料量有助於降低每次寫入作業的負擔比率，最好是每個修訂版本都修改數百個資料列。一般而言，寫入數量相當龐大的資料列時，大小介於 1 MB 至 5 MB 間的修訂版本可提供最佳效能。寫入的值較小或被編入索引時，最佳做法通常是在單一修訂版本中只寫入幾百個資料列。請注意，無論修訂版本大小和資料列數量，每個修訂版本的異動事件數不得超過 80,000 個。您應測試並評估總處理量，藉此判斷最佳效能。
修訂版本超過 5 MB 或內含數百個以上的資料列並不會帶來額外益處，而且還可能超過 Spanner 針對修訂版本大小和各修訂版本異動事件數所設定的限制。
次要索引的使用指南
如果資料庫具有次要索引，您就必須選擇在載入資料表資料前新增索引至資料庫結構定義，或載入完成後再予以新增。
在資料載入前新增索引，可讓結構定義變更立即完成。不過，每個影響索引的寫入作業都需要更新索引，因此會花費較長的時間。資料載入完成後，資料庫就會立即可用，且所有索引都已就位。如要同時建立資料表及其索引，請在單一要求中傳送新資料表和新索引的 DDL 陳述式給 Spanner。
在載入資料後新增索引，可確保每次寫入作業的效率。不過，每個索引補充作業的結構定義變更可能需要很長的時間。資料庫無法完全使用，且查詢無法使用索引，直到所有結構定義變更都完成為止。資料庫仍可提供寫入和查詢服務，但速度會變慢。
建議您在載入資料前，先新增對業務應用程式至關重要的索引。對於所有非必要的索引，請在資料遷移完成後再新增。
在大量載入期間使用 INTERLEAVE IN
如果定義結構描述時，在各個資料表中有多個父項/子項參照，請務必先載入父項，再載入子項，以確保參照完整性。這項協調作業可能相當棘手，尤其是在多層階層結構的情況下。這種複雜性也讓批次處理和平行處理變得更加困難，並可能大大影響整體大量載入時間。在 Spanner 中，這些關係會使用 INTERLEAVE IN PARENT 或外鍵強制執行。詳情請參閱 CREATE TABLE 說明文件。
在大量載入後新增外部索引鍵會在幕後建立索引，因此請遵循 secondary-indexes 中的規範。
不過，對於 INTERLEAVE IN PARENT 資料表，建議您在大量載入期間使用 INTERLEAVE IN 語意建立所有資料表，這會在物理上交錯列，但不會強制執行參照完整性。這樣您就能享有區域性帶來的效能優勢，但不需要事先排序。由於子資料列可插入至相應父項之前，Spanner 就能同時寫入所有資料表。
所有資料表都載入後，您就可以遷移交錯式資料表，開始使用 ALTER TABLE t1 SET INTERLEAVE IN PARENT t2 陳述式強制執行父項/子項關係。這會驗證參照完整性，如果有任何孤立的子項資料列，則會失敗。如果驗證失敗，請使用下列查詢找出缺少的上層資料列。
SELECT pk1, pk2 FROM child
EXCEPT DISTINCT
SELECT pk1, pk2 FROM parent;
測試並評估總處理量
要預測總處理量並不容易，因此建議您先測試大量載入策略，再執行最終載入作業。如需使用分區和監控效能的詳細範例，請參閱最大化資料負載總處理量。
定期大量載入資料至現有資料庫的最佳做法
如要更新包含資料但沒有次要索引的現有資料庫，本文件的建議做法仍然適用。
如果您有次要索引，遵循上述操作說明還是可以產生不錯的效能。效能將依交易中用到的平均分割數量而異。若總處理量變得極低，您可以嘗試下列方法：
- 減少每個修訂版本中的異動事件，以便增加總處理量。
- 如果上傳的資料量超過要更新的資料表目前總大小，請刪除次要索引，並在資料上傳完畢後重新加入這些次要索引。一般來說，這並非必要的步驟，不過這樣做也許能提高總處理量。