Vorbereitende Schritte für Datenmigrationen von MongoDB zu Azure Cosmos DB for MongoDB

Artikel
08/15/2024

GILT FÜR: MongoDB

Wichtig

Lesen Sie bitte diesen gesamten Leitfaden, bevor Sie Ihre vorbereitenden Schritte für die Migration ausführen.

Dieser MongoDB-Leitfaden für die Migrationsvorbereitung ist ein Teil der Reihe zur MongoDB-Migration. Die kritischen MongoDB-Migrationsschritte umfassen die Migrationsvorbereitung, die Migration und die Migrationsnachbereitung, wie in dieser Anleitung aufgezeigt.

Diagramm der Migrationsschritte von vor der Migration zu nach der Migration.

Eine Übersicht der Migrationsvorbereitung

Es ist wichtig, im Vorfeld eine bestimmte Planung und Entscheidungsfindung für Ihre Migration durchzuführen, bevor Sie tatsächlich Daten verschieben. Dieser anfängliche Entscheidungsprozess ist die „Migrationsvorbereitung“.

Ihr Ziel bei der Migrationsvorbereitung besteht darin, Folgendes zu erreichen:

Sicherstellen, dass Sie Azure Cosmos DB einrichten, um die Anforderungen Ihrer Anwendung zu erfüllen, und
Planen Sie, wie Sie die Migration durchführen.

Führen Sie diese Schritte aus, um eine umfassende Migrationsvorbereitung durchzuführen

Ermitteln Sie Ihre vorhandenen MongoDB-Ressourcen und bewerten Sie die Bereitschaft Ihrer vorhandenen MongoDB-Ressourcen für die Datenmigration
Ordnen Sie Ihre vorhandenen MongoDB-Ressourcen den neuen Azure Cosmos DB Ressourcen zu
Planen Sie die Logistik des End-to-End Migrationsprozesses, bevor Sie mit der vollständigen Datenmigration beginnen

Führen Sie ihre Migration dann in Übereinstimmung mit Ihrem Migrationsvorbereitungsplan aus.

Führen Sie abschließend die wichtigen Schritte der Migrationsnachbereitung wie die Übernahme und die Optimierung durch.

Alle der oben genannten Schritte sind wichtig, um eine erfolgreiche Migration sicherzustellen.

Wenn Sie eine Migration planen, wird empfohlen, dass Sie, nach Möglichkeit, auf der Ebene einzelner Ressourcen planen.

Die Migrationsvorbereitungsbewertung

Der erste Schritt vor der Migration besteht darin, Ihre vorhandenen MongoDB-Ressourcen zu ermitteln und die Bereitschaft Ihrer Ressourcen für die Migration zu bewerten.

Bei der Ermittlung muss eine umfassende Liste der vorhandenen Ressourcen (Datenbanken oder Sammlungen) in Ihrem MongoDB-Datenbestand erstellt werden.

Die Bewertung umfasst die Ermittlung, ob Sie die Features und die Syntax verwenden, die unterstützt werden. Sie stellt außerdem sicher, dass Sie die Grenzwerte und Kontingente einhalten. Ziel dieser Phase ist es, eine Liste von Inkompatibilitäten und Warnungen zu erstellen, sofern vorhanden. Nachdem Ihnen die Bewertungsergebnisse vorliegen, können Sie versuchen, die Ergebnisse im weiteren Verlauf der Migrationsplanung zu berücksichtigen.

Es gibt drei Möglichkeiten, die Bewertung vor der Migration abzuschließen. Es wird empfohlen, die Azure Cosmos DB Migration für MongoDB-Erweiterung zu verwenden.

Erweiterung für die Azure Cosmos DB-Migration für MongoDB

Die Erweiterung für die Azure Cosmos DB-Migration for MongoDB in Azure Data Studio hilft Ihnen bei der Bewertung einer MongoDB-Workload für die Migration zu Azure Cosmos DB for MongoDB. Sie können diese Erweiterung verwenden, um eine End-to-End-Bewertung für Ihre Workload auszuführen und die Aktionen zu ermitteln, die Sie durchführen müssen, um Ihre Workloads nahtlos zu Azure Cosmos DB zu migrieren. Während der Bewertung eines MongoDB-Endpunkts meldet die Erweiterung alle ermittelten Ressourcen.

Hinweis

Wir empfehlen Ihnen, die unterstützten Funktionen und die Syntax, Azure Cosmos DB-Grenzwerte und -Kontingente im Detail durchzugehen sowie vor der eigentlichen Migration einen Proof of Concept durchzuführen.

Manuelle Ermittlung (Legacy)

Alternativ können Sie eine Datenbestandsmigrationstabelle erstellen. Der Zweck dieser Tabelle besteht darin, Ihre Produktivität zu steigern und Ihnen zu helfen, die Migration von End-to-End zu planen und als Nachverfolgungsdokument während des gesamten Migrationsprozesses zu verwenden.

Diese Tabelle enthält eine umfassende Liste der vorhandenen Ressourcen (Datenbanken oder Sammlungen) in Ihrem MongoDB-Datenbestand.
Diese Tabelle sollte als ein Datensatz Ihrer Datenbestandsressourcen in Listenform strukturiert werden.
Jede Zeile entspricht einer Ressource (Datenbank oder Sammlung).
Jede Spalte entspricht einer Eigenschaft der Ressource; beginnen Sie mit mindestens Name und Datengröße (GB) als Spalten.
Während Sie diesen Leitfadens durcharbeiten, werden Sie dieses Arbeitsblatt in ein Nachverfolgungsdokument für Ihre End-to-End-Migrationsplanung umbauen und nach Bedarf Spalten hinzufügen.

Hier sind einige Tools, die Sie zum Ermitteln von den Ressourcen verwenden können:

Gehen Sie die Tabelle durch, und überprüfen Sie jede Sammlung anhand der unterstützten Features und Syntax sowie der Grenzwerte und Kontingente von Azure Cosmos DB im Detail.

Hilfsprogramm des Datenbankmigrations-Assistenten (Legacy)

Hinweis

Der Datenbankmigrations-Assistent ist ein Legacy-Hilfsprogramm, das Sie bei den Schritten vor der Migration unterstützen soll. Wir empfehlen Ihnen, die Erweiterung Azure Cosmos DB Migration for MongoDB für alle Schritte vor der Migration zu verwenden.

Sie können das Hilfsprogramm Datenbankmigrations-Assistent (DMA) verwenden, um Sie bei den Schritten vor der Migration zu unterstützen.

Die Zuordnung der Migrationsvorbereitung

Wenn die Ermittlungs- und Bewertungsschritte abgeschlossen sind, sind Sie mit der MongoDB-Seite der Gleichung fertig. Jetzt ist es Zeit, die Azure Cosmos DB-Seite der Gleichung zu planen. Wie planen Sie, Ihre Produktionsressourcen für Azure Cosmos DB einzurichten und zu konfigurieren? Führen Sie Ihre Planung auf einzelnen Ressourcenebenen durch. Das bedeutet, dass Sie Ihrer Planungstabelle die folgenden Spalten hinzufügen sollten:

Azure Cosmos DB-Zuordnung
Shardschlüssel
Datenmodell
Der Dedizierte und gemeinsam genutzter Durchsatz im Vergleich

Weitere Details hierzu finden Sie in den folgenden Abschnitten.

Kapazitätsplanung

Versuchen Sie, die Kapazitätsplanung für eine Migration zu Azure Cosmos DB durchzuführen?

Wenn Sie lediglich die Anzahl der virtuellen Kerne und Server in Ihrem vorhandenen Datenbankcluster kennen, lesen Sie die Informationen zum Schätzen von Anforderungseinheiten mithilfe von virtuellen Kernen oder virtuellen CPUs.
Wenn Sie die typischen Anforderungsraten für Ihre aktuelle Datenbankworkload kennen, lesen Sie die Informationen zum Schätzen von Anforderungseinheiten mit dem Azure Cosmos DB-Kapazitätsplaner

Aspekte beim Verwenden der Azure Cosmos DB-API für MongoDB

Bevor Sie Ihren Azure Cosmos DB-Datenbestand planen, stellen Sie sicher, dass Sie die folgenden Azure Cosmos DB-Konzepte verstehen:

Kapazitätsmodell: Die Datenbankkapazität in Azure Cosmos DB basiert auf einem durchsatzbasierten Modell. Dieses Modell basiert auf Anforderungseinheiten pro Sekunde. Dabei handelt es sich um eine Einheit, die die Anzahl von Datenbankvorgängen darstellt, die pro Sekunde für eine Sammlung ausgeführt werden können. Diese Kapazität kann auf Datenbank- oder Sammlungsebene zugeordnet werden, und sie kann in einem Zuordnungsmodell oder mithilfe des per Autoskalierung bereitgestellten Durchsatzes bereitgestellt werden.
Anforderungseinheiten: In Azure Cosmos DB sind jedem Datenbankvorgang Kosten für Anforderungseinheiten (Request Units, RUs) zugeordnet. Bei der Ausführung werden die Anforderungseinheiten von der Ebene der verfügbaren Anforderungseinheiten für eine bestimmte Sekunde subtrahiert. Wenn für eine Anforderung mehr RUs als die aktuell zugeordneten RU/s erforderlich sind, gibt es zwei Möglichkeiten, das Problem zu beheben: Erhöhen Sie die Anzahl von RUs, oder warten Sie, bis die nächste Sekunde beginnt, und wiederholen Sie dann den Vorgang.
Elastische Kapazität: Die Kapazität für eine bestimmte Sammlung oder Datenbank kann sich jederzeit ändern. Diese Flexibilität erlaubt der Datenbank, sich elastisch an die Durchsatzanforderungen Ihrer Workload anzupassen.
Automatisches Sharding: Azure Cosmos DB bietet ein automatisches Partitionierungssystem, das nur einen Shard (oder einen Partitionsschlüssel) erfordert. Der automatische Partitionierungsmechanismus wird von allen Azure Cosmos DB-APIs gemeinsam genutzt und ermöglicht nahtlose Daten und die gesamte Skalierung durch horizontale Verteilung.

Planen Sie den Azure Cosmos DB-Datenbestand

Finden Sie heraus, welche Azure Cosmos DB-Ressourcen Sie erstellen. Dieser Prozess erfordert, dass Sie Ihr Arbeitsblatt für die Datenbestandsmigration schrittweise durchgehen und jede vorhandene MongoDB-Ressource einer neuen Azure Cosmos DB-Ressource zuordnen.

Gehen Sie davon aus, dass jede MongoDB-Datenbank zu einer Azure Cosmos DB-Datenbank wird.
Gehen Sie davon aus, dass jede MongoDB-Sammlung eine Azure Cosmos DB-Sammlung wird.
Wählen Sie eine Namenskonvention für Ihre Azure Cosmos DB-Ressourcen aus. Die Beibehaltung der gleichen Ressourcennamen ist in der Regel eine gute Wahl, es sei denn, es gibt Änderungen an der Struktur von Datenbanken und Sammlungen.
Bestimmen Sie, ob Sie horizontal partitionierte oder nicht horizontal partitionierte Sammlungen in Azure Cosmos DB verwenden. Der Grenzwert für nicht horizontal partitionierte Sammlungen beträgt 20 GB. Sharding hilft andererseits, horizontale Skalierung zu erzielen, die für die Leistung vieler Workloads von entscheidender Bedeutung ist.
Wenn Sie horizontal partitionierte Sammlungen verwenden, gehen Sie nicht davon aus, dass der Shard-Schlüssel Ihrer Ihr MongoDB-Sammlung zum Partitionsschlüssel Ihrer Azure Cosmos DB-Container wird. Gehen Sie nicht davon aus, dass Ihre vorhandene Dokumentstruktur des MongoDB-Datenmodells dasselbe Modell sein sollte, das Sie auf Azure Cosmos DB verwenden.
- Der Shard-Schlüssel ist die wichtigste Einstellung zum Optimieren der Skalierbarkeit und Leistung von der Azure Cosmos DB. Die Datenmodellierung ist die zweit wichtigste Einstellung. Beide Einstellungen sind unveränderlich und können nicht mehr geändert werden, nachdem sie festgelegt wurden. Es ist daher äußerst wichtig, diese bereits in der Planungsphase zu optimieren. Für weitere Informationen, befolgen Sie die Anleitung im Abschnitt Unveränderliche Entscheidungen.
Azure Cosmos DB erkennt bestimmte MongoDB-Sammlungstypen wie z. B. die Sammlungen mit festen Größen (Capped Collections) nicht. Erstellen Sie für diese Ressourcen einfach normale Azure Cosmos DB Sammlungen.
Azure Cosmos DB verfügt über zwei eigene Sammlungstypen: den gemeinsam genutzten und den dedizierten Durchsatz. Gemeinsamer oder dedizierter Durchsatz ist eine weitere kritische, unveränderliche Entscheidung, die unbedingt in der Planungsphase getroffen werden muss. Für weitere Informationen, befolgen Sie die Anleitung im Abschnitt Unveränderliche Entscheidungen.

Die Unveränderlichen Entscheidungen

Die folgenden Azure Cosmos DB-Konfigurationsentscheidungen können nicht mehr geändert oder rückgängig gemacht werden, nachdem Sie eine Azure Cosmos DB-Ressource erstellt haben. Daher ist es wichtig, diese Konfigurationsentscheidungen bei der Planung vor der Migration richtig zu treffen, bevor Sie mit den Migrationen loslegen:

Weitere Informationen zum Auswählen des besten Shard-Schlüssels finden Sie unter Partitionierung und horizontale Skalierung in Azure Cosmos DB. Die Partitionierung (auch als Sharding bezeichnet) ist ein wichtiger Aspekt, den Sie vor dem Migrieren von Daten berücksichtigen müssen. Azure Cosmos DB verwendet die vollständig verwaltete Partitionierung, um die Kapazität in einer Datenbank zur Erfüllung der Speicher- und Durchsatzanforderungen zu erhöhen. Diese Funktion erfordert weder das Hosting noch die Konfiguration von Routingservern.
- Auf ähnliche Weise fügt die Partitionierungsfunktion automatisch Kapazität hinzu und gleicht die Daten entsprechend neu aus. Weitere Informationen zur Wahl des richtigen Partitionsschlüssels für Ihre Daten finden Sie unter Auswählen eines Partitionsschlüssels.
Verwenden Sie den Leitfaden für Datenmodellierung in Azure Cosmos DB, um ein Datenmodell auszuwählen.
Befolgen Sie die Anleitungen unter Optimieren der Kosten für bereitgestellten Durchsatz in Azure Cosmos DB, um zwischen dediziertem und gemeinsamem Durchsatz für jede Ressource auszuwählen, die Sie migrieren
Modellieren und Partitionieren von Daten in Azure Cosmos DB anhand eines realen Beispiels ist ein reales Beispiel für Sharding und Datenmodellierung, das Ihnen bei Ihrer Entscheidungsfindung helfen soll.

Die Betriebskosten

Schätzen Sie die Betriebskosten Ihrer neuen Azure Cosmos DB Ressourcen mithilfe des Azure Cosmos DB-Kapazitätsrechners.

Das Schätzen des Durchsatzes

In Azure Cosmos DB wird der Durchsatz vorab bereitgestellt und in Anforderungseinheiten (RU) pro Sekunde gemessen. Im Gegensatz zu VMs oder lokalen Servern können RUs jederzeit einfach hoch- und herunterskaliert werden. Sie können die Anzahl der bereitgestellten RUs sofort ändern. Weitere Informationen finden Sie unter Anforderungseinheiten in Azure Cosmos DB.
Sie können den Azure Cosmos DB-Kapazitätsrechner verwenden, um die Anzahl der Anforderungseinheiten zu ermitteln, die Sie verwenden sollten. Diese Zahl basiert auf Ihrer Datenbankkontokonfiguration, der Menge der Daten, der Dokumentgröße und den erforderlichen Lese- und Schreibvorgängen pro Sekunde.
Im Folgenden sind wichtige Faktoren beschrieben, die sich auf die Anzahl der erforderlichen RUs auswirken:
- Dokumentgröße: Je größer ein Element/Dokument wird, desto mehr RUs werden beim Lesen oder Schreiben des Elements/Dokuments verbraucht.
- Anzahl der Dokumenteigenschaften: Die Anzahl der zum Erstellen oder Aktualisieren eines Dokuments verbrauchten RUs bezieht sich auf die Anzahl, Komplexität und Länge der zugehörigen Eigenschaften. Sie können die für Schreibvorgänge genutzten Anforderungseinheiten verringern, indem Sie die Anzahl indizierter Eigenschaften begrenzen.
- Abfragemuster: Die Komplexität einer Abfrage wirkt sich darauf aus, wie viele Anforderungseinheiten die Anfrage verbraucht.
Am besten können Sie die Kosten von Abfragen verstehen, wenn Sie Beispieldaten in Azure Cosmos DB verwenden und Beispielabfragen aus der MongoDB-Shell mit dem Befehl getLastRequestStastistics ausführen, um die Anforderungsgebühr abzurufen, was die Anzahl der verbrauchten RUs ausgibt:
```
db.runCommand({getLastRequestStatistics: 1})
```
*Dieser Befehl gibt ein JSON-Dokument ähnlich dem folgenden Beispiel aus:
```
{
  "_t": "GetRequestStatisticsResponse",
  "ok": 1,
  "CommandName": "find",
  "RequestCharge": 10.1,
  "RequestDurationInMilliSeconds": 7.2
}
```
Sie können auch die Diagnoseeinstellungen verwenden, um die Häufigkeit und die Muster der für Azure Cosmos DB ausgeführten Abfragen zu verstehen. Die Ergebnisse der Diagnoseprotokolle können an ein Speicherkonto, eine Event Hubs-Instanz oder an die Azure-Protokollanalyse gesendet werden.

Das Planen der Migrationsvorbereitungslogistik

Nachdem Sie nun einen Überblick über Ihren vorhandenen Datenbestand und ein Design für Ihren neuen Azure Cosmos DB-Datenbestand haben, sind Sie bereit zu planen, wie Sie Ihren Migrationsprozess End-to-End durchführen. Auch hier planen Sie auf der Ebene der einzelnen Ressource und fügen Spalten in Ihr Arbeitsblatt hinzu, um die in diesem Abschnitt aufgeführten logistischen Dimensionen einzuschließen.

Die Ausführungslogistik

Das Zuweisen der Verantwortung für die Migration jeder vorhandenen Ressource von der MongoDB zur Azure Cosmos DB. Wie Sie die Ressourcen Ihres Teams einsetzen, um Ihre Migration zum Abschluss zu bringen, bleibt Ihnen überlassen. Bei kleinen Migrationen können Sie ein Team die gesamte Migration starten und den Fortschritt überwachen lassen. Bei größeren Migrationen können Sie den Teammitgliedern ressourcenspezifische Verantwortung für die Migration und Überwachung dieser Ressource zuweisen.

Nachdem Sie die Verantwortung für die Migration Ihren Ressourcen zugewiesen haben, sollten Sie nun das/die richtige(n) Migrationstool(s) für die Migration auswählen. Bei kleinen Migrationen können Sie möglicherweise ein Migrationstool wie ein natives MongoDB-Tool oder den Azure DMS verwenden, um alle Ihre Ressourcen auf einmal zu migrieren. Für größere Migrationen oder solche mit speziellen Anforderungen sollten Sie Migrationstools mit einer Granularität für die einzelnen Ressourcen auswählen.

Bevor Sie die zu verwendenden Migrationstools planen, sollten Sie sich mit den verfügbaren Optionen vertraut machen. Der Azure Database Migration Service für die Azure Cosmos DB-API für MongoDB bietet einen Mechanismus, der die Datenmigration vereinfacht, indem eine vollständig verwaltete Hostingplattform, Migrationsüberwachungsoptionen und die automatische Drosselung bereitgestellt werden. Hier ist eine vollständige Liste der Optionen:

Migrationstyp	Lösung	Überlegungen
Online	Azure Database Migration Service	• Verwendet die Bulk Executor-Bibliothek für Azure Cosmos DB • Eignet sich für große Datasets und übernimmt die Replikation von Live-Änderungen • Funktioniert nur mit anderen MongoDB-Quellen
Offline	Azure Database Migration Service	• Verwendet die Bulk Executor-Bibliothek für Azure Cosmos DB • Eignet sich für große Datasets und übernimmt die Replikation von Live-Änderungen • Funktioniert nur mit anderen MongoDB-Quellen
Offline	Azure Data Factory	• Verwendet die Bulk Executor-Bibliothek für Azure Cosmos DB • Geeignet für große Datensets • Einfache Einrichtung und Unterstützung mehrerer Quellen • Das Fehlen eines Checkpoints bedeutet, dass jedes Problem während der Migration einen Neustart des gesamten Migrationsprozesses erfordern würde • Fehlende Warteschlange für unzustellbare Nachrichten: Dies bedeutet, dass einige fehlerhafte Dateien den gesamten Migrationsprozess unterbrechen können • Erfordert benutzerdefinierten Code, um den Lesedurchsatz für bestimmte Datenquellen zu erhöhen
Offline	Vorhandene Mongo-Tools (mongodump, mongorestore, Studio3T)	• Einfache Einrichtung und Integration • Erfordert die benutzerdefinierte Behandlung von Drosselungen
offline / online	Azure Databricks und Spark	• Vollständige Steuerung der Migrationsrate und Datentransformation • Erfordert benutzerdefinierten Code

Wenn Ihre Ressource eine Offline-Migration tolerieren kann, verwenden Sie dieses Diagramm, um das entsprechende Migrationstool zu wählen:
Wenn Ihre Ressource eine Online-Migration erfordert, verwenden Sie dieses Diagramm, um das entsprechende Migrationstool zu wählen:
Sehen sie sich ein Video zur Übersicht und Demo der Migrationslösungen an.

Sobald Sie die Migrationstools für jede Ressource ausgewählt haben, besteht der nächste Schritt im Priorisieren Ressourcen, die Sie migrieren werden. Eine gute Priorisierung kann dazu beitragen, ihre Migration im Zeitplan zu halten. Eine bewährte Methode ist, die Migration derjenigen Ressourcen zu priorisieren, die am meisten Zeit für das Verschieben beanspruchen. Diese Ressourcen zuerst zu migrieren, bringt den größten Fortschritt in Richtung Fertigstellung. Da diese zeitaufwändigen Migrationen in der Regel mehr Daten umfassen, sind sie auch ressourcenintensiver für das Migrationstool, so dass Probleme mit Ihrer Migrationspipeline wahrscheinlich frühzeitig aufgedeckt werden können. Diese Methode minimiert die Wahrscheinlichkeit, dass Ihr Zeitplan aufgrund von Schwierigkeiten mit Ihrer Migrationspipeline ins Wanken gerät.
Planen Sie, wie Sie den Migrationsfortschritts nach dem Start überwachen. Wenn Sie Ihre Datenmigrationsaufwand in einem Team koordinieren, planen Sie auch eine regelmäßige Kadenz von Teamsynchronisierungen, damit Sie einen umfassenden Überblick über den Verlauf der Migrationen mit hoher Priorität erhalten.

Unterstützte Migrationsszenarien

Die beste Wahl für das MongoDB-Migrationstool hängt von Ihrem Migrationsszenario ab.

Die Migrationstypen

Hier finden Sie eine Liste kompatibler Tools für jedes Migrationsszenario:

`Source`	Destination	Prozessempfehlungen
• Lokaler MongoDB-Cluster • MongoDB on IaaS-VM-Cluster • MongoDB Atlas-Cluster – Offline	Mongo-API von Azure Cosmos DB	• <10 GB Daten: Native MongoDB-Tools • < 1 TB Daten: Azure DMS • > 1 TB Daten: Spark
• Lokaler MongoDB-Cluster • MongoDB on IaaS-VM-Cluster • MongoDB Atlas-Cluster – Online	Mongo-API von Azure Cosmos DB	• < 1 TB Daten: Azure DMS • > 1 TB Daten: Spark + MongoDB-Änderungsstream
• Schema muss während der Migration geändert werden Es wird mehr Flexibilität als bei den zuvor erwähnten Tools benötigt	Mongo-API von Azure Cosmos DB	• ADF ist flexibler als DMS, unterstützt Schemaänderungen während der Migration und die meisten Quell-/Zielkombinationen • DMS ist in Bezug auf die Skalierung besser (z. B. schnellere Migration)
• JSON-Datei	Mongo-API von Azure Cosmos DB	• Native MongoDB-Tools, insbesondere mongoimport
• CSV-Datei	Mongo-API von Azure Cosmos DB	• Native MongoDB-Tools, insbesondere mongoimport
• BSON-Datei	Mongo-API von Azure Cosmos DB	• Native MongoDB-Tools, insbesondere mongorestore

Die Toolunterstützung für die MongoDB-Versionen

Da Sie von einer bestimmten MongoDB-Version migrieren, sind hier die unterstützten Tools für jede Version aufgeführt:

MongoDB-Quellversion	Azure Cosmos DB for MongoDB-Zielversion	Unterstützte Tools	Nicht unterstützte Tools
<2.x, >4.0	3.2, 3.6, 4.0	Native MongoDB-Tools, Spark	DMS, ADF
3.2, 3.6, 4.0	3.2, 3.6, 4.0	Native MongoDB-Tools, DMS, ADF, Spark	Keine

Nach der Migration

Nehmen Sie sich in der Migrationsvorbereitungsphase etwas Zeit, um zu planen, welche Schritte Sie für die App-Migration und die Optimierung nach der Migration unternehmen.

In der Phase der Migrationsnachbereitung führen Sie einen Cutover Ihrer Anwendung aus, um Azure Cosmos DB anstelle Ihres vorhandenen MongoDB-Datenbestands zu verwenden.
Bemühen Sie sich, Indizierung, globale Verteilung, Konsistenz und andere veränderbare Azure Cosmos DB-Eigenschaften auf Ressourcenebene zu planen. Diese Azure Cosmos DB-Konfigurationseinstellungen können jedoch später geändert werden, so dass Sie damit rechnen müssen, diese Einstellungen später anzupassen. Sie wenden diese veränderlichen Konfigurationen nach der Migration an.
Einen Leitfaden für die Zeit nach der Migration finden Sie unter Optimierungsschritte nach der Migration bei Verwendung der API für MongoDB von Azure Cosmos DB.

Nächste Schritte

Migration zu Azure Cosmos DB for MongoDB

Freigeben über