Migrera hundratals terabyte data till Azure Cosmos DB

GÄLLER för: SQL API API för Cassandra Gremlin API tabell-API Azure Cosmos DB API för MongoDB

Azure Cosmos DB kan lagra flera terabyte data. Du kan utföra en storskalig datamigrering för att flytta din produktionsarbetsbelastning till Azure Cosmos DB. I den här artikeln beskriver vi utmaningarna med att flytta storskaliga data till Azure Cosmos DB och introducerar ett verktyg som hjälper dig med migreringen. I den här fallstudien använde kunden Cosmos DB SQL API.

Innan du migrerar hela arbetsbelastningen till Azure Cosmos DB kan du migrera en delmängd data för att verifiera några av aspekterna som val av partitionsnyckel, frågeprestanda och datamodellering. När du har validerat konceptbeviset kan du flytta hela arbetsbelastningen till Azure Cosmos DB.

Verktyg för datamigrering

Azure Cosmos DB migreringsstrategier skiljer sig för närvarande beroende på API-valet och storleken på data. Om du vill migrera mindre datauppsättningar – för att verifiera datamodellering, frågeprestanda, val av partitionsnyckel osv. – kan du välja datamigreringsverktyget eller Azure Data Factory:s Azure Cosmos DB anslutningsapp. Om du är bekant med Spark kan du även välja att använda Azure Cosmos DB Spark-anslutningsappen för att migrera data.

Utmaningar vid storskaliga migreringar

De befintliga verktygen för att migrera data till Azure Cosmos DB har vissa begränsningar som blir särskilt synliga i stor skala:

• Begränsade utskalningsfunktioner: För att kunna migrera flera terabyte data till Azure Cosmos DB så snabbt som möjligt, och för att effektivt förbruka hela det etablerade dataflödet, bör migreringsklienterna kunna skala ut på obestämd tid.

• Brist på förloppsspårning och kontroll pekare: Det är viktigt att spåra migreringens förlopp och ha kontroll pekare vid migrering av stora datamängder. Annars stoppas migreringen av eventuella fel som inträffar under migreringen, och du måste starta processen från början. Det skulle inte vara produktivt att starta om hela migreringsprocessen när 99 % av den redan har slutförts.

• Brist på kö för oställbara meddelanden: I stora datamängder kan det i vissa fall finnas problem med delar av källdata. Dessutom kan det finnas tillfälliga problem med klienten eller nätverket. Endera av dessa fall bör inte orsaka att hela migreringen misslyckas. Även om de flesta migreringsverktyg har robusta återförsöksfunktioner som skyddar mot tillfälliga problem räcker det inte alltid. Om till exempel mindre än 0,01 % av källdatadokumenten är större än 2 MB kommer dokumentskrivningen att misslyckas i Azure Cosmos DB. Helst är det användbart för migreringsverktyget att bevara dessa "misslyckade" dokument i en annan kö för dead letter som kan bearbetas efter migreringen.

Många av dessa begränsningar åtgärdas för verktyg som Azure Data Factory och Azure Data Migration Services.

Anpassat verktyg med masse executor-bibliotek

Utmaningarna som beskrivs i avsnittet ovan kan lösas med hjälp av ett anpassat verktyg som enkelt kan skalas ut över flera instanser och är motståndskraftigt mot tillfälliga fel. Dessutom kan det anpassade verktyget pausa och återuppta migreringen vid olika kontrollpunkter. Azure Cosmos DB redan massut executor-biblioteket som innehåller några av dessa funktioner. Masskörarbiblioteket har till exempel redan funktioner för att hantera tillfälliga fel och kan skala ut trådar i en enda nod för att förbruka cirka 500 000 RU:er per nod. Massut executor-biblioteket partitionerar även källdatauppsättningen i mikrobatchar som körs oberoende av varandra som en form av kontrollpunkter.

Det anpassade verktyget använder mass executor-biblioteket och stöder utskalning över flera klienter och för att spåra fel under inmatningsprocessen. Om du vill använda det här verktyget ska källdata partitioneras i olika filer i Azure Data Lake Storage (ADLS) så att olika migreringsarbetare kan hämta varje fil och mata in dem i Azure Cosmos DB. Det anpassade verktyget använder en separat samling som lagrar metadata om migreringsförloppet för varje enskild källfil i ADLS och spårar eventuella fel som är associerade med dem.

I följande bild beskrivs migreringsprocessen med det här anpassade verktyget. Verktyget körs på en uppsättning virtuella datorer och varje virtuell dator frågar spårningssamlingen i Azure Cosmos DB för att få ett lån på en av källdatapartitionerna. När det är klart läses källdatapartitionen av verktyget och matas in i Azure Cosmos DB med hjälp av massutfilens bibliotek. Därefter uppdateras spårningssamlingen för att registrera förloppet för datainmatning och eventuella påträffade fel. När en datapartition har bearbetats försöker verktyget fråga efter nästa tillgängliga källpartition. Den fortsätter att bearbeta nästa källpartition tills alla data har migrerats. Källkoden för verktyget finns på lagringsplatsen Azure Cosmos DB massinmatning.

Spårningssamlingen innehåller dokument som du ser i följande exempel. Du ser sådana dokument ett för varje partition i källdata. Varje dokument innehåller metadata för källdatapartitionen, till exempel dess plats, migreringsstatus och fel (om sådana finns):

{ 
  "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 
} 

Förutsättningar för datamigrering

Innan datamigrering startar finns det några förutsättningar att tänka på:

Beräkna datastorleken:

Källdatastorleken kanske inte exakt mappar till datastorleken i Azure Cosmos DB. Några exempeldokument från källan kan infogas för att kontrollera datastorleken i Azure Cosmos DB. Beroende på exempeldokumentets storlek kan den totala datastorleken i Azure Cosmos DB efter migreringen beräknas.

Om till exempel varje dokument efter migreringen i Azure Cosmos DB är cirka 1 kB och om det finns cirka 60 miljarder dokument i källdatauppsättningen, skulle den uppskattade storleken i Azure Cosmos DB vara nära 60 TB.

Skapa containrar i förväg med tillräckligt med RU:er:

Även Azure Cosmos DB skalar ut lagring automatiskt, är det inte lämpligt att börja från den minsta containerstorleken. Mindre containrar har lägre tillgänglighet för dataflöde, vilket innebär att migreringen tar mycket längre tid att slutföra. I stället är det bra att skapa containrarna med den slutliga datastorleken (enligt uppskattningen i föregående steg) och se till att migreringsarbetsbelastningen använder det etablerade dataflödet fullt ut.

I föregående steg. Eftersom datastorleken uppskattades till cirka 60 TB krävs en container på minst 2,4 M RU:er för att hantera hela datauppsättningen.

Beräkna migreringshastigheten:

Förutsatt att migreringsarbetsbelastningen kan förbruka hela det etablerade dataflödet skulle det etablerade genomströmningen ge en uppskattning av migreringshastigheten. Om vi fortsätter med föregående exempel krävs 5 RU:er för att skriva ett dokument på 1 kB till Azure Cosmos DB SQL API-konto. 2,4 miljoner RU:er skulle tillåta en överföring av 480 000 dokument per sekund (eller 480 MB/s). Det innebär att den fullständiga migreringen på 60 TB tar 125 000 sekunder eller cirka 34 timmar.

Om du vill att migreringen ska slutföras inom en dag bör du öka det etablerade dataflödet till 5 miljoner RU:er.

Stäng av indexeringen:

Eftersom migreringen bör slutföras så snart som möjligt rekommenderar vi att du minimerar den tid och ru:er som läggs på att skapa index för vart och ett av de dokument som matas in. Azure Cosmos DB automatiskt indexerar alla egenskaper är det värt att minimera indexeringen till några få termer eller stänga av den helt under migreringen. Du kan inaktivera containerns indexeringsprincip genom att ändra indexingMode till none enligt nedan:

  { 
        "indexingMode": "none" 
  } 

När migreringen är klar kan du uppdatera indexeringen.

Migreringsprocessen

När förutsättningarna är klara kan du migrera data med följande steg:

1. Importera först data från källan till Azure Blob Storage. Om du vill öka migreringshastigheten är det bra att parallellisera mellan olika källpartitioner. Innan du påbörjar migreringen bör källdatauppsättningen partitioneras i filer med en storlek på cirka 200 MB.

2. Massut executor-biblioteket kan skalas upp för att förbruka 500 000 RU:er på en enda virtuell klientdator. Eftersom det tillgängliga dataflödet är 5 miljoner RU:er bör 10 virtuella Ubuntu 16.04-datorer (Standard_D32_v3) etableras i samma region där din Azure Cosmos-databas finns. Du bör förbereda de här virtuella datorerna med migreringsverktyget och dess inställningsfil.

3. Kör kösteget på en av de virtuella klientdatorerna. Det här steget skapar spårningssamlingen, som genomsöker ADLS-containern och skapar ett förloppsspårningsdokument för var och en av källdatauppsättningens partitionsfiler.

4. Kör sedan importsteget på alla virtuella klientdatorer. Var och en av klienterna kan bli ägare till en källpartition och mata in data i Azure Cosmos DB. När den är klar och dess status uppdateras i spårningssamlingen kan klienterna sedan fråga efter nästa tillgängliga källpartition i spårningssamlingen.

5. Den här processen fortsätter tills hela uppsättningen källpartitioner har matats in. När alla källpartitioner har bearbetats ska verktyget köras igen i felkorrigeringsläget i samma spårningssamling. Det här steget krävs för att identifiera de källpartitioner som ska bearbetas igen på grund av fel.

6. Några av de här felen kan bero på felaktiga dokument i källdata. Dessa bör identifieras och åtgärdas. Därefter bör du köra importsteget på de misslyckade partitionerna igen för attestera dem.

När migreringen är klar kan du kontrollera att antalet dokument i Azure Cosmos DB är samma som antalet dokument i källdatabasen. I det här exemplet visades den totala storleken Azure Cosmos DB 65 terabyte. Efter migreringen kan indexering aktiveras selektivt och RU:erna kan sänkas till den nivå som krävs av arbetsbelastningens åtgärder.

Nästa steg

• Lär dig mer genom att testa exempelprogrammen som använder massut executor-biblioteket i .NET och Java.
• Massekveringsbiblioteket är integrerat i Cosmos DB Spark-anslutningsappen. Mer information finns i artikeln Azure Cosmos DB Spark-anslutningsappen.
• Kontakta Azure Cosmos DB produktteamet genom att öppna en supportbiljett under problemtypen "Allmän rådgivning" och undertypen "Stora migreringar (TB+) för ytterligare hjälp med storskaliga migreringar.
• Försöker du göra kapacitetsplanering för en migrering till Azure Cosmos DB? Du kan använda information om ditt befintliga databaskluster för kapacitetsplanering.
  • Om allt du vet är antalet virtuella kärnor och servrar i ditt befintliga databaskluster kan du läsa om att uppskatta enheter för programbegäran med hjälp av virtuella kärnor eller virtuella processorer
  • Om du känner till vanliga begärandefrekvenser för din aktuella databasarbetsbelastning kan du läsa om att uppskatta enheter för programbegäran Azure Cosmos DB kapacitetsplaneraren