Förmigreringssteg för datamigreringar från MongoDB till Azure Cosmos DB för MongoDB

GÄLLER FÖR: MongoDB

Den här guiden före migreringen av MongoDB är en del av serien om MongoDB-migrering. De kritiska Stegen för MongoDB-migrering är före migrering, migrering och efter migrering, som du ser i den här guiden.

Översikt över förmigrering

Det är viktigt att utföra viss planering och beslutsfattande i förväg om migreringen innan du faktiskt flyttar data. Den här inledande beslutsprocessen är "före migreringen".

Målet i före migreringen är att:

1. Se till att du konfigurerar Azure Cosmos DB för att uppfylla programmets krav och
2. Planera hur du utför migreringen.

Följ de här stegen för att utföra en grundlig förmigrering

1. Identifiera dina befintliga MongoDB-resurser och utvärdera beredskapen för dina befintliga MongoDB-resurser för datamigrering
2. Mappa dina befintliga MongoDB-resurser till nya Azure Cosmos DB-resurser
3. Planera logistiken för migreringsprocessen från slutpunkt till slutpunkt innan du startar den fullständiga datamigreringen

Kör sedan migreringen i enlighet med din plan före migreringen.

Utför slutligen de kritiska stegen efter migreringen av cut-over och optimering.

Alla ovanstående steg är viktiga för att säkerställa en lyckad migrering.

När du planerar en migrering rekommenderar vi att du planerar på resursnivå när det är möjligt.

Utvärdering före migrering

Det första steget före migreringen är att identifiera dina befintliga MongoDB-resurser och utvärdera beredskapen för dina resurser för migrering.

Identifiering innebär att du skapar en omfattande lista över befintliga resurser (databaser eller samlingar) i din MongoDB-dataegendom.

Utvärderingen omfattar att ta reda på om du använder de funktioner och syntax som stöds. Det omfattar även att se till att du följer gränserna och kvoterna. Syftet med det här steget är att skapa en lista över eventuella inkompatibiliteter och varningar. När du har utvärderingsresultatet kan du försöka åtgärda resultaten under resten av migreringsplaneringen.

Det finns tre sätt att slutföra utvärderingen före migreringen. Vi rekommenderar att du använder Azure Cosmos DB Migration for MongoDB-tillägget.

Azure Cosmos DB-migrering för MongoDB-tillägg

Azure Cosmos DB Migration for MongoDB-tillägget i Azure Data Studio hjälper dig att utvärdera en MongoDB-arbetsbelastning för migrering till Azure Cosmos DB för MongoDB. Du kan använda det här tillägget för att köra en utvärdering från slutpunkt till slutpunkt för din arbetsbelastning och ta reda på vilka åtgärder du kan behöva vidta för att sömlöst migrera dina arbetsbelastningar i Azure Cosmos DB. Under utvärderingen av en MongoDB-slutpunkt rapporterar tillägget alla identifierade resurser.

Manuell identifiering (äldre)

Du kan också skapa ett kalkylblad för migrering av dataegendom. Syftet med det här kalkylbladet är att förbättra produktiviteten och hjälpa dig att planera migrering från slutpunkt till slutpunkt och använda det som ett spårningsdokument under hela migreringsprocessen.

• Det här bladet innehåller en omfattande lista över befintliga resurser (databaser eller samlingar) i din MongoDB-dataegendom.
• Kalkylbladet bör struktureras som en post för dina dataegendomsresurser i listformulär.
• Varje rad motsvarar en resurs (databas eller samling).
• Varje kolumn motsvarar en egenskap för resursen. börja med minst namn och datastorlek (GB) som kolumner.
• När du går igenom den här guiden skapar du det här kalkylbladet i ett spårningsdokument för migreringsplaneringen från slutpunkt till slutpunkt och lägger till kolumner efter behov.

Här är några verktyg som du kan använda för att identifiera resurser:

• MongoDB Shell
• MongoDB-kompass

Gå igenom kalkylbladet och verifiera varje samling mot de funktioner och syntax som stöds samt Azure Cosmos DB-gränser och kvoter i detalj.

Database Migration Assistant-verktyget (äldre)

Du kan använda verktyget Database Migration Assistant (DMA) för att hjälpa dig med stegen före migreringen.

Mappning före migrering

När identifierings- och utvärderingsstegen är klara är du klar med MongoDB-sidan av ekvationen. Nu är det dags att planera Azure Cosmos DB-sidan av ekvationen. Hur planerar du att konfigurera dina Azure Cosmos DB-produktionsresurser? Planera på resursnivå – det innebär att du bör lägga till följande kolumner i ditt planeringskalkyk:

• Azure Cosmos DB-mappning
• Shard-nyckel
• Datamodell
• Dedikerat kontra delat dataflöde

Mer information finns i följande avsnitt.

Kapacitetsplanering

Försöker du planera kapacitet för en migrering till Azure Cosmos DB?

• Om allt du vet är antalet virtuella kärnor och servrar i ditt befintliga databaskluster läser du om att uppskatta enheter för begäranden med virtuella kärnor eller virtuella kärnor
• Om du känner till vanliga begärandefrekvenser för din aktuella databasarbetsbelastning kan du läsa om att uppskatta enheter för begäranden med azure Cosmos DB-kapacitetshanteraren

Överväganden när du använder Azure Cosmos DB:s API för MongoDB

Innan du planerar din Azure Cosmos DB-dataegendom måste du förstå följande Azure Cosmos DB-begrepp:

• Kapacitetsmodell: Databaskapaciteten i Azure Cosmos DB baseras på en dataflödesbaserad modell. Den här modellen baseras på enheter för begäranden per sekund, vilket är en enhet som representerar antalet databasåtgärder som kan köras mot en samling per sekund. Den här kapaciteten kan allokeras på databas- eller samlingsnivå och kan etableras på en allokeringsmodell eller med hjälp av det autoskalningsetablerade dataflödet.
• Enheter för begäran: Varje databasåtgärd har en associerad kostnad för enheter för programbegäran (RU: er) i Azure Cosmos DB. När de körs subtraheras enheter för begäran från den tillgängliga enhetsnivån för begäranden på en viss sekund. Om en begäran kräver fler RU:er än de för närvarande allokerade RU:erna finns det två alternativ för att lösa problemet – öka antalet RU:er eller vänta tills nästa sekund startar och försök sedan utföra åtgärden igen.
• Elastisk kapacitet: Kapaciteten för en viss samling eller databas kan ändras när som helst. Med den här flexibiliteten kan databasen elastiskt anpassa sig till dataflödeskraven för din arbetsbelastning.
• Automatisk horisontell partitionering: Azure Cosmos DB tillhandahåller ett automatiskt partitioneringssystem som bara kräver en shard (eller en partitionsnyckel). Den automatiska partitioneringsmekanismen delas mellan alla Azure Cosmos DB-API:er och möjliggör sömlösa data och hela skalningen via horisontell distribution.

Planera Azure Cosmos DB-dataegendomen

Ta reda på vilka Azure Cosmos DB-resurser du skapar. Den här processen kräver att du går igenom kalkylbladet för migrering av dataegendom och mappar varje befintlig MongoDB-resurs till en ny Azure Cosmos DB-resurs.

• Förutse att varje MongoDB-databas blir en Azure Cosmos DB-databas.
• Förutse att varje MongoDB-samling blir en Azure Cosmos DB-samling.
• Välj en namngivningskonvention för dina Azure Cosmos DB-resurser. Att behålla samma resursnamn är vanligtvis ett bra val, såvida det inte finns några ändringar i strukturen för databaser och samlingar.
• Ta reda på om du använder fragmenterade eller ohardade samlingar i Azure Cosmos DB. Gränsen för ohardad samling är 20 GB. Horisontell partitionering hjälper å andra sidan till att uppnå horisontell skalning som är avgörande för prestanda för många arbetsbelastningar.
• Om du använder fragmenterade samlingar ska du inte anta att mongoDB-samlingens shardnyckel blir din Azure Cosmos DB-containerpartitionsnyckel. Anta inte att din befintliga Dokumentstruktur för MongoDB-datamodell ska vara samma modell som du använder i Azure Cosmos DB.
  • Shard-nyckeln är den enskilt viktigaste inställningen för att optimera skalbarheten och prestandan för Azure Cosmos DB, och datamodellering är den näst viktigaste. Båda dessa inställningar är oföränderliga och kan inte ändras när de har angetts. Därför är det mycket viktigt att optimera dem i planeringsfasen. Mer information finns i avsnittet Oföränderliga beslut i vägledningen.
• Azure Cosmos DB känner inte igen vissa MongoDB-samlingstyper, till exempel begränsade samlingar. För dessa resurser skapar du bara vanliga Azure Cosmos DB-samlingar.
• Azure Cosmos DB har två egna samlingstyper – delat och dedikerat dataflöde. Delat kontra dedikerat dataflöde är ett annat kritiskt, oföränderligt beslut som det är viktigt att fatta i planeringsfasen. Mer information finns i avsnittet Oföränderliga beslut i vägledningen.

Oföränderliga beslut

Följande konfigurationsalternativ för Azure Cosmos DB kan inte ändras eller ångras när du har skapat en Azure Cosmos DB-resurs. Därför är det viktigt att få de här konfigurationsalternativen rätt under planeringen före migreringen, innan du startar några migreringar:

• Se Partitionering och horisontell skalning i Azure Cosmos DB för att välja den bästa shardnyckeln. Partitionering, även kallat Sharding, är en viktig faktor att tänka på innan du migrerar data. Azure Cosmos DB använder fullständigt hanterad partitionering för att öka kapaciteten i en databas för att uppfylla lagrings- och dataflödeskraven. Den här funktionen behöver inte värdtjänster eller konfiguration av routningsservrar.
  • På liknande sätt lägger partitioneringsfunktionen automatiskt till kapacitet och balanserar om data i enlighet med detta. Mer information om hur du väljer rätt partitionsnyckel för dina data finns i välja en partitionsnyckel.
• Följ guiden för datamodellering i Azure Cosmos DB för att välja en datamodell.
• Följ Optimera kostnader för etablerat dataflöde i Azure Cosmos DB för att välja mellan dedikerat och delat dataflöde för varje resurs som du migrerar
• Hur du modellerar och partitionerar data i Azure Cosmos DB med hjälp av ett verkligt exempel är ett verkligt exempel på horisontell partitionering och datamodellering som hjälper dig i beslutsprocessen

Ägandekostnad

• Beräkna ägandekostnaden för dina nya Azure Cosmos DB-resurser med hjälp av Kapacitetskalkylatorn för Azure Cosmos DB.

Beräkna dataflöde

• I Azure Cosmos DB etableras dataflödet i förväg och mäts i enheter för programbegäran (RU: er) per sekund. Till skillnad från virtuella datorer eller lokala servrar är RU:er enkla att skala upp och ned när som helst. Du kan ändra antalet etablerade RU:er direkt. Mer information finns i Enheter för begäran i Azure Cosmos DB.

• Du kan använda Kapacitetskalkylatorn för Azure Cosmos DB för att fastställa antalet enheter för begäranden som du bör använda. Det här talet baseras på din databaskontokonfiguration, mängden data, dokumentstorlek och nödvändiga läsningar och skrivningar per sekund.

• Följande är viktiga faktorer som påverkar antalet nödvändiga RU:er:

  • Dokumentstorlek: När storleken på ett objekt/dokument ökar ökar även antalet RU:er som används för att läsa eller skriva objektet/dokumentet.

  • Antal dokumentegenskap:Antalet RU:er som används för att skapa eller uppdatera ett dokument är relaterat till antalet, komplexiteten och längden på dess egenskaper. Du kan minska enhetsförbrukningen för begäranden för skrivåtgärder genom att begränsa antalet indexerade egenskaper.

  • Frågemönster: Komplexiteten i en fråga påverkar hur många enheter för begäran som frågan förbrukar.

• Det bästa sättet att förstå kostnaden för frågor är att använda exempeldata i Azure Cosmos DB och köra exempelfrågor från MongoDB Shell med hjälp av getLastRequestStastistics kommandot för att hämta begärandeavgiften, som matar ut antalet förbrukade RU:er:

  db.runCommand({getLastRequestStatistics: 1})
  

  *Det här kommandot matar ut ett JSON-dokument som liknar följande exempel:

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

• Du kan också använda diagnostikinställningarna för att förstå frekvensen och mönstren för de frågor som körs mot Azure Cosmos DB. Resultatet från diagnostikloggarna kan skickas till ett lagringskonto, en Event Hubs-instans eller Azure Log Analytics.

Logistikplanering före migrering

Nu när du nu har en vy över din befintliga dataegendom och en design för din nya Azure Cosmos DB-dataegendom är du redo att planera hur du ska köra migreringsprocessen från slutpunkt till slutpunkt. Gör återigen planeringen på resursnivå och lägg till kolumner i kalkylbladet för att samla in de logistiska dimensioner som ingår i det här avsnittet.

Körningslogistik

• Tilldela ansvar för att migrera varje befintlig resurs från MongoDB till Azure Cosmos DB. Hur du tillämpar dina teamresurser för att genomföra migreringen är upp till dig. För små migreringar kan du låta ett team starta hela migreringen och övervaka dess förlopp. För större migreringar kan du tilldela ansvaret till teammedlemmar per resurs för migrering och övervakning av resursen.

• När du har tilldelat ansvar för att migrera dina resurser bör du nu välja rätt migreringsverktyg för migrering. För små migreringar kanske du kan använda ett migreringsverktyg, till exempel ett ursprungligt MongoDB-verktyg eller Azure DMS för att migrera alla dina resurser i ett enda skott. För större migreringar eller migreringar med särskilda krav kanske du vill välja migreringsverktyg med kornighet per resurs.

  • Innan du planerar vilka migreringsverktyg som ska användas rekommenderar vi att du bekantar dig med de alternativ som är tillgängliga. Azure Database Migration Service för Azure Cosmos DB:s API för MongoDB tillhandahåller en mekanism som förenklar datamigreringen genom att tillhandahålla en fullständigt hanterad värdplattform, övervakningsalternativ för migrering och automatisk begränsningshantering. Här är en fullständig lista över alternativ:

    Migreringstyp	Lösning	Överväganden
    Online	Azure Database Migration Service	• Använder massexekutorbiblioteket för Azure Cosmos DB • Lämplig för stora datamängder och tar hand om replikering av live-ändringar • Fungerar endast med andra MongoDB-källor
    Offline	Azure Database Migration Service	• Använder massexekutorbiblioteket för Azure Cosmos DB • Lämplig för stora datamängder och tar hand om replikering av live-ändringar • Fungerar endast med andra MongoDB-källor
    Offline	Azure Data Factory	• Använder massexekutorbiblioteket för Azure Cosmos DB • Lämplig för stora datamängder • Lätt att konfigurera och har stöd för flera källor • Brist på kontrollpunkter innebär att alla problem under migreringen skulle kräva en omstart av hela migreringsprocessen • Avsaknaden av en kö med obeställbara meddelanden skulle innebära att några felaktiga filer skulle kunna stoppa hela migreringsprocessen • Behöver anpassad kod för att öka läsflödet för vissa datakällor
    Offline	Befintliga Mongo-verktyg (mongodump, mongorestore, Studio3T)	• Lätt att konfigurera och integrera • Behöver anpassad hantering av begränsningar
    Offline/online	Azure Databricks och Spark	• Fullständig kontroll över migreringshastighet och datatransformering • Kräver anpassad kodning

  • Om din resurs kan tolerera en offlinemigrering använder du det här diagrammet för att välja lämpligt migreringsverktyg:

    

  • Om din resurs kräver en onlinemigrering använder du det här diagrammet för att välja lämpligt migreringsverktyg:

    

  • Titta på en översikt och demonstration av videon med migreringslösningar .

• När du har valt migreringsverktyg för varje resurs är nästa steg att prioritera de resurser som du ska migrera. Bra prioritering kan hjälpa dig att hålla migreringen enligt schemat. En bra idé är att prioritera migreringen av dessa resurser, som behöver mest tid för att flyttas. När du migrerar de här resurserna är det först de största framstegen mot slutförande. Eftersom dessa tidskrävande migreringar vanligtvis omfattar mer data är de dessutom mer resursintensiva för migreringsverktyget och är därför mer benägna att exponera eventuella problem med din migreringspipeline tidigt. Den här metoden minimerar risken för att ditt schema halkar på grund av problem med migreringspipelinen.

• Planera hur du övervakar migreringens förlopp när den har startats. Om du samordnar din datamigrering mellan ett team planerar du även en regelbunden takt av teamsynkroniseringar, så att du får en omfattande vy över hur de högprioriterad migreringen går.

Migreringsscenarier som stöds

Det bästa valet av MongoDB-migreringsverktyg beror på ditt migreringsscenario.

Typer av migreringar

Här är en lista över kompatibla verktyg för varje migreringsscenario:

Stöd för verktyg för MongoDB-versioner

Med tanke på att du migrerar från en viss MongoDB-version ingår de verktyg som stöds för varje version här:

Efter migreringen

I fasen före migreringen ägnar du lite tid åt att planera vilka steg du ska vidta för appmigrering och optimering efter migreringen.

• I fasen efter migreringen kör du en snabb genomgång av ditt program för att använda Azure Cosmos DB i stället för din befintliga MongoDB-dataegendom.
• Gör ditt bästa för att planera indexering, global distribution, konsekvens och andra föränderliga Azure Cosmos DB-egenskaper på resursnivå. Dessa Azure Cosmos DB-konfigurationsinställningar kan dock ändras senare, så förvänta dig att göra justeringar i de här inställningarna senare. Du använder de här föränderliga konfigurationerna efter migreringen.
• En guide efter migreringen finns i optimeringssteg efter migreringen när du använder Azure Cosmos DB:s API för MongoDB.

Nästa steg

• Migrera till Azure Cosmos DB för MongoDB
  • Offlinemigrering med hjälp av inbyggda MongoDB-verktyg
  • Offlinemigrering med hjälp av Azure Database Migration Service (DMS)
  • Onlinemigrering med hjälp av Azure Database Migration Service (DMS)