Rekommendationer för datapartitionering

Artikel
07/03/2024

gäller för den här rekommendationen i checklistan för Azure Well-Architected Framework Reliability:

RE:06	Implementera en tidsenlig och tillförlitlig skalningsstrategi på program-, data- och infrastrukturnivå. Basera skalningsstrategin på faktiska eller förutsagda användningsmönster och minimera manuella åtgärder.

Relaterad guide:Skalning

Den här guiden beskriver rekommendationerna för att utforma en strategi för datapartitionering för den databas- och datalagringsteknik som du distribuerar. Den här strategin hjälper dig att förbättra tillförlitligheten för din dataegendom.

Viktiga designstrategier

I många storskaliga lösningar används partitioner för att dela upp data så att de kan hanteras och nås separat. Partitionering av data förbättrar skalbarheten, minskar konkurrensen och optimerar prestanda. Implementera datapartitionering för att dela upp data efter användningsmönster. Du kan till exempel arkivera äldre data i billig datalagring. Välj partitioneringsstrategin noggrant för att maximera fördelarna och minimera negativa effekter.

Not

I den här artikeln innebär termen partitionering processen att fysiskt dela upp data i separata datalager. Den skiljer sig från SQL Server-tabellpartitionering.

Du kan partitionera data till:

Förbättra skalbarheten. När du skalar upp ett enda databassystem når databasen så småningom en fysisk maskinvarugräns. Om du delar upp data mellan flera partitioner, där varje partition finns på en separat server, kan du skala ut systemet nästan på obestämd tid.
Förbättra prestanda. I varje partition utförs dataåtkomståtgärder över en mindre mängd data jämfört med data som inte är partitionerade. Partitionera data för att göra systemet mer effektivt. Åtgärder som påverkar mer än en partition kan köras parallellt.
Förbättra säkerheten. I vissa fall kan du separera känsliga och meningslösa data i olika partitioner och tillämpa olika säkerhetskontroller på känsliga data.
Möjliggör flexibilitet i driften. Du kan partitionera data för att finjustera åtgärder, maximera den administrativa effektiviteten och minimera kostnaderna. Du kan till exempel definiera strategier för hantering, övervakning, säkerhetskopiering och återställning samt andra administrativa uppgifter baserat på vikten av data i varje partition.
Matcha datalagret med användningsmönstret. Du kan distribuera varje partition på en annan typ av datalager baserat på kostnaden och de inbyggda funktioner som datalagret erbjuder. Du kan till exempel lagra stora binära data i Blob Storage och lagra strukturerade data i en dokumentdatabas. Mer information finns i Förstå datalagermodeller.
Förbättra tillgängligheten. För att undvika en enskild felpunkt kan du separera data mellan flera servrar. Om en instans misslyckas är endast data i partitionen otillgängliga. Åtgärderna fortsätter i andra partitioner. Det här är mindre relevant för paaS-datalager (managed platform as a service) eftersom de har inbyggd redundans.

Välj rätt partitioneringsstrategi

Det finns tre vanliga strategier för partitionering av data:

Horisontell partitionering (kallas ofta sharding). I den här strategin är varje partition ett separat datalager, men alla partitioner har samma schema. Varje partition kallas för en shard- och innehåller en delmängd av data, till exempel en uppsättning kundbeställningar.
Vertikal partitionering. I den här strategin innehåller varje partition en delmängd av fälten för objekt i datalagret. Fälten delas upp enligt användningsmönstret. Till exempel kan fält som används ofta placeras i en vertikal partition och mindre ofta använda fält i en annan.
Funktionell partitionering. I den här strategin aggregeras data enligt hur varje begränsad kontext i systemet använder data. Ett e-handelssystem kan till exempel lagra fakturadata i en partition och produktinventeringsdata i en annan.

Överväg att kombinera dessa strategier när du utformar ett partitioneringsschema. Du kan till exempel dela upp data i shards och sedan använda vertikal partitionering för att ytterligare dela upp data i varje shard.

Horisontell partitionering (sharding)

Följande bild visar ett exempel på horisontell partitionering eller shardning. I det här exemplet delas produktinventeringsdata in i fragment som baseras på produktnyckeln. Varje shard innehåller data för ett sammanhängande intervall med shardnycklar (A-G och H-Z), ordnade i alfabetisk ordning. När du utför horisontell partitionering sprids belastningen över fler datorer, vilket minskar konkurrensen och förbättrar prestandan.

Den viktigaste faktorn är partitioneringsnyckeln som du väljer. Det kan vara svårt att ändra nyckeln när systemet är i drift. Nyckeln måste se till att data partitioneras för att sprida arbetsbelastningen så jämnt som möjligt över fragmenten.

Fragmenten behöver inte ha samma storlek. Det är viktigare att balansera antalet begäranden. Vissa skärvor kan vara stora, men varje föremål i skärvan har ett lågt antal åtkomster. Andra shards kan vara mindre, men varje objekt i fragmentet används oftare. Det är också viktigt att se till att en enda shard inte överskrider skalningsgränserna för datalagret när det gäller kapacitet och bearbetningsresurser.

Undvik att skapa heta partitioner som kan påverka prestanda och tillgänglighet. Om du till exempel använder den första bokstaven i en kunds namn kan den skapa en obalanserad distribution eftersom vissa bokstäver är vanligare än andra. Använd i stället en hash för kundidentifierare för att distribuera data jämnt mellan partitioner.

Välj en shardingnyckel som minimerar det framtida behovet av att dela upp stora shards, kombinera små shards till större partitioner eller ändra schemat. Dessa åtgärder är tidskrävande och kan kräva att du tar en eller flera shards offline.

Om shards replikeras kan du hålla vissa av replikerna online medan andra delas, sammanfogas eller konfigureras om. Systemet kan dock begränsa de åtgärder som kan utföras under omkonfigurationen. Till exempel kan data i replikerna markeras som skrivskyddade för att förhindra datainkonsekvenser.

Mer information finns i mönster för horisontell partitionering.

Lodrät partitionering

Den vanligaste användningen för vertikal partitionering är att minska de I/O- och prestandakostnader som är associerade med hämtning av objekt som används ofta. Följande bild visar ett exempel på vertikal partitionering. I det här exemplet lagras olika egenskaper för ett objekt i olika partitioner. En partition innehåller data som används oftare, inklusive produktnamn, beskrivning och pris. En annan partition innehåller inventeringsdata, inklusive lagerantalet och det senaste ordnade datumet.

I det här exemplet frågar programmet regelbundet produktnamnet, beskrivningen och priset när det visar produktinformationen för kunderna. Lagerantalet och det senaste ordnade datumet finns i en separat partition eftersom dessa två objekt ofta används tillsammans.

Se följande fördelar med vertikal partitionering:

Du kan separera relativt långsamma data (produktnamn, beskrivning och pris) från mer dynamiska data (lagernivå och senaste beställningsdatum). Långsamma data är en bra kandidat för ett program att cachas i minnet.
Du kan lagra känsliga data i en separat partition med tillagda säkerhetskontroller.
Vertikal partitionering kan minska mängden samtidig åtkomst som behövs.

Vertikal partitionering fungerar på entitetsnivå i ett datalager, vilket delvis normaliserar en entitet för att dela upp den från ett brett objekt till en uppsättning smala objekt. Det passar perfekt för kolumnorienterade datalager, till exempel HBase och Cassandra. Om data i en samling kolumner sannolikt inte kommer att ändras bör du överväga att använda kolumnlager i SQL Server.

Funktionell partitionering

När en avgränsad kontext kan identifieras för varje enskilt affärsområde i ett program kan funktionell partitionering förbättra isolerings- och dataåtkomstprestanda. En annan vanlig användning för funktionell partitionering är att separera läs- och skrivdata från skrivskyddade data. Följande bild visar en översikt över funktionell partitionering som har inventeringsdata åtskilda från kunddata.

Den här partitioneringsstrategin kan bidra till att minska konkurrensen om dataåtkomst i olika delar av ett system.

Utforma partitioner för skalbarhet

Det är viktigt att tänka på storleken och arbetsbelastningen för varje partition. Balansera dem så att data distribueras för att uppnå maximal skalbarhet. Men du måste också partitionera data så att de inte överskrider skalningsgränserna för ett enda partitionslager.

Följ dessa steg när du utformar partitioner för skalbarhet:

Analysera programmet för att förstå dataåtkomstmönster, till exempel storleken på resultatuppsättningen som varje fråga returnerar, åtkomstfrekvens, inbyggd svarstid och bearbetningskrav på serversidan. I många fall kräver några större entiteter de flesta bearbetningsresurserna.
Använd den här analysen för att fastställa aktuella och framtida skalbarhetsmål, till exempel datastorlek och arbetsbelastning. Distribuera sedan data mellan partitionerna för att uppfylla skalbarhetsmålet. För horisontell partitionering väljer du rätt shardnyckel för att säkerställa jämn distribution. För mer information, se Sharding-mönster.
Se till att varje partition har tillräckligt med resurser för att hantera skalbarhetskraven när det gäller datastorlek och dataflöde. Beroende på datalagret kan det finnas en gräns för varje partition på mängden lagringsutrymme, bearbetningskraft eller nätverksbandbredd. Om kraven sannolikt överskrider dessa gränser kan du behöva förfina partitioneringsstrategin eller dela upp data ytterligare. Du kan behöva kombinera två eller flera strategier.
Övervaka systemet för att kontrollera att data distribueras som förväntat och att partitionerna kan hantera belastningen. Den faktiska användningen matchar inte alltid vad en analys förutsäger. Du kan behöva balansera om partitionerna eller göra om vissa delar av systemet för att ge det nödvändiga saldot.

Vissa molnmiljöer allokerar resurser baserat på infrastrukturgränser. Se till att gränserna för den valda gränsen ger tillräckligt med utrymme för förväntad tillväxt i datavolym, datalagring, bearbetningskraft och bandbredd.

Om du till exempel använder Azure Table Storage finns det en gräns för mängden begäranden som en enskild partition kan hantera under en viss tidsperiod. Mer information finns i skalbarhets- och prestandamål för standardlagringskonton. En upptagen shard kan kräva mer resurser än en enskild partition kan hantera. Du kan behöva partitionera om fragmentet för att sprida belastningen. Om den totala storleken eller dataflödet för dessa tabeller överskrider kapaciteten för ett lagringskonto kan du behöva skapa fler lagringskonton och sprida tabellerna över dessa konton.

Utforma partitioner för frågeprestanda

Du kan öka frågeprestandan med hjälp av små datauppsättningar och köra parallella frågor. Varje partition bör innehålla en liten del av hela datamängden. Den här volymminskningen kan förbättra prestandan för sökfrågor. Partitionering är dock inte ett alternativ till lämplig databasdesign och konfiguration. Se till att du implementerar de index som behövs.

Följ dessa steg när du utformar partitioner för frågeprestanda:

Granska programmets krav och prestanda.
- Använd affärskrav för att fastställa kritiska frågor som alltid måste utföras snabbt.
- Övervaka systemet för att identifiera frågor som utförs långsamt.
- Fastställ de frågor som presterar oftast. Även om en enskild fråga har en minimal kostnad kan den kumulativa resursförbrukningen vara betydande.
Partitionering av data som orsakar långsamma prestanda.
- Begränsa storleken på varje partition så att frågesvarstiden ligger inom målet.
- Om du använder horisontell partitionering utformar du shardnyckeln så att programmet enkelt kan välja rätt partition. Den här specifikationen förhindrar att frågan genomsöker varje partition.
- Överväg platsen för en partition. Försök att lagra data i partitioner som ligger geografiskt nära de program och användare som har åtkomst till dem.
Om en entitet har dataflödes- och frågeprestandakrav använder du funktionell partitionering som baseras på den entiteten. Om den här allokeringen fortfarande inte uppfyller kraven kan du lägga till horisontell partitionering. En enskild partitioneringsstrategi är vanligtvis tillräcklig, men i vissa fall är det mer effektivt att kombinera båda strategierna.
Kör frågor parallellt mellan partitioner för att förbättra prestandan.

Utforma partitioner för tillgänglighet

Partitioneringsdata för att förbättra tillgängligheten för program. Partitionering säkerställer att hela datamängden inte har en enda felpunkt, och du kan oberoende hantera enskilda delmängder av datamängden.

Tänk på följande faktorer som påverkar tillgängligheten:

Fastställ datans allvarlighetsgrad. Identifiera kritiska affärsdata, till exempel transaktioner och mindre kritiska driftdata, till exempel loggfiler.

Lagra kritiska data i partitioner med hög tillgänglighet och skapa en lämplig säkerhetskopieringsplan.
Upprätta separata hanterings- och övervakningsförfaranden för olika datauppsättningar.
Placera data som har samma kritiska nivå i samma partition så att de kan säkerhetskopieras med samma frekvens. Du kan till exempel behöva säkerhetskopiera partitioner som innehåller transaktionsdata oftare än partitioner som innehåller loggnings- eller spårningsinformation.

Hantera enskilda partitioner. Utforma partitioner för att stödja oberoende hantering och underhåll. Den här metoden ger flera fördelar, till exempel:

Om en partition misslyckas kan den återställas oberoende av varandra utan program som har åtkomst till data i andra partitioner.
Genom att partitionera data efter geografiskt område kan schemalagda underhållsaktiviteter utföras vid låg belastning för varje plats. Se till att partitionerna inte är så stora att de förhindrar att planerat underhåll slutförs under den här perioden.

Replikera kritiska data mellan partitioner. Den här strategin förbättrar tillgängligheten och prestandan men kan även medföra konsekvensproblem. Det tar tid att synkronisera ändringar med varje replik. Under synkroniseringen innehåller olika partitioner olika datavärden.

Optimera programkod för att använda partitioner

Partitionering ökar komplexiteten i systemets design och utveckling. Partitionera data som en grundläggande del av systemdesignen även om systemet inledningsvis bara innehåller en enda partition. Om du hanterar partitionering som en eftertanke är det svårt eftersom du redan har ett system att underhålla. Du kan:

Måste ändra dataåtkomstlogik.
Måste migrera stora mängder befintliga data för att distribuera dem mellan partitioner.
Stöter på utmaningar eftersom användarna förväntar sig att fortsätta använda systemet under migreringen.

I vissa fall är partitionering inte viktigt eftersom den inledande datamängden är liten och en enskild server enkelt kan hantera den. Vissa arbetsbelastningar kan gå utan partitioner, men många kommersiella system måste utökas i takt med att antalet användare ökar.

Vissa små datalager drar också nytta av partitionering. Hundratals samtidiga klienter kan till exempel komma åt ett litet datalager. Om du partitionerade data i den här situationen kan det bidra till att minska konkurrensen och förbättra dataflödet.

Tänk på följande när du utformar ett datapartitioneringsschema:

Minimera dataåtkomståtgärder mellan partitioner. Försök att hålla ihop data för de vanligaste databasåtgärderna i en partition för att minimera dataåtkomståtgärder mellan partitioner. Det kan vara mer tidskrävande att fråga mellan partitioner i stället för att fråga inom en enda partition. Men att optimera partitioner för en uppsättning frågor kan påverka andra frågeuppsättningar negativt. Om du måste fråga mellan partitioner minimerar du frågetiden genom att köra parallella frågor och aggregera resultaten i programmet. I vissa fall kan du inte använda den här metoden, till exempel om resultatet från en fråga används i nästa fråga.

Replikera statiska referensdata. Om frågor använder relativt statiska referensdata, till exempel postnummertabeller eller produktlistor, bör du överväga att replikera dessa data i alla partitioner för att minska separata uppslagsåtgärder i olika partitioner. Den här metoden kan också minska sannolikheten för att referensdata blir en frekvent datauppsättning med tung trafik från hela systemet. Det finns extra kostnader som associeras med synkronisering av ändringar i referensdata.

Minimera kopplingar mellan partitioner. Om möjligt minimerar du kraven på referensintegritet mellan vertikala och funktionella partitioner. I dessa scheman ansvarar programmet för att upprätthålla referensintegriteten mellan partitioner. Frågor som kopplar data över flera partitioner är ineffektiva eftersom programmet vanligtvis utför frågor i följd som baseras på en nyckel och sedan en sekundärnyckel. Överväg i stället att replikera eller avnormalisera relevanta data. Om det krävs kopplingar mellan partitioner kör du parallella frågor över partitionerna och ansluter data i programmet.

Anamma slutlig konsistens. Utvärdera om stark konsekvens är ett krav. En vanlig metod i distribuerade system är att implementera eventuell konsistens. Data i varje partition uppdateras separat och programlogik säkerställer att uppdateringarna slutförs. Applikationslogiken hanterar också de inkonsekvenser som uppstår vid databasfrågor medan en eventuellt konsistent operation körs.

Fundera på hur frågor hittar rätt partition. Om en fråga måste söka igenom alla partitioner för att hitta nödvändiga data påverkar den prestanda avsevärt, även när flera parallella frågor körs. Med vertikal och funktionell partitionering kan frågor ange partitionen. Å andra sidan kan horisontell partitionering göra det svårt att hitta ett objekt eftersom varje shard har samma schema. En vanlig lösning är att underhålla en karta som används för att söka efter fragmentplatsen för objekt. Implementera strukturen i partitioneringslogiken av applikationen. Det kan också underhållas av datalagret om datalagret stöder transparent partitionering.

Balansera om skärvor med jämna mellanrum. Med horisontell partitionering kan ombalansering av shards hjälpa till att fördela data jämnt efter storlek och arbetsbelastning. Balansera om shards för att minimera hotspots, maximera frågeprestanda och kringgå fysiska lagringsbegränsningar. Den här uppgiften är komplex och kräver ofta ett anpassat verktyg eller en anpassad process.

Replikera partitioner. Replikera varje partition för att ge ytterligare skydd mot fel. Om en enskild replik misslyckas dirigeras frågor till en fungerande kopia.

Utöka skalbarheten till en annan nivå. Om du når de fysiska gränserna för en partitioneringsstrategi kan du behöva utöka skalbarheten till en annan nivå. Om partitioneringen till exempel är på databasnivå kan du behöva hitta eller replikera partitioner i flera databaser. Om partitionering redan finns på databasnivå och det finns fysiska begränsningar kan du behöva hitta eller replikera partitioner på flera värdkonton.

Undvik transaktioner som har åtkomst till data i flera partitioner. Vissa datalager implementerar transaktionskonsekvens och integritet för åtgärder som ändrar data men bara när data finns i en enda partition. Om du behöver transaktionsstöd över flera partitioner implementerar du det som en del av programlogik eftersom de flesta partitioneringssystem inte har inbyggt stöd.

Alla datalager kräver viss driftshanterings- och övervakningsaktivitet. Dessa uppgifter omfattar inläsning av data, säkerhetskopiering och återställning av data, omorganisering av data och säkerställa att systemet fungerar korrekt och effektivt.

Tänk på följande faktorer som påverkar driftshanteringen:

Implementera lämpliga hanterings- och driftuppgifter när data partitioneras. Dessa uppgifter kan omfatta säkerhetskopiering och återställning, arkivering av data, övervakning av systemet och andra administrativa uppgifter. Det kan till exempel vara svårt att upprätthålla logisk konsekvens under säkerhetskopierings- och återställningsåtgärder.
Läs in data i flera partitioner och lägg till nya data som kommer från andra källor. Vissa verktyg och hjälpmedel kanske inte stöder uppdelade dataoperationer, till exempel att ladda in data i rätt partition.
Arkivera och ta bort data regelbundet. För att förhindra överdriven tillväxt av partitioner arkiverar och tar du bort data varje månad. Du kan behöva transformera data för att matcha ett annat arkivschema.
Leta upp dataintegritetsproblem. Överväg att köra en periodisk process för att hitta dataintegritetsproblem, till exempel data i en partition som refererar till information som saknas i en annan. Processen kan antingen automatiskt försöka åtgärda dessa problem eller generera en rapport för manuell granskning.

Balansera om partitioner

När ett system mognar kan du behöva justera partitioneringsschemat. Till exempel kan enskilda partitioner börja ta emot en oproportionerlig mängd trafik och bli heta, vilket leder till överdriven konkurrens. Eller så kanske du har underskattat mängden data i vissa partitioner, vilket gör att partitionerna närmar sig kapacitetsbegränsningar.

Vissa datalager, till exempel Azure Cosmos DB, kan automatiskt balansera om partitioner. I andra fall kan du balansera om partitioner i två steg:

Fastställ en ny partitioneringsstrategi.
- Vilka partitioner måste delas eller kombineras?
- Vad är den nya partitionsnyckeln?
Migrera data från det gamla partitioneringsschemat till den nya uppsättningen partitioner.

Du kan behöva göra partitioner otillgängliga när du flyttar data, vilket kallas offlinemigrering. Beroende på datalagret kan du migrera data mellan partitioner när de används. Den här tekniken kallas online-migrering.

Offlinemigrering

Offlinemigrering minskar risken för konkurrens. Så här utför du offlinemigrering:

Markera partitionen som offline. Du kan markera en partition som skrivskyddad så att program fortfarande kan läsa data medan du flyttar den.
Dela samman och flytta data till de nya partitionerna.
Verifiera datan.
Ta de nya partitionerna i drift.
Ta bort den gamla partitionen.

Online-migrering

Onlinemigrering är mer komplext men mindre störande jämfört med offlinemigrering. Processen liknar offlinemigrering, men du markerar inte den ursprungliga partitionen som offline. Beroende på migreringsprocessens detaljnivå, till exempel objekt för objekt mot skärv för skärv, kan dataåtkomstkoden i klientprogrammen behöva läsa och skriva data som finns på två platser: den ursprungliga partitionen och den nya partitionen.

Azure-hantering

I följande avsnitt beskrivs rekommendationer för partitionering av data som lagras i Azure-tjänster.

Partition i Azure SQL Database

En enskild SQL-databas har en gräns för mängden data som den kan innehålla. Dataflödet begränsas av arkitekturfaktorer och antalet samtidiga anslutningar som stöds.

Elastiska pooler stöder horisontell skalning för en SQL-databas. Använd elastiska pooler för att partitionera dina data i shards som är spridda över flera SQL-databaser. Du kan också lägga till eller ta bort shards när datavolymen växer och krymper. Elastiska pooler kan också bidra till att minska konkurrensen genom att distribuera belastningen mellan databaser.

Varje shard implementeras som en SQL-databas. En shard kan innehålla mer än en datauppsättning. Varje datauppsättning kallas för en shardlet. Varje databas har metadata som beskriver de shardletar som den innehåller. En shardlet kan vara ett enskilt dataobjekt eller en grupp med objekt som delar samma shardlet-nyckel. I ett program med flera klienter kan shardlet-nyckeln till exempel vara klientorganisations-ID och alla data för en klientorganisation kan finnas i samma shardlet.

Program ansvarar för att associera en datauppsättning med en shardlet-nyckel. En separat SQL-databas fungerar som en global hanterare av shard-kartor. Den här databasen har en lista över alla shards och shardletar i systemet. Programmet ansluter till shard map manager-databasen för att hämta en kopia av fragmentkartan. Den lagrar shardkartan lokalt i cache och använder kartan för att dirigera dataförfrågningar till rätt del. Den här funktionen är dold bakom en serie API:er som finns i -klientbiblioteket för elastic database-funktionen i SQL Database, som är tillgänglig för Java och .NET.

Mer information om elastiska pooler finns i Skala ut med SQL Database.

För att minska svarstiden och förbättra tillgängligheten kan du replikera den globala shard map manager-databasen. Med prisnivåerna premium kan du konfigurera aktiv geo-replikering för att kontinuerligt kopiera data till databaser i olika regioner.

Du kan också använda SQL Data Sync för SQL Database eller Azure Data Factory för att replikera shard map manager-databasen mellan regioner. Den här typen av replikering körs regelbundet och är lämpligare om fragmentkartan ändras sällan och inte kräver premiumnivån.

Elastic Database innehåller två scheman för att mappa data till shardletar och lagra dem i shards:

En lista med fragmentkarta associerar en enda nyckel med en shardlet. I ett system med flera hyresgäster kan datan för varje hyresgäst associeras med en unik nyckel och lagras i sin egen shardlet. För att garantera isolering kan varje shardlet placeras i sin egen shard.

Ladda ned en Visio-fil av det här diagrammet.
En intervallshardkarta associerar en uppsättning sammanhängande nyckelvärden med en shardlet. Du kan till exempel gruppera data för en uppsättning hyresgäster, var och en med sin egen nyckel, inom samma shardlet. Det här schemat är billigare än en listshardkarta eftersom klienter delar datalagring, men det ger mindre isolering.

Ladda ned en Visio-fil av det här diagrammet

En enda shard kan innehålla data för flera shardletar. Till exempel kan du använda list-shardlets för att lagra data för olika icke-sammanhängande klientorganisationer i samma shard. Du kan också blanda intervallshardlets och listshardlets i samma fragment, men sedan adresseras de via olika kartor. Följande diagram visar den här metoden:

Ladda ner en Visio-fil av det här diagrammet.

Med elastiska pooler kan du lägga till och ta bort shards när datavolymen växer och krymper. Klientprogram kan skapa och ta bort delningar dynamiskt och transparent uppdatera manager för shard-kartan. Att ta bort en shard är dock en destruktiv åtgärd som också kräver att alla data i fragmentet tas bort.

Om ett program behöver dela upp en shard i två separata shards eller kombinera shards, använd verktyget split-merge-verktyg. Det här verktyget körs som en Azure-webbtjänst och migrerar data på ett säkert sätt mellan shards.

Partitioneringsschemat kan avsevärt påverka systemets prestanda. Det kan också påverka den hastighet med vilken shards måste läggas till eller tas bort, eller att data måste partitioneras om mellan shards. Tänk på följande:

Gruppera data som används tillsammans i samma fragment och undvik åtgärder som kommer åt data från flera shards. En shard är en SQL-databas i sig, och kopplingar mellan databaser måste utföras på klientsidan när åtgärder får åtkomst till flera shards.

Även om SQL Database inte stöder kopplingar mellan databaser kan du använda Elastic Database-verktyg för att utföra frågor med flera fragment. En fråga med flera fragment skickar enskilda frågor till varje databas och sammanfogar resultatet.
Utforma ett system som inte har beroenden mellan shards. Referensintegritetsbegränsningar, utlösare och lagrade procedurer i en databas kan inte referera till objekt i en annan.
Överväg att replikera data mellan shards om du har referensdata som ofta används av frågor. Den här metoden kan eliminera behovet av att koppla data mellan databaser. Helst bör sådana data vara statiska eller långsamma för att minimera replikeringsarbetet och minska risken för att de blir inaktuella.
Använd samma schema för shardletar som tillhör samma fragmentkarta. Den här vägledningen tillämpas inte av SQL Database, men datahantering och frågor är komplexa om varje shardlet har ett annat schema. Skapa i stället separata fragmentkartor för varje schema. Du kan lagra data som tillhör olika shardletar i samma fragment.
Lagra data i samma del eller implementera eventuell konsistens om din affärslogik behöver utföra transaktioner. Transaktionsåtgärder stöds endast för data som finns i en shard och inte mellan shards. Transaktioner kan sträcka sig över shardletar om de ingår i samma fragment.
Placera skärvor nära de användare som behöver åtkomst till data i dessa skärvor. Den här strategin hjälper till att minska svarstiden.
Undvik att ha en kombination av mycket aktiva och relativt inaktiva shards. Försök att sprida belastningen jämnt över partitioner. Du kan behöva hash-partitioneringsnycklarna. Om du geolokaliserar shards, kontrollera att de hashade nycklarna mappas till shardlets som finns i shards som är placerade nära användare som har åtkomst till dessa data.

Partition i Azure Blob Storage

Med Blob Storage kan du lagra stora binära objekt. Använd blockblobar i scenarier som kräver att du snabbt laddar upp eller laddar ned stora mängder data. Använd sidblobar för program som kräver slumpmässig, snarare än seriell, åtkomst till delar av data.

Varje blockblob eller sidblob lagras i en container i ett Azure Storage-konto. Använd containrar för att gruppera relaterade blobar som har samma säkerhetskrav. Den här gruppering är logisk snarare än fysisk. I en container har varje blob ett unikt namn.

Partitionsnyckeln för en blob är kontonamnet, containernamnet och blobnamnet. Partitionsnyckeln används för att partitionera data i intervall. Dessa intervall lastbalanseras över hela systemet. Blobar kan distribueras över många servrar för att skala ut åtkomsten till dem. En enskild blob kan bara hanteras av en enskild server.

Om ditt namngivningsschema använder tidsstämplar eller numeriska identifierare kan det leda till överdriven trafik till en partition. Det förhindrar att systemet effektivt belastningsutjämnar. Om du till exempel har dagliga åtgärder som använder ett blobobjekt med en tidsstämpel, till exempel ååååmm-dd, går all trafik för åtgärden till en enda partitionsserver. Lägg till en tresiffrig hash framför namnet i stället. Mer information finns i namngivningskonvention för partitioner.

Åtgärderna för att skriva ett enda block eller en sida är atomiska, men åtgärder som omfattar block, sidor eller blobar är inte det. Om du behöver säkerställa konsekvens när skrivåtgärder utförs mellan block, sidor och blobar tar du ut ett skrivlås med hjälp av ett bloblån.

Överväganden

Datapartitionering introducerar vissa utmaningar och komplexiteter som du behöver tänka på.

Datasynkronisering mellan partitionerna kan bli en utmaning. Se till att uppdateringar eller ändringar i en partition sprids till de andra partitionerna i tid och konsekvent.
Redundans- och haveriberedskapsprocesser blir komplexa när du behöver samordna säkerhetskopieringen och återställningen av flera partitioner. Dataintegritetsproblem kan uppstå om vissa partitioner eller deras säkerhetskopior är skadade eller otillgängliga.
Datapartitionering kan påverka prestanda och tillförlitlighet om du behöver fråga mellan partitioner och när du balanserar om partitionerna om data växer ojämnt.

Checklista för tillförlitlighet

Se den fullständiga uppsättningen rekommendationer.

tillförlitlighetschecklista

Dela via

Rekommendationer för datapartitionering