Azure Cosmos DB 可以儲存 TB 級的資料。 您可以執行大規模資料移轉來將生產工作負載移動到 Azure Cosmos DB。 本文說明將大規模資料移至 Azure Cosmos DB 所涉及的挑戰，並介紹有助於因應這些挑戰以及將資料遷移至 Azure Cosmos DB 的工具。 在此案例研究中，客戶使用 Azure Cosmos DB API for NoSQL。
將整個工作負載遷移至 Azure Cosmos DB 之前，您可以先遷移一小部分資料來驗證某些層面，例如分割區索引鍵選擇、查詢效能和資料模型化。 驗證概念證明之後，就能將整個工作負載移至 Azure Cosmos DB。
資料移轉工具
目前 Azure Cosmos DB 的移轉策略會隨所選 API 和資料大小而不同。 若要遷移較小的資料集——用於驗證資料建模、查詢效能、分割區鍵選擇等——你可以使用 Azure Data Factory 的 Azure Cosmos DB 連接器。 如果熟悉 Spark，您也可以選擇使用 Azure Cosmos DB Spark 連接器來遷移資料。
大規模移轉的挑戰
現有將資料遷移至 Azure Cosmos DB 的工具有一些限制，規模很大時尤其明顯：
擴增能力有限：為了儘快將數 TB 的資料遷移至 Azure Cosmos DB，並有效運用已佈建的全部輸送量，移轉用戶端的擴增能力必須不受限制。
缺少進度追蹤和檢查點：遷移大型資料集時，必須追蹤移轉進度，還要有檢查點。 否則，遷移過程中發生任何錯誤都會停止遷移，你必須從頭開始整個流程。 當移轉過程完成 99% 時，全部重來很沒效率。
缺乏無效信件佇列：在大型資料集內，部分來源資料有時會出現問題。 此外，用戶端或網路也可能發生暫時性問題。 這兩種情況都不應該導致整個遷移失敗。 即使大多數遷移工具具備強大的重試功能，能防止間歇性問題，但這並不總是足夠。 例如，若來源資料文件中少於 0.01% 大於 2 MB，則會導致 Azure Cosmos DB 的文件寫入失敗。 理想情況下，遷移工具應該將這些「失敗」的文件儲存到另一個死信佇列中，以便在遷移後進行處理。
對於 Azure Data Factory、Azure 資料移轉服務等工具，目前正在修正上述諸多限制。
自訂工具搭配大量執行工具程式庫
前一節所述的挑戰，可以透過使用自訂工具解決，該工具能輕鬆跨多個實例擴展，且對短暫故障具有韌性。 此外，自訂工具可以在不同的檢查點暫停和繼續移轉。 Azure Cosmos DB 已提供大量執行工具程式庫，涵蓋上述部分功能。 例如，大量執行工具程式庫已有能力處理暫時性錯誤，還可以擴增單一節點中的執行緒，每個節點各耗用大約 500 K 個 RU。 大量執行工具程式庫也將來源資料集分割成多個微批次，像檢查點一樣獨立運作。
自訂工具使用大量執行工具程式庫，支援跨多個用戶端擴增，還可在擷取過程中追蹤錯誤。 若要使用此工具，應該在 Azure Data Lake Storage (ADLS) 中將來源資料分割成不同檔案，讓不同的移轉背景工作角色挑選每個檔案，並內嵌至 Azure Cosmos DB。 自訂工具利用單獨的集合，其中儲存 ADLS 中每一個來源檔案移轉進度的中繼資料，並追蹤任何相關的錯誤。
下圖說明使用此自訂工具進行的移轉流程。 此工具在一組虛擬機器上執行，各虛擬機器查詢 Azure Cosmos DB 中的追蹤集合，以獲得租用其中一個來源資料分割。 完成之後，工具會讀取來源資料分割區，並使用批次執行程式庫將資料匯入 Azure Cosmos DB。 接著，更新追蹤集合，以記錄資料擷取的進度及發生的任何錯誤。 處理來源資料分割之後，工具嘗試查詢下一個可用的來源資料分割。 繼續處理下一個來源資料分割，直到所有資料都遷移為止。 此工具的原始程式碼位於 Azure Cosmos DB 大量擷取存放庫。
追蹤集合包含如下列範例所示的文件。 您將看到來源資料中的每個分區各有一份這樣的文件。 每份文件包含來源資料分割的中繼資料，例如位置、移轉狀態和錯誤 (若有)：
{
"owner": "25812@bulkimporttest07",
"jsonStoreEntityImportResponse": {
"numberOfDocumentsReceived": 446688,
"isError": false,
"totalRequestUnitsConsumed": 3950252.2800000003,
"errorInfo": [],
"totalTimeTakenInSeconds": 188,
"numberOfDocumentsImported": 446688
},
"storeType": "AZURE_BLOB",
"name": "sourceDataPartition",
"location": "sourceDataPartitionLocation",
"id": "sourceDataPartitionId",
"isInProgress": false,
"operation": "unpartitioned-writes",
"createDate": {
"seconds": 1561667225,
"nanos": 146000000
},
"completeDate": {
"seconds": 1561667515,
"nanos": 180000000
},
"isComplete": true
}
資料移轉的必要條件
資料移轉開始之前，請注意幾項必要條件：
估計資料大小：
來源資料大小可能不準確對應至 Azure Cosmos DB 中的資料大小。 可以從來源插入幾份樣本文件，以檢查在 Azure Cosmos DB 中的資料大小。 根據樣本文件大小，就能估計移轉之後 Azure Cosmos DB 中的資料大小總計。
例如，如果移轉之後 Azure Cosmos DB 中的每份文件大約 1 KB，而來源資料集大約有 600 億份文件，這表示 Azure Cosmos DB 中的估計大小接近 60 TB。
預先建立具備足夠 RU 的容器：
雖然 Azure Cosmos DB 會自動擴展儲存空間，但不建議從最小的容器大小開始。 容器愈小，可用的輸送量愈低，相對就需要更長的時間才能完成移轉。 相反，最好使用最終資料大小 (如上一步估計的那樣) 來建立容器，並確保遷移工作負載完全消耗已配置的傳輸量。
在前一步，由於資料大小估計約為 60 TB，因此需要至少 240 萬 RU 的容器來容納整個資料集。
估計移轉速度：
假設移轉工作負載可以耗用已佈建的全部輸送量，則從佈建的輸送量就能估計移轉速度。 延續前述範例，為 NoSQL 帳戶要將 1-KB 文件寫入至 Azure Cosmos DB API 需要五個 RU。 240 萬個 RU 每秒可以傳輸 480,000 份文件 (或 480 MB/秒)。 這表示 60 TB 的完整遷移需要 125,000 秒，約 34 小時。
如果想在一天之內完成移轉，則應該將佈建的輸送量增加到 500 萬個 RU。
停止編製索引：
由於遷移應盡快完成，建議盡量減少為每份文件建立索引的時間與資源。 Azure Cosmos DB 會自動索引所有屬性，建議在遷移過程中盡量減少索引到少數幾個詞，或完全關閉。 你可以透過將 indexingMode 變更為 none 如下所示，來關閉容器的索引策略。
{
"indexingMode": "none"
}
您可以在完成移轉之後再更新索引。
移轉程序
完成必要條件之後，您可以使用下列步驟來遷移資料：
首先，將資料從來源匯入 Azure Blob 儲存體。 為了加快遷移速度，跨不同來源分割區平行化會很有幫助。 開始移轉之前，應該將來源資料集分割成大約 200 MB 大小的檔案。
大量執行工具程式庫可以擴大，在單一用戶端 VM 中耗用 500,000 個 RU。 由於可用的輸送量為 500 萬個 RU，在您的 Azure Cosmos DB 資料庫所在的區域，應該佈建 10 個 Ubuntu 16.04 VM (Standard_D32_v3)。 您應該以移轉工具及其設定檔案來準備這些 VM。
在其中一部用戶端虛擬機器上，執行佇列步驟。 此步驟建立追蹤集合，掃描 ADLS 容器，並為每個來源資料集的分割檔建立進度追蹤文件。
接下來，在所有用戶端 VM 上執行匯入步驟。 每個用戶端都可以取得來源資料分割的所有權，並將資料內嵌至 Azure Cosmos DB。 完成後，狀態更新於追蹤集合中，客戶端即可查詢追蹤集合中下一個可用的來源分割區。
此流程持續到整組來源分割區塊都被導入為止。 處理所有來源資料分割之後，應該在相同的追蹤集合上以錯誤更正模式重新執行此工具。 此步驟是為了識別因錯誤而應重新處理的原始分割區。
其中一些錯誤可能起因於來源資料中的不正確文件。 應該查明並修正。 接下來，您應該在失敗分割區上重新執行匯入步驟，以重新內嵌分割區。
完成移轉之後，您可以驗證 Azure Cosmos DB 與來源資料庫中的文件計數是否一致。 在此範例中，Azure Cosmos DB 中的大小總計結果為 65 TB。 遷移後，索引功能可選擇性開啟，RU可降至工作負載操作所需的等級。
下一步
- 若要深入了解，請使用 .NET 和 JAVA 來試驗應用程式範例取用大量執行工具程式庫。
- 大量執行工具程式庫已整合至 Azure Cosmos DB Spark 連接器，若要深入了解，請參閱 Azure Cosmos DB Spark 連接器一文。
- 請透過「一般諮詢」問題類型及「大型（TB+）遷移」問題子類型，開啟支援單，聯繫 Azure Cosmos DB 產品團隊，以獲得更多大型遷移協助。
- 正在嘗試為遷移至 Azure Cosmos DB 進行容量規劃嗎？ 您可以使用現有資料庫叢集的相關資訊進行容量規劃。
- 如果您知道現有資料庫叢集中的虛擬核心和伺服器數目，請參閱使用虛擬核心或 vCPU 來估計要求單位
- 如果您知道目前資料庫工作負載的一般要求率，請參閱使用 Azure Cosmos DB 容量規劃工具來估計要求單位