Rekommendationer för datapartitionering

Artikel
11/15/2023

Gäller för denna checklista för Azure Well-Architected Framework Reliability:

RE:06	Implementera en strategi för aktuell och tillförlitlig skalning på program-, data- och infrastrukturnivå.

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 din partitioneringsstrategi noggrant för att maximera fördelarna och minimera negativa effekter.

Anteckning

I den här artikeln betyder termen partitionering att en process delar in data i fysiskt separata datalager. Den skiljer sig från SQL Server tabellpartitionering.

Därför ska du partitionera data

Bättre skalbarhet. När du skalar upp ett enda databassystem når databasen så småningom en gräns för fysisk maskinvara. 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.
Bättre säkerhet. 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.
Gör verksamheten flexibel. 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.
Dela upp datalager efter användningsmönster. 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 bloblagring och lagra strukturerade data i en dokumentdatabas. Mer information finns i Förstå datalagermodeller.
Bättre tillgänglighet. 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.

Utforma partitioner

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

Horisontell (vågrät) partitionering (kallas även 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 kundorder.
Vertikal (lodrät) partitionering. Vid vertikal partitionering innehåller varje partition en delmängd av fälten för objekten i datalagret. Fälten är uppdelade enligt användningsmönster. Du kan till exempel placera ofta använda fält i en vertikal partition och fält som används mer sällan 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 fragment och sedan dela upp ytterligare inom fragmenten med vertikal partitionering.

Horisontell partitionering (sharding)

Följande bild visar ett exempel på horisontell partitionering eller horisontell partitionering. Det här exemplet delar in produktinventeringsdata i shards som baseras på produktnyckeln. Varje fragment innehåller data för ett sammanhängande intervall fragmentnycklar (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 väl ä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 shards kan vara stora, men varje objekt i fragmentet har ett lågt antal åtkomståtgärder. 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 frekventa 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 horisontell partitioneringsnyckel som minimerar framtida behov av att dela upp stora shards, kombinera små shards i större partitioner eller ändra schemat. De här åtgärderna är tidskrävande och kan kräva att du tar en eller flera shards offline.

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

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

Vertikal 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 antalet lager och det senaste ordnade datumet.

I det här exemplet frågar programmet regelbundet efter produktnamn, beskrivning och pris när produktinformationen visas för kunderna. Lagerantalet och senaste sorteringsdatum 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 senast ordnat datum). Långsamma data är en bra kandidat för att ett program ska cachelagrat i minnet.
Du kan lagra känsliga data i en separat partition med extra säkerhetskontroller.
Vertikal partitionering kan minska mängden samtidig åtkomst som behövs.

Vertikal partitionering fungerar på enhetsnivå inom datalagret. En enhet normaliseras delvis för att bryta ned den från ett brett objekt till en uppsättning mer begränsade objekt. Den 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 distinkt 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 skrivskyddade data 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 minska konkurrensen i dataåtkomsten 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önstren, till exempel storleken på resultatuppsättningen som varje fråga returnerar, åtkomstfrekvens, inbyggd svarstid och beräkningsbearbetningskrav på serversidan. I många fall kräver några större entiteter merparten av 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 över partitionerna för att uppfylla skalbarhetsmålen. För horisontell partitionering väljer du rätt shardnyckel för att säkerställa jämn distribution. Mer information finns i Mönster för horisontell partitionering.
Se till att varje partition har tillräckligt med resurser för att hantera skalbarhetskraven vad gäller datastorlek och dataflöde. Beroende på datalagret kan det finnas en gräns för varje partition för 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 få det saldo som krävs.

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 ökning av 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 fler 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 genom att använda små datauppsättningar och köra parallella frågor. Varje partition bör innehålla en liten del av hela datauppsättningen. Den här minskningen i volym kan ge bättre prestanda för frågor. Partitionering är dock inte ett alternativ till lämplig databasdesign och konfiguration. Se till att du implementerar de nödvändiga indexen.

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 vilka kritiska frågor som alltid måste utföras snabbt.
- Övervaka systemet för att identifiera frågor som körs långsamt.
- Fastställ de frågor som utförs 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 svarstiden för frågorna 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 placeringen av partitionen. 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 enda partitioneringsstrategi är vanligtvis lämplig, 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 prestanda.

Utforma partitioner för tillgänglighet

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

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

Fastställ datas 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 övervakningsprocedurer för olika datauppsättningar.
Placera data som har samma allvarlighetsgrad 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.

Designöverväganden för program

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 en utmaning eftersom du redan har ett live-system att underhålla. Du kan:

Du måste ändra dataåtkomstlogik.
Du 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 datauppsättningen ä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å det här när du utformar datapartitioneringsscheman:

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 uppsättningar frågor 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 för att synkronisera ändringar av referensdata.

Minimera kopplingar mellan partitioner. När det är möjligt ska du minimera kraven på referensintegritet mellan lodräta och funktionella partitioner. I dessa scheman ansvarar programmet för att upprätthålla referensintegritet mellan partitioner. Frågor som kopplar data över flera partitioner är ineffektiva eftersom programmet vanligtvis utför på varandra följande frågor som baseras på en nyckel och sedan en sekundärnyckel. Överväg istället att replikera eller avnormalisera relevanta data. Om det behövs kopplingar mellan partitioner kör du parallella frågor över partitionerna och kopplar data i programmet.

Tänk på den slutliga konsekvensen. Utvärdera om stark konsekvens är ett krav. En vanlig metod i distribuerade system är att implementera slutlig konsekvens. Data i varje partition uppdateras separat och programlogik säkerställer att uppdateringarna slutförs. Programlogik hanterar också de inkonsekvenser som uppstår vid frågor mot data medan en så småningom konsekvent åtgärd 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 prestandan 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 fragment 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 den här kartan i programmets horisontella logik. Det kan också underhållas av datalagret om datalagret stöder transparent horisontell partitionering.

Balansera om shards 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 begränsningarna för en partitioneringsstrategi kan du behöva utöka skalbarheten en nivå. Om du till exempel partitionerar på databasnivå kan behöva du 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 kommer åt 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 operativ hantering och övervakning. Dessa uppgifter omfattar inläsning av data, säkerhetskopiering och återställning av data, omorganisering av data och säkerställande av att systemet fungerar korrekt och effektivt.

Tänk på de här faktorerna som påverkar den operativa hanteringen:

Implementera lämpliga hanterings- och driftuppgifter när data partitioneras. Det kan handla om säkerhetskopiering, återställning, dataarkivering, systemövervakning 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 verktyg kanske inte stöder horisontella dataåtgärder, till exempel att läsa in data i rätt partition.
Arkivera och ta bort data regelbundet. För att förhindra den stora tillväxten 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. Enskilda partitioner kan till exempel 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 kapacitetsgränser.

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 onlinemigrering.

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 när du flyttar dem.
Dela samman och flytta data till de nya partitionerna.
Kontrollera data.
Ta de nya partitionerna online.
Ta bort den gamla partitionen.

Onlinemigrering

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 kornighet, till exempel objekt efter objekt jämfört med shard av shard, 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-underlättande

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

Partition i Azure SQL database

Varje enskild SQL-databas kan innehålla en viss datavolym. Genomströmningen begränsas av arkitekturen och hur många 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 mängden data växer och krymper. Elastiska pooler kan också minska konkurrensen genom att distribuera belastningen mellan databaser.

Varje fragment (eller 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 enda dataobjekt eller en grupp med objekt som delar samma shardlet-nyckel. I ett program med flera klienter kan shardletnyckeln 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 ansvarar för en övergripande fragmentkarta. Den här databasen innehåller en lista över alla shards och shardletar i systemet. Programmet ansluter till shard map manager-databasen för att hämta en kopia av shardkartan. Den cachelagrar shardkartan lokalt och använder kartan för att dirigera databegäranden till rätt fragment. Den här funktionen är dold bakom en serie API:er som finns i klientbiblioteket för funktionen Elastic Database i SQL Database, som är tillgänglig för Java och .NET.

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

Om du vill minska svarstiden och förbättra tillgängligheten kan du replikera den globala shard map manager-databasen. Med premiumprisnivåerna 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 shardkartan ändras sällan och inte kräver premiumnivån.

Elastic Database ger två scheman för att mappa data till shardletar och lagra dem i fragment:

En listshardkarta associerar en enda nyckel med en shardlet. I ett flerklientsystem kan data för varje klient kopplas till en unik nyckel och lagras i en egen shardlet. För att garantera isolering kan varje shardlet hållas inom sin egen shard.

Ladda ned en Visio-fil med 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 klienter, var och en med sin egen nyckel, inom samma shardlet. Det här schemat är billigare än en list-shardkarta eftersom klienter delar datalagring, men det ger mindre isolering.

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

En enda shard kan innehålla data för flera shardletar. Du kan till exempel använda listshardletar och lagra data för olika, icke sammanhängande klienter i samma fragment. Du kan också blanda intervall-shardletar och lista shardletar i samma shard, men sedan åtgärdas de via olika kartor. Följande diagram visar den här metoden:

Ladda ned en Visio-fil med 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 shards dynamiskt och transparent uppdatera shardkarthanteraren. Att ta bort ett fragment är dock en destruktiv åtgärd. Det krävs att du också tar bort alla data i fragmentet.

Om ett program behöver dela upp en shard i två separata shards eller kombinera shards använder du verktyget split-merge. 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 också på följande faktorer:

Gruppera data som används tillsammans i samma shard 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 shard. En fråga med flera shard 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 över 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 shardkarta. 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 shardkartor för varje schema. Du kan lagra data som tillhör olika shardletar i samma shard.
Lagra data i samma shard eller implementera eventuell konsekvens om affärslogik behöver utföra transaktioner. Transaktionsåtgärder stöds bara för data som finns i en shard och inte över shards. Transaktioner kan sträcka sig över shardletar om de ingår i samma shard.
Placera shards nära de användare som har åtkomst till data i dessa shards. Den här strategin kan förkorta svarstiden.
Undvik att ha en kombination av mycket aktiva och relativt inaktiva shards. Försök att sprida belastningen jämnt över fragmenten. Du kan behöva hash-partitioneringsnycklarna. Om du geo-lokaliserar shards kontrollerar du att hashade nycklar mappas till shardletar som lagras i shards som lagras nära de 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-lagringskonto. Använd containrar för att gruppera relaterade blobar som har samma säkerhetskrav. Den här grupperingen är logisk snarare än fysisk. Varje blob har ett unikt namn i en container.

Partitionsnyckeln för en blob är kontonamnet, containernamnet och blobnamnet. Partitionsnyckeln används för att partitionera data i intervall. Dessa intervall lastbalanseras i hela systemet. Blobar kan distribueras över många servrar för att skala ut åtkomsten till dem. En enda blob kan bara hanteras av en enda 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ämning. Om du till exempel har dagliga åtgärder som använder ett blobobjekt med en tidsstämpel, till exempel yyyy-mm-dd, går all trafik för åtgärden till en enda partitionsserver. Prefixet är i stället namnet med en tresiffrig hash. 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 medför 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.

Checklista för tillförlitlighet

Share via

Rekommendationer för datapartitionering