移轉前步驟和考量事項
有數種方式可將現有的 MongoDB 資料庫和應用程式移轉適用於 MongoDB 的 Azure CosmoDB API 帳戶。 為確保移轉流程順暢,我們必須先對移轉流程進行一些預先規劃和決策,再實際移動任何資料。 在本單元中,我們會更詳細地檢視其中一些移轉前步驟。
移轉前概觀
我們最初的決策制定流程稱為「移轉前」。
此移轉前流程的目標是:
- 確定設定 Azure Cosmos DB 以滿足應用程式的需求。
- 規劃移轉的執行方式。
我們的移轉前流程分成下列四個步驟或階段。
- 移轉前探索 - 探索現有的 MongoDB 資源,並建立數據資產電子錶格來追蹤它們。
- 移轉前評估 - 評估現有 MongoDB 資源的整備程度以進行數據遷移。
- 移轉前對應 - 將現有的 MongoDB 資源對應至新的 Azure Cosmos DB 資源
- 遷移前物流規劃 - 在開始完整數據遷移之前,規劃遷移流程的物流。
遵循以下四個步驟可確保移轉成功。 讓我們進一步詳細討論這些階段。
注意
資料庫移轉小幫手 (DMA) 將協助您規劃的探索和評估階段。
移轉前探索
我們的第一個步驟是建立 數據資產移轉電子表格。 此試算表會:
- 包含 MongoDB 資料資產現有資源 (資料庫或集合) 的完整清單。
- 協助您規劃端對端移轉。
- 應該在整個移轉過程中當成追蹤文件使用。
雖然您可以手動探索,但在此單元中,建議您使用 資料庫移轉小幫手 (DMA) 協助您進行探索。 此工具容易使用,而且可為您執行許多工作。
DMA 會以程式設計方式建立資產移轉試算表。 我們將使用 Azure Data Studio 輕鬆地 安裝和使用 DMA 工具。 您只要在任何可存取來源 MongoDB 環境的機器上執行此工具即可。
DMA 會輸出下列檔案,供您作為資料資產移轉試算表使用。
- workload_database_details.csv - 顯示來源的資料庫層級檢視。
- workload_collection_details.csv - 顯示來源的集合層級檢視。
這些試算表會類似以下的試算表。
移轉前評量
完成探索之後,您必須瞭解目前 MongoDB 環境使用哪些功能,這些功能可能不受 目前的 MongoDB 版本 Azure Cosmos DB for MongoDB 的支援。 您也需要記住 Azure Cosmos DB 限制和配額。 完成此評估後,您將能在剩餘的移轉規劃期間,視需要處理這些結果。
而我們也會再次使用 DMA 協助收集此階段所需要的資料。 DMA 會針對來源 MongoDB 的資源執行,並列出繼續進行移轉所需的必要和建議變更。 此數據會寫入 assessment_result.csv 檔案。
移轉前對應
探索和評估都是關於 MongoDB 來源,現在是時候在接下來的這兩個階段中移至我們的 Azure Cosmos DB 端。 讓我們從容量規劃開始。
容量規劃
我們可以透過兩種方式之一來執行一些容量規劃。
將虛擬核心轉換為 RU。 - 如果我們知道的唯一資訊是目前 MongoDB 環境中的伺服器數目或虛擬核心數目,我們可以將這些虛擬核心轉換成 RU。 在上一個單元中, 將虛擬核心轉換為 RU,我們更詳細地瞭解如何使用虛擬核心或 vCPU 來估計要求單位。
使用Azure Cosmos DB容量規劃工具。 如果我們能清楚掌握資料量以及每秒執行的 CRUD 作業數目,就可以使用容量計算機來估計需要的 RU/秒數目。 在上一個課程模組中,我們會在 [使用 Azure Cosmos DB 容量計算機的容量估計][/training/modules/get-started-mongodb-api-azure-cosmos-db/5-capacity-estimation-use-calculator] 單元下詳細討論此主題。
注意
您也可以使用 Azure Cosmos DB 容量計算機 來估計新 Azure Cosmos DB 資源的擁有成本。
評估輸送量
如上述的容量規劃一節所述,我們可以使用 Azure Cosmos DB 容量計算機 來估計我們需要的 RU/秒,或在移轉前將虛擬核心轉換為 RU 來估計 RU。 但是,一旦資料進入 Azure Cosmos DB,我們該如何判斷查詢的實際成本?
一旦我們的數據位於 Azure Cosmos DB 集合中,我們就可以進一步瞭解我們的查詢成本,方法是使用 MongoDB Shell,以及使用 getLastRequestStastistics 命令來取得要求費用。 我們會先在 MongoDB 殼層中執行查詢,並緊接著執行下列命令取得這些 RU 統計資料。
db.runCommand({getLastRequestStatistics: 1})
還有一種方式可以檢閱查詢效能,就是使用 Azure 監視器。 我們會在下個課程模組複寫及監視 Azure Cosmos DB for MongoDB 帳戶中詳細討論此主題。
規劃 Azure Cosmos DB 資料資產
現在可以使用我們用 DMA 建立的工作負載詳細資料試算表了。 我們現在必須將每項 MongoDB 資源對應至新的 Azure Cosmos DB 資源。 若要這樣做,我們應該:
將每個 MongoDB 資料庫對應至 Azure Cosmos DB 資料庫。
將每個 MongoDB 集合對應至 Azure Cosmos DB 集合。
可能的話,請使用相同的資源名稱。
判斷要在 Azure Cosmos DB 中使用分區集合還是未分區集合。 分區可協助您水平縮放,這對許多工作負載的效能至關重要。 請記住,未分區集合的每個集合限制為 20 GB。
如果使用分區集合,Azure Cosmos DB 就只關乎效能。 使用最適合您工作負載的正確分區索引鍵即可達成。 也就是說,我們的 Azure Cosmos DB 分區索引鍵可能與您在 MongoDB 環境中使用的集合分區索引鍵不同。
注意
分區索引鍵是最佳化 Azure Cosmos DB 可擴縮性和效能最重要的一個設定,而資料模型化是第二重要的設定。 這兩個都是不可變的設定,一旦設定後就無法變更;因此,在規劃階段就將其最佳化非常重要。
Azure Cosmos DB 有自己的兩種集合 – 共用和專屬輸送量。
注意
共用與專用輸送量是另一個重要、不可變的決策,必須在規劃階段做出此決策。
注意
需要可預測效能的集合應有專用的輸送量,而不是共用輸送量。 使用共用輸送量的集合應約等於要求和儲存體的需求。
有些決策是永久的
不可變的決策。 是時候做出數個設計決策了,不僅因為我們需要正確規劃移轉,也因為我們無法在建立資源後變更其中部分設定。 為協助我們做出無法變更的正確選擇,我們應該:
選擇最佳的分區索引鍵 - 一旦建立集合,就無法變更分區索引鍵,因此我們必須從一開始就選擇正確的分區索引鍵。 在我們挑選適用於集合的分區索引鍵後,Azure Cosmos DB 就會管理集合的水平成長。 在上一個課程模組中,我們會在 Models和Shard keys 單元下詳細探討此主題。 如果您想要深入瞭解此主題,請參閱 Azure Cosmos DB 中的數據分割和水平調整 一文和 選擇分割區索引鍵 一文。 請記住,分區化也稱為資料分割。
選擇正確的模型 - 同樣地,我們在上一個課程模組的 Models 和分區索引鍵 單元中更詳細地討論了此主題。 如需詳細資訊,請參閱 Azure Cosmos DB 中的數據模型 化一文。
針對您要移轉的每個資源,選擇專用和共用輸送量 - 如需詳細資訊,請參閱 優化 Azure Cosmos DB 中的布建輸送量成本 一文。
提示
如果您想要檢閱如何模型化和分割數據的實際範例,請參閱 如何使用真實世界的範例文章,在 Azure Cosmos DB 上建立模型和數據分割 。
移轉前後勤規劃
我們已收集、對應 Azure Cosmos DB 的資源並建立其模型,現在該規劃真正的移轉執行作業。
執行後勤作業
我們需要回答一些問題。
- 誰正在進行移轉? - 視移轉的大小而定,您不僅需要指派一或多個人移轉資源,還要指派一或多個人監視要移轉之每項資源的移轉進度。
- 您要用來進行移轉的工具是什麼? - 我們有許多工具可用於線上或離線執行移轉。 這些工具包括原生 MongoDB 工具和 Azure 服務,例如 Azure 資料移轉服務 (DMS)、Azure Data Factory (ADF) 或 Azure Databricks 和 Spark。 在後續兩節中,我們將詳細說明將 MongoDB 資料庫移轉至 Azure Cosmos DB 時可使用的工具。
- 我們應該以何種順序移轉資源? - 決定優先移轉的項目可讓您依排程執行移轉作業。 最佳做法是優先移轉需要最多移動時間的資源;先移轉這些資源會帶來最多的完成進度。 因為這些通常是您包含最多資料的較大資源,所以先移轉這些資源還可提早發現任何移轉問題。
- 您要如何監視移轉程式? - 您必須與小組就監視流程合作,以便全面掌握高優先順序移轉項目的進度。
支援的移轉案例
MongoDB 移轉工具的最佳選擇取決於移轉情節。
每個移轉情節的相容工具如下所示:
| 來源 | 目的地 | 流程建議 |
|---|---|---|
|
離線 • MongoDB 內部部署叢集 • MongoDB IaaS VM 叢集 • MongoDB Atlas 叢集 |
Azure Cosmos DB Mongo API | • <10-GB 資料:MongoDB 原生工具 • < 1-TB 資料:Azure DMS • > 1-TB 資料:Spark |
|
在線 • MongoDB 內部部署叢集 • MongoDB IaaS VM 叢集 • MongoDB Atlas 叢集 |
Azure Cosmos DB Mongo API | • < 1-TB 資料:Azure DMS • > 1-TB 資料:Spark + Mongo ChangeStream |
| • 需要在移轉期間變更結構描述 • 需要比上述工具更多的彈性 |
Azure Cosmos DB Mongo API | • ADF 比 DMS 更有彈性,其支援在移轉期間修改結構描述,並支援大部分的來源/目的地組合。 • DMS 在縮放方面的表現更好,例如移轉更快速。 |
| JSON 檔案 | Azure Cosmos DB Mongo API | MongoDB 原生工具,特別是 mongoimport。 |
| CSV 檔案 | Azure Cosmos DB Mongo API | MongoDB 原生工具,特別是 mongoimport。 |
| BSON 檔案 | Azure Cosmos DB Mongo API | MongoDB 原生工具,特別是 mongorestore。 |
如果您是從特定的 MongoDB 版本進行移轉,支援的工具如下所示:
| Mongo 來源版本 | Azure Cosmos DB Mongo API 目的地版本 | 支援的工具 | 不支援的工具 |
|---|---|---|---|
| < 2.x、> 4.0 | 3.2, 3.6, 4.0 | MongoDB 原生工具、Spark | DMS、ADF |
| 3.2, 3.6. 4.0 | 3.2, 3.6, 4.0 | MongoDB 原生工具、DMF、ADF、Spark | 無 |
移轉後
在移轉前階段,請花一些時間詳述移轉後步驟。
需採取的步驟:
完全移轉應用程式:您應該將應用程式重新指向 Azure Cosmos DB 環境。
規劃遷移後的配置 - 應該規劃索引編製、全域散發和一致性等方面。 請注意,這些設定通常會臨時變更,而且最可能在集合存留期間變更,但建議為這些設定規劃移轉一完成後的所在位置。
提示
如需移轉后的詳細資訊,請參閱 使用適用於 MongoDB 的 Azure Cosmos DB API 時的移轉後優化步驟 指南。
移轉 MongoDB 資料庫不是一鍵完成的作業。 建議您花一些時間好好規劃移轉作業。 在接下來的幾個章節中,我們將進一步討論實際的移轉步驟本身。