共用方式為

將資料從 MongoDB 移轉至 Azure Cosmos DB for MongoDB 的預先移轉步驟

  • 發行項

適用於： MongoDB

重要

請先閱讀本指南，然後再執行您的移轉前步驟。

此 MongoDB 移轉前指南是 MongoDB 移轉系列的一部分。 重要的 MongoDB 移轉步驟分為移轉前、移轉和移轉後，如本指南所示。

圖表顯示移轉前後的移轉步驟。

移轉前的概觀

在您實際移動任何資料之前，請務必先執行您移轉的一些前期規劃和決策。 這項初始決策制定程序是「移轉前」。

移轉前的目標是：

  1. 確定您已設定 Azure Cosmos DB 以滿足應用程式的需求，以及
  2. 規劃您將如何執行移轉。

遵循下列步驟以執行完整的移轉前程序

  1. 探索現有的 MongoDB 資源，並評估現有 MongoDB 資源的整備程度以進行資料移轉
  2. 將現有的 MongoDB 資源對應至新的 Azure Cosmos DB 資源
  3. 在開始進行完整規模的資料移轉之前，請先規劃端對端的移轉程序物流

然後，根據移轉前方案來執行移轉。

最後，執行完全移轉和最佳化的重要移轉後步驟。

上述所有步驟都是確保成功移轉的關鍵。

當您規劃移轉時，建議您盡可能規劃每個資源等級。

移轉前評量

第一個移轉前步驟是探索現有的 MongoDB 資源，並評估資源的移轉整備程度。

探索涉及在您的 MongoDB 資料資產中建立現有資源 (資料庫或集合) 的完整清單。

評量涉及釐清您是否使用支援的功能和語法。 這也包含確保您遵守限制和配額。 此階段的目標是建立不相容和警告的清單 (若有)。 取得評量結果之後，您可以嘗試處理移轉規劃剩餘部分期間的結果。

有 3 種方式可以完成移轉前評估，建議您使用適用於 MongoDB 的 Azure Cosmos DB 移轉延伸模組。

適用於 MongoDB 的 Azure Cosmos DB 移轉延伸模組

Azure Data Studio 中適用於 MongoDB 的 Azure Cosmos DB 移轉延伸模組可協助您評估 MongoDB 工作負載，以移轉至 Azure Cosmos DB for MongoDB。 您可以使用此延伸模組對您的工作負載執行端對端評估，並找出順暢地在 Azure Cosmos DB 上移轉工作負載可能需要採取的動作。 在評估 MongoDB 端點期間，此延伸模組會報告所有探索到的資源。

注意

建議您詳細了解支援的功能和語法、Azure Cosmos DB 限制和配額，以及在實際移轉之前執行概念證明。

手動探索 (舊版)

或者，您可以建立資料資產移轉試算表。 此試算表的目的是要提升您的生產力，並協助您規劃端對端的移轉，並在移轉過程中將其作為追蹤文件。

  • 此工作表包含 MongoDB 資料資產中現有資源 (資料庫或集合) 的完整清單。
  • 此試算表的結構應以清單形式記錄資料資產資源。
  • 每個資料列都會對應至資源 (資料庫或集合)。
  • 每個資料行都會對應至資源的屬性；至少會以名稱和資料大小 (GB) 資料行開頭。
  • 當您進行本指南時，您將在追蹤文件中建立此試算表以便進行端對端移轉規劃，並視需要新增資料行。

以下是您可以用來探索資源的一些工具：

查看試算表，並根據支援的功能和語法以及 Azure Cosmos DB 限制和配額仔細確認每個集合。

資料庫移轉小幫手公用程式 (舊版)

注意

資料庫移轉小幫手是一個舊版公用程式，旨在協助您進行移轉前步驟。 如需所有移轉前步驟，建議您參考適用於 MongoDB 的 Azure Cosmos DB 移轉延伸模組。

您可以利用資料庫移轉小幫手 (DMA) 公用程式來進行移轉前步驟。

移轉前對應

完成探索和評量步驟之後，您就可以完成方程式的 MongoDB 端。 現在是時候規劃方程式的 Azure Cosmos DB 端。 您預計要如何設定生產 Azure Cosmos DB 資源？ 在每個資源等級進行規劃，這表示您應該將下列資料行新增至規劃試算表：

  • Azure Cosmos DB 對應
  • 分區金鑰
  • 資料模型
  • 專用與共用輸送量

下列各節提供詳細資料。

產能規劃

正在嘗試為遷移至 Azure Cosmos DB 進行容量規劃嗎？

使用適用於 MongoDB 的 Azure Cosmos DB API 的考量事項

規劃 Azure Cosmos DB 資料資產之前，請確定您瞭解下列 Azure Cosmos DB 概念：

  • 容量模型：Azure Cosmos DB 的資料庫容量是以輸送量為基礎的模型作為根據。 此模型是以每秒要求單位為基礎，此單位表示每秒鐘可對一個集合所執行的資料庫作業數目。 此容量可以在資料庫或集合層級進行配置，而且可以在配置模型上佈建容量，或使用自動調整佈建輸送量。
  • 要求單位：每個資料庫作業在 Azure Cosmos DB 中都有相關聯的要求單位 (RU) 成本。 執行時，會從給定秒數的可用要求單位層級減去這些要求單位。 如果要求所需的 RU 超過目前配置的 RU/秒，有兩個選項可解決此問題 - 增加 RU 數目，或等到下一秒開始後再重試作業。
  • 彈性容量：給定集合或資料庫的容量可隨時變更。 此彈性讓資料庫可彈性因應工作負載的輸送量需求。
  • 自動分區化：Azure Cosmos DB 提供一個只需要分區 (或分割區索引鍵) 的自動資料分割系統。 自動資料分割機制會在所有 Azure Cosmos DB API 之間共用，可透過水平發佈，順暢地進行資料和輸送量調整。

規劃 Azure Cosmos DB 資料資產

確認您要建立哪些 Azure Cosmos DB 資源。 此程序必須逐步執行資料資產移轉試算表，並將每個現有的 MongoDB 資源對應至新的 Azure Cosmos DB 資源。

  • 預期每個 MongoDB 資料庫都會變成 Azure Cosmos DB 資料庫。
  • 預期每個 MongoDB 集合都會變成 Azure Cosmos DB 集合。
  • 選擇 Azure Cosmos DB 資源的命名慣例。 保留相同的資源名稱通常是不錯的選擇，除非資料庫和集合結構有任何變更。
  • 確認您要在 Cosmos DB 中使用分區化還是未分區化集合。 未分區化集合限制為 20 GB。 另一方面，分區化有助於達到對許多工作負載效能至關重要的水準調整。
  • 如果使用分區化集合，請勿假設 MongoDB 集合分區索引鍵會成為 Azure Cosmos DB 容器分割區索引鍵。 請勿假設您現有的 MongoDB 資料模型文件結構應該是您在 Azure Cosmos DB 上採用的相同模型。
    • 分區索引鍵是最佳化 Azure Cosmos DB 可擴縮性和效能最重要的一個設定，而資料模型化是第二重要的設定。 這兩個設定都是不可變的，而且在設定之後就無法變更；因此，在規劃階段將這兩個設定最佳化是非常重要的。 如需詳細資訊，請遵循不可變的決策一節中的指導方針。
  • Azure Cosmos DB 無法辨識特定的 MongoDB 集合類型，例如受限的集合。 針對這些資源，您只需建立一般 Azure Cosmos DB 集合。
  • Azure Cosmos DB 有自己的兩種集合 – 共用和專屬輸送量。 共用和專用輸送量是另一項重要且不可變的決策，在規劃階段中做出這個決策是很重要的。 如需詳細資訊，請遵循不可變的決策一節中的指導方針。

不可變的決策

當您建立 Azure Cosmos DB 資源之後，就無法修改或復原下列 Azure Cosmos DB 設定選項；因此，在開始進行任何移轉之前，請務必在移轉前規劃期間完成這些設定選項：

擁有權成本

評估輸送量

  • 在 Azure Cosmos DB 中，系統會事先佈建輸送量，並以每秒的要求單位 (RU) 進行測量。 不同於 VM 或內部部署伺服器，RU 可以輕鬆地隨時擴大或縮小。 您可以立即變更佈建的 RU 數目。 如需詳細資訊，請參閱 Azure Cosmos DB 中的要求單位。

  • 您可以使用 Azure Cosmos DB 容量計算機來判斷您所應使用的要求單位數目。 此數目以您的資料庫帳戶設定、資料量、文件大小，以及每秒所需的讀取和寫入數為基礎。

  • 以下是影響所需 RU 數量的重要因素：

    • 文件大小：當項目/文件大小增加時，用來讀取或寫入該項目/文件的 RU 數目也會增加。

    • 文件屬性計數：建立或更新文件所耗用的 RU 數目，與數量、複雜性及其屬性長度有關。 您可以藉由限制已編製索引的屬性數目，來減少寫入作業的要求單位取用量。

    • 查詢模式：查詢的複雜度會影響到查詢所取用的要求單位數目。

  • 了解查詢成本的最佳方式是，使用 Azure Cosmos DB 中的樣本資料，並使用 getLastRequestStastistics 命令，從 MongoDB Shell 執行樣本查詢，以取得要求費用，這將會輸出取用的 RU 數量：

    db.runCommand({getLastRequestStatistics: 1})

    *此命令會輸出類似於下列範例的 JSON 文件：

    {
  "_t": "GetRequestStatisticsResponse",
  "ok": 1,
  "CommandName": "find",
  "RequestCharge": 10.1,
  "RequestDurationInMilliSeconds": 7.2
}

  • 您也可以使用診斷設定，以了解針對 Azure Cosmos DB 執行查詢的頻率和模式。 診斷記錄的結果可傳送至儲存體帳戶、事件中樞執行個體或 Azure Log Analytics。

移轉前後勤規劃

最後，現在您已了解現有的資料資產，以及新 Azure Cosmos DB 資料資產的設計，您就做好準備，可規劃如何從端對端執行移轉程序。 同樣地，請在每個資源等級進行規劃，並將資料行新增至試算表，以擷取本節中包含的物流維度。

執行物流

  • 指派將每個現有資源從 MongoDB 移轉至 Azure Cosmos DB 的責任。 運用小組資源來帶領移轉完成的方式取決於您。 針對小規模的移轉，您可以讓一個小組開始整個移轉，並監視其進度。 針對較大型的移轉，您可以依每個資源為小組成員指派責任，以移轉和監視該資源。

  • 一旦您指派了移轉資源的責任，現在您應該選擇適當的移轉工具來進行移轉。 針對小規模的移轉，您可以使用一個移轉工具 (例如 MongoDB 原生工具或 Azure DMS) 來一次移轉所有資源。 針對較大的移轉或具有特殊需求的移轉，您可能會想要以每個資源的細微性來選擇移轉工具。

  • 一旦為每個資源選擇了移轉工具之後，下一個步驟就是設定您要移轉的資源優先順序。 良好的優先順序有助於依排程進行移轉。 最好的做法是，優先移轉需要最多移動時間的資源；先移轉這些資源會帶來最大的完成進度。 此外，由於這些耗時的移轉通常會牽涉到更多資料，因此會耗用更多移轉工具的資源，因此更可能在初期暴露移轉管道的任何問題。 此做法可將因為任何移轉管道困難而使得排程滑動的機率降到最低。

  • 規劃您在移轉啟動後要如何監視其進度。 如果您正在小組之間協調資料移轉工作，請一併規劃定期團隊同步，讓您充分掌握高優先順序移轉的進展。

支援的移轉案例

MongoDB 移轉工具的最佳選擇取決於移轉情節。

移轉類型

以下列出每個移轉案例的相容工具：

來源 Destination 程序建議
• MongoDB 內部部署叢集
• IaaS VM 叢集上的 MongoDB
• MongoDB Atlas 叢集 - 離線		 Azure Cosmos DB Mongo API • <10-GB 資料：MongoDB 原生工具
• < 1 TB 資料：Azure DMS
• > 1-TB 資料：Spark
• MongoDB 內部部署叢集
• IaaS VM 叢集上的 MongoDB
• 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 版本的工具支援

假設您要從特定 MongoDB 版本移轉，此處包含每個版本的支援工具，供您參考：

MongoDB 來源版本 Azure Cosmos DB for MongoDB 目的地版本 支援的工具 不支援的工具
<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 原生工具、DMS、ADF、Spark 無

移轉後

在移轉前階段，請花一些時間來規劃您要採取哪些步驟來進行應用程式移轉和移轉後最佳化。

  • 在移轉後階段中，您會執行應用程式的轉換，以使用 Azure Cosmos DB (而非現有的 MongoDB 資料資產)。
  • 盡可能妥善地在個別資源層級規劃索引編製、全域散發、一致性和其他可變動 Azure Cosmos DB 屬性。 不過，這些 Azure Cosmos DB 組態設定可於稍後修改，因此可規劃稍後再調整這些設定。 您會在移轉後套用這些可變動設定。
  • 針對移轉後指南，請參閱使用適用於 MongoDB 的 Azure Cosmos DB API 時的移轉後最佳化步驟。

下一步