Richtlijnen voor gegevenspartitionering

In veel grootschalige oplossingen worden gegevens onderverdeeld in partities die afzonderlijk kunnen worden beheerd en geopend. Partitioneren kan de schaalbaarheid verbeteren, conflicten verminderen en de prestaties optimaliseren. Het kan ook een mechanisme bieden voor het delen van gegevens met behulp van een gebruikspatroon. U kunt bijvoorbeeld oudere gegevens archiveren in goedkopere gegevensopslag.

De partitioneringsstrategie moet echter zorgvuldig worden gekozen om de voordelen te maximaliseren terwijl negatieve effecten worden geminimaliseerd.

Waarom gegevens partitioneren?

• Schaalbaarheid te verbeteren. Wanneer u een individueel databasesysteem opschaalt, zal dit uiteindelijk een fysieke hardwarelimiet bereiken. Als u gegevens over meerdere partities verdeelt, die elk op een afzonderlijke server worden gehost, kunt u het systeem bijna voor onbepaalde tijd uitschalen.

• Prestaties te verbeteren. Bewerkingen voor gegevenstoegang op elke partitie vinden plaats over een kleinere hoeveelheid gegevens. Correct gedaan, partitioneren kan uw systeem efficiënter maken. Bewerkingen die invloed hebben op meer dan één partitie kunnen parallel worden uitgevoerd.

• Beveiliging te verbeteren. In sommige gevallen kunt u gevoelige en niet-gevoelige gegevens scheiden in verschillende partities en verschillende beveiligingscontroles toepassen op de gevoelige gegevens.

• Operationele flexibiliteit te bieden. Partitionering biedt veel mogelijkheden voor het verfijnen van bewerkingen, het maximaliseren van de administratieve efficiëntie en het minimaliseren van de kosten. U kunt bijvoorbeeld verschillende strategieën voor beheer, bewaking, back-up en herstel en andere beheertaken definiëren op basis van het belang van de gegevens in elke partitie.

• Het gegevensarchief aanpassen aan het gebruikspatroon. Partitioneren zorgt ervoor dat elke partitie wordt geïmplementeerd op een ander type gegevensarchief, op basis van de kosten en de ingebouwde functies die het gegevensarchief biedt. Grote binaire gegevens kunnen bijvoorbeeld worden opgeslagen in blobopslag, terwijl er meer gestructureerde gegevens in een documentdatabase kunnen worden opgeslagen. Zie Het juiste gegevensarchief kiezen voor meer informatie.

• Beschikbaarheid te verbeteren. Het scheiden van gegevens over meerdere servers voorkomt een Single Point of Failure. Als één exemplaar mislukt, zijn alleen de gegevens in die partitie niet beschikbaar. Bewerkingen op andere partities kunnen worden voortgezet. Voor paaS-gegevensarchieven (Managed Platform as a Service) is deze overweging minder relevant, omdat deze services zijn ontworpen met ingebouwde redundantie.

Partities ontwerpen

Er zijn drie typische strategieën voor het partitioneren van gegevens:

• Horizontale partitionering (vaak sharding genoemd). In deze strategie is elke partitie een afzonderlijk gegevensarchief, maar alle partities hebben hetzelfde schema. Elke partitie wordt een shard genoemd en bevat een specifieke subset van de gegevens, zoals alle orders voor een specifieke set klanten.

• Verticale partitionering. In deze strategie bevat elke partitie een subset van de velden voor items in het gegevensarchief. De velden worden onderverdeeld volgens hun gebruikspatroon. Veelgebruikte velden kunnen bijvoorbeeld in een verticale partitie worden geplaatst, en minder vaak gebruikte velden in een andere.

• Functionele partitionering. In deze strategie worden gegevens samengevoegd op basis van hoe deze worden gebruikt door elke begrensde context in het systeem. Een e-commercesysteem kan bijvoorbeeld factuurgegevens opslaan in één partitie en productinventarisgegevens in een andere.

Deze strategieën kunnen worden gecombineerd en we raden u aan ze allemaal te overwegen wanneer u een partitioneringsschema ontwerpt. U kunt bijvoorbeeld gegevens onderverdelen in shards en vervolgens de gegevens in elke shard met verticale partities verder onderverdelen.

Horizontale partitionering (sharding)

In afbeelding 1 ziet u horizontale partitionering of sharding. In dit voorbeeld worden productinventarisgegevens onderverdeeld in shards op basis van de productcode. Elke shard bevat de gegevens voor een aaneengesloten reeks shard-sleutels (A-G en H-Z), alfabetisch gerangschikt. Sharding verspreidt de belasting over meer computers, waardoor conflicten worden verminderd en de prestaties worden verbeterd.

Afbeelding 1: gegevens horizontaal partitioneren (sharding) op basis van een partitiesleutel.

De belangrijkste factor is de keuze van een sharding-sleutel. Het kan lastig zijn om de sleutel te wijzigen als het systeem wordt uitgevoerd. De sleutel moet ervoor zorgen dat gegevens worden gepartitioneerd om de werkbelasting zo gelijkmatig mogelijk over de shards te verdelen.

De shards hoeven niet dezelfde grootte te hebben. Het is belangrijker om het aantal aanvragen te verdelen. Sommige shards kunnen erg groot zijn, maar elk item heeft een laag aantal toegangsbewerkingen. Het is mogelijk dat andere shards kleiner zijn, maar elk item wordt veel vaker geopend. Het is ook belangrijk om ervoor te zorgen dat één shard de schaallimieten (qua capaciteit en verwerkingsbronnen) van het gegevensarchief niet overschrijdt.

Vermijd het maken van 'dynamische' partities die van invloed kunnen zijn op de prestaties en beschikbaarheid. Als u bijvoorbeeld de eerste letter van de naam van een klant gebruikt, wordt een niet-verdeelde verdeling veroorzaakt, omdat sommige letters vaker voorkomen. Gebruik in plaats daarvan een hash van een klant-id om gegevens gelijkmatiger over partities te verdelen.

Kies een shardingsleutel waarmee toekomstige vereisten worden geminimaliseerd om grote shards te splitsen, kleine shards te samenvoegen in grotere partities of het schema te wijzigen. Deze bewerkingen kunnen veel tijd in beslag nemen en halen mogelijk een of meer shards offline terwijl ze worden uitgevoerd.

Als shards worden gerepliceerd, is het mogelijk sommige replica's online te bewaren terwijl anderen worden verdeeld, samengevoegd of opnieuw geconfigureerd. Het systeem moet echter mogelijk de bewerkingen beperken die kunnen worden uitgevoerd tijdens de herconfiguratie. De gegevens in de replica's kunnen bijvoorbeeld worden gemarkeerd als alleen-lezen om inconsistenties van gegevens te voorkomen.

Zie Sharding-patroon voor meer informatie over horizontale partitionering.

Verticale partitionering

Het meest voorkomende gebruik voor verticale partitionering is het verminderen van de I/O- en prestatiekosten die zijn gekoppeld aan het ophalen van items die vaak worden geopend. Afbeelding 2 toont een voorbeeld van verticale partitionering. In dit voorbeeld worden verschillende eigenschappen van een item opgeslagen in verschillende partities. Eén partitie bevat gegevens die vaker worden geopend, waaronder productnaam, beschrijving en prijs. Een andere partitie bevat inventarisgegevens: het aantal aandelen en de laatste bestelde datum.

Afbeelding 2: gegevens verticaal partitioneren op basis van het gebruikspatroon.

In dit voorbeeld voert de toepassing regelmatig query's uit naar de productnaam, beschrijving en prijs bij het weergeven van details van het product aan klanten. Voorraadtelling en laatste bestelde datum worden in een afzonderlijke partitie bewaard, omdat deze twee items vaak samen worden gebruikt.

Andere voordelen van verticale partitionering:

• Relatief langzaam bewegende gegevens (productnaam, beschrijving en prijs) kunnen worden gescheiden van de dynamischere gegevens (voorraadniveau en laatste bestelde datum). Trage verplaatsing van gegevens is een goede kandidaat voor een toepassing om in het geheugen op te cachen.

• Gevoelige gegevens kunnen worden opgeslagen in een afzonderlijke partitie met aanvullende beveiligingsmaatregelen.

• Verticale partitionering kan de hoeveelheid gelijktijdige toegang verminderen die nodig is.

Verticale partitionering werkt op het entiteitsniveau binnen een gegevensarchief en normaliseert gedeeltelijk een entiteit voor het splitsen van een breed item naar een reeks beperkte items. Het is ideaal voor kolomgebaseerde gegevensopslag zoals HBase en Cassandra. Als de gegevens in een verzameling van kolommen waarschijnlijk niet zullen veranderen, kunt u ook overwegen kolomopslag in SQL Server te gebruiken.

Functionele partitionering

Wanneer het mogelijk is om een gebonden context te identificeren voor elk afzonderlijk bedrijfsgebied in een toepassing, is functionele partitionering een manier om isolatie- en gegevenstoegangsprestaties te verbeteren. Een ander veelvoorkomend gebruik voor functionele partitionering is het scheiden van alleen-lezen gegevens van alleen-lezengegevens. Afbeelding 3 toont een overzicht van functionele partitionering waar inventarisgegevens zijn gescheiden van de gegevens van de klant.

Afbeelding 3: Functioneel partitioneren van gegevens door gebonden context of subdomein.

Deze strategie voor partitioneren kan conflicten in de gegevenstoegang tussen de verschillende onderdelen van een systeem helpen verkleinen.

Het ontwerpen van partities voor schaalbaarheid

Het is essentieel om rekening te houden met grootte en belasting voor elke partitie en deze zo te balanceren dat gegevens worden gedistribueerd om te zorgen voor maximale schaalbaarheid. U moet echter ook de gegevens zo partitioneren dat deze de schaalgrenzen van één partitie-archief niet overschrijden.

Volg deze stappen bij het ontwerpen van partities voor schaalbaarheid:

1. Analyseer de toepassing om de toegangspatronen van de gegevens te begrijpen, zoals de grootte van de resultatenset die elke query geeft, de frequentie van toegang, de intrinsieke latentie en de verwerkingsvereisten voor berekeningen door de server. In veel gevallen vereisen enkele belangrijke entiteiten de meeste resources voor het verwerken.
2. Gebruik deze analyse om de huidige en toekomstige schaalbaarheidsdoelen te bepalen, zoals gegevensgrootte en workload. Verdeel vervolgens de gegevens over de partities om te voldoen aan het schaalbaarheidsdoel. Voor horizontale partitionering is het kiezen van de juiste shardsleutel belangrijk om ervoor te zorgen dat de distributie gelijkmatig is. Zie het sharding-patroon voor meer informatie.
3. Zorg ervoor dat elke partitie voldoende resources heeft om de schaalbaarheidsvereisten af te handelen, wat betreft de gegevensgrootte en doorvoer. Afhankelijk van het gegevensarchief is er mogelijk een limiet voor de hoeveelheid opslagruimte, verwerkingskracht of netwerkbandbreedte per partitie. Als de vereisten waarschijnlijk deze limieten overschrijden, moet u mogelijk uw partitioneringsstrategie verfijnen of gegevens verder splitsen, mogelijk door twee of meer strategieën te combineren.
4. Bewaak het systeem om te controleren of de gegevens worden gedistribueerd zoals verwacht en of de partities de belasting kunnen verwerken. Het werkelijke gebruik komt niet altijd overeen met wat een analyse voorspelt. Als dat het zo is, kan het mogelijk zijn om de partities opnieuw te verdelen of een deel van het systeem opnieuw te ontwerpen om het vereiste saldo te verkrijgen.

Sommige cloudomgevingen wijzen resources toe in termen van infrastructuurgrenzen. Zorg ervoor dat de limieten van de geselecteerde grens voldoende ruimte bieden voor alle verwachte groei van de hoeveelheid gegevens wat betreft gegevensopslag, verwerkingskracht en bandbreedte.

Als u bijvoorbeeld Azure Table Storage gebruikt, is er een limiet voor het aantal aanvragen dat kan worden verwerkt door één partitie in een bepaalde periode. (Zie voor meer informatie Schaalbaarheids- en prestatiedoelen voor Azure Storage.) Een bezet shard vereist mogelijk meer resources dan één partitie kan verwerken. Zo ja, dan moet de shard mogelijk opnieuw worden gepartitioneerd om de belasting te verdelen. Als de totale grootte of doorvoer van deze tabellen de capaciteit van een opslagaccount overschrijdt, moet u mogelijk extra opslagaccounts maken en de tabellen over deze accounts verdelen.

Partities voor queryprestaties ontwerpen

Queryprestaties kunnen vaak worden verhoogd door het gebruik van kleinere gegevenssets en het uitvoeren van parallelle query's. Elke partitie moet een klein deel van de volledige gegevensset bevatten. Deze vermindering van het volume kan de prestaties van query's verbeteren. Partitioneren is echter geen alternatief voor het op de juiste wijze ontwerpen en configureren van een database. Zorg er bijvoorbeeld voor dat u over de benodigde indexen beschikt.

Volg deze stappen bij het ontwerpen van partities voor queryprestaties:

1. Controleer de vereisten van de toepassing en de prestaties:

   • Gebruik bedrijfsvereisten om de kritieke query's te bepalen die altijd snel moeten worden uitgevoerd.
   • Bewaak het systeem om alle traagwerkende query's te identificeren.
   • Zoek welke query's het vaakst worden uitgevoerd. Zelfs als één query minimale kosten heeft, kan het cumulatieve resourceverbruik aanzienlijk zijn.

2. Partitioneer de gegevens die trage prestaties veroorzaken:

   • Beperk de grootte van elke partitie zodat de reactietijd van de query binnen een doel blijft.
   • Als u horizontale partitionering gebruikt, ontwerpt u de shardsleutel zodat de toepassing eenvoudig de juiste partitie kan selecteren. Dit voorkomt dat de query door elke partitie moet scannen.
   • Denk na over de locatie van een partitie. Probeer indien mogelijk om gegevens te bewaren in partities, die geografisch dicht bij de toepassingen en gebruikers liggen die hiertoe toegang hebben.

3. Als een entiteit eisen heeft aan de doorvoer en queryprestaties, gebruikt u functionele partitionering op basis van die entiteit. Als dit nog niet voldoet aan de vereisten, pas dan ook horizontale partitionering toe. In de meeste gevallen volstaat één partitioneringsstrategie, maar in sommige gevallen is het efficiënter om beide strategieën te combineren.

4. Overweeg query's parallel uit te voeren in meerdere partities om de prestaties te verbeteren.

Het ontwerpen van partities voor beschikbaarheid

Het partitioneren van gegevens kan de beschikbaarheid van toepassingen verbeteren, doordat ervoor wordt gezorgd dat de volledige gegevensset geen Single Point of Failure vormt en dat afzonderlijke subsets van de gegevensset onafhankelijk kunnen worden beheerd.

Houd rekening met de volgende factoren die van invloed zijn op de beschikbaarheid:

Hoe essentieel de gegevens zijn voor bedrijfsactiviteiten. Bepaal welke gegevens kritieke bedrijfsgegevens zijn, zoals transacties, en welke gegevens minder kritieke operationele gegevens zijn, zoals logboekbestanden.

• Overweeg kritieke gegevens op te slaan in maximaal beschikbare partities met een geschikt back-upplan.

• Stel afzonderlijke beheer- en bewakingsprocedures in voor de verschillende gegevenssets.

• Plaats gegevens die even kritiek zijn in dezelfde partitie, zodat hiervan met de juiste frequentie een back-up kan worden gemaakt. Partities met transactiegegevens moeten bijvoorbeeld vaker een back-up maken dan partities die logboek- of traceringsgegevens bevatten.

Hoe afzonderlijke partities kunnen worden beheerd. Het ontwerpen van partities voor de ondersteuning van onafhankelijk beheer en onderhoud biedt verschillende voordelen. Voorbeeld:

• Als een partitie mislukt, kan deze onafhankelijk worden hersteld zonder toepassingen die toegang hebben tot gegevens in andere partities.

• Door gegevens per geografisch gebied te partitioneren, kunnen geplande onderhoudstaken optreden tijdens daluren voor elke locatie. Zorg ervoor dat partities niet te groot zijn om te voorkomen dat gepland onderhoud tijdens deze periode wordt voltooid.

Het al dan niet repliceren van essentiële gegevens via partities. Deze strategie kan de beschikbaarheid en prestaties verbeteren, maar kan ook consistentieproblemen veroorzaken. Het duurt even om wijzigingen met elke replica te synchroniseren. Tijdens deze periode bevatten verschillende partities ook verschillende waarden.

Ontwerpoverwegingen voor toepassingen

Partitionering voegt complexiteit toe aan het ontwerp en de ontwikkeling van uw systeem. Beschouw partitioneren als een fundamenteel onderdeel van het systemontwerp, zelfs als het systeem in eerste instantie slechts één partitie bevat. Als u partitionering als een achteraf adresseert, is het lastiger omdat u al een live systeem hebt om te onderhouden:

• Logica voor gegevenstoegang moet worden gewijzigd.
• Grote hoeveelheden bestaande gegevens moeten mogelijk worden gemigreerd om deze over partities te verdelen.
• Gebruikers verwachten dat ze het systeem tijdens de migratie kunnen blijven gebruiken.

In sommige gevallen wordt partitioneren niet als belangrijk beschouwd omdat de initiële gegevensset te klein is, en eenvoudig door één server kan worden verwerkt. Dit geldt mogelijk voor sommige workloads, maar veel commerciële systemen moeten worden uitgebreid naarmate het aantal gebruikers toeneemt.

Bovendien zijn het niet alleen grote gegevensarchieven die profiteren van partitionering. Een klein gegevensarchief kan bijvoorbeeld veelvuldig worden gebruikt voor honderden gelijktijdige clients. Partitionering van gegevens kan in dit geval conflicten verminderen en de doorvoer verbeteren.

Houd rekening met de volgende punten bij het ontwerpen van een partitieschema van gegevens:

Minimaliseer bewerkingen voor gegevenstoegang tussen meerdere partities. Waar mogelijk, blijven gegevens voor de meest voorkomende databasebewerkingen samen in elke partitie, om bewerkingen met gegevenstoegang over meerdere partities te minimaliseren. Query's uitvoeren op meerdere partities kan tijdrovender zijn dan het uitvoeren van query's binnen één partitie, maar het optimaliseren van partities voor één set query's kan nadelig zijn voor andere sets query's. Als u query's op meerdere partities moet uitvoeren, minimaliseert u de querytijd door parallelle query's uit te voeren en de resultaten in de toepassing samen te stellen. (Deze benadering is in sommige gevallen mogelijk niet mogelijk, bijvoorbeeld wanneer het resultaat van de ene query wordt gebruikt in de volgende query.)

Overweeg om statische referentiegegevens te repliceren. Als query's relatief statische referentiegegevens gebruiken, zoals postcodetabellen of productlijsten, kunt u overwegen deze gegevens in alle partities te repliceren om afzonderlijke opzoekbewerkingen in verschillende partities te verminderen. Deze aanpak kan ook de kans verminderen dat de referentiegegevens een 'dynamische' gegevensset worden, met veel verkeer van over het hele systeem. Er zijn echter extra kosten verbonden aan het synchroniseren van wijzigingen in de referentiegegevens.

Minimaliseer joins tussen partities. Minimaliseer waar mogelijk de vereisten voor referentiële integriteit over meerdere verticale en functionele partities. In deze schema's is de toepassing verantwoordelijk voor het onderhouden van referentiële integriteit tussen partities. Query's die gegevens samenvoegen tussen meerdere partities zijn inefficiënt, omdat de toepassing doorgaans opeenvolgende query's moet uitvoeren op basis van een sleutel en vervolgens een refererende sleutel. Overweeg in plaats daarvan om de relevante gegevens te repliceren of denormaliseren. Als joins tussen partities nodig zijn, voert u parallelle query's uit over de partities en voegt u de gegevens in de toepassing toe.

Uiteindelijke consistentie is het streven. Evalueer of sterke consistentie daadwerkelijk vereist is. Een algemene benadering in gedistribueerde systemen is het implementeren van uiteindelijke consistentie. De gegevens in elke partitie worden afzonderlijk bijgewerkt en de toepassingslogica zorgt ervoor dat alle updates worden voltooid. Ook verwerkt deze de inconsistenties die zich kunnen voordoen bij het opvragen van gegevens, terwijl een uiteindelijk consistente bewerking wordt uitgevoerd.

Houd rekening met hoe query's de juiste partitie zoeken. Als een query alle partities moet scannen om de vereiste gegevens te zoeken, heeft dat een aanzienlijke invloed op de prestaties, zelfs wanneer er meerdere parallelle query's worden uitgevoerd. Met verticale en functionele partitionering kunnen query's op natuurlijke wijze de partitie opgeven. Horizontale partitionering kan daarentegen het lastig maken om een item te vinden, omdat elke shard hetzelfde schema heeft. Een typische oplossing voor het onderhouden van een kaart die wordt gebruikt om de shardlocatie voor specifieke items op te zoeken. Deze kaart kan worden geïmplementeerd in de sharding-logica van de toepassing of worden beheerd door de gegevensopslag als deze transparante sharding ondersteunt.

Overweeg regelmatig shards opnieuw te verdelen. Met horizontale partitionering kunt u shards gelijkmatig verdelen op grootte en werkbelasting om hotspots te minimaliseren, queryprestaties te maximaliseren en beperkingen voor fysieke opslag te omzeilen. Dit is echter een complexe taak die vaak het gebruik van een aangepast hulpprogramma of proces vereist.

Partities repliceren. Als u elke partitie repliceert, biedt dit extra beveiliging tegen fouten. Als één replica mislukt, kunnen query's worden omgeleid naar een werkende kopie.

Als u de fysieke grenzen van een strategie voor partitioneren bereikt, moet u mogelijk de schaalbaarheid naar een ander niveau uitbreiden. Als het partitioneren bijvoorbeeld op het databaseniveau gebeurt, moet u mogelijk partities in meerdere databases zoeken of repliceren. Als partitioneren al op het databaseniveau is en fysieke beperkingen een probleem zijn, kan dit betekenen dat u partities in meerdere hosting-accounts moet zoeken of repliceren.

Voorkom dat transacties gegevens in meerdere partities aanspreken. Sommige gegevensarchieven implementeren transactionele consistentie en integriteit voor bewerkingen die gegevens aanpassen, maar alleen als de gegevens zich in een enkele partitie bevinden. Als u transactionele ondersteuning voor meerdere partities nodig hebt, moet u dit waarschijnlijk als onderdeel van uw toepassingslogica implementeren, omdat de meeste systemen voor partitioneren geen systeemeigen ondersteuning bieden.

Alle gegevensarchieven vereisen enig operationeel beheer en enige controleactiviteit. De taken kunnen variëren van het laden van gegevens, een back-up maken en herstellen van gegevens, opnieuw indelen van gegevens tot ervoor zorgen dat het systeem correct en doeltreffend functioneert.

Houd rekening met de volgende factoren die invloed hebben op operationeel beheer:

• Hoe u de betreffende beheer- en operationele taken uitvoert wanneer de gegevens zijn gepartitioneerd. Deze taken kunnen onder meer back-ups maken en herstellen, gegevens archiveren, het systeem bewaken en andere beheertaken omvatten. Beheren van de logische consistentie tijdens de back-up en herstelbewerkingen kan bijvoorbeeld een uitdaging zijn.

• Hoe u de gegevens in meerdere partities laadt en nieuwe gegevens toevoegt die uit andere resources binnenkomen. Sommige functies en hulpprogramma's bieden mogelijk geen ondersteuning voor gedeelde gegevensbewerkingen, zoals het laden van gegevens naar de juiste partitie.

• Hoe de gegevens op regelmatige basis moeten worden gearchiveerd en verwijderd . Als u de overmatige groei van partities wilt voorkomen, moet u gegevens regelmatig archiveren en verwijderen (zoals maandelijks). Het kan nodig zijn om de gegevens te transformeren zodat deze overeenkomen met een ander archiefschema.

• Problemen met de gegevensintegriteit identificeren. Overweeg een periodiek proces uit te voeren om problemen met gegevensintegriteit te vinden, zoals gegevens in één partitie die verwijst naar ontbrekende informatie in een andere partitie. Het proces kan proberen deze problemen automatisch op te lossen of een rapport genereren voor handmatige controle.

Herverdeling van partities

Als een systeem volwassen wordt, moet u mogelijk het partitioneringsschema aanpassen. Afzonderlijke partities kunnen bijvoorbeeld een onevenredig volume aan verkeer krijgen en heet worden, wat leidt tot overmatige conflicten. Of u hebt het volume van gegevens in sommige partities onderschat, waardoor sommige partities capaciteitslimieten naderen.

Sommige gegevensarchieven, zoals Azure Cosmos DB, kunnen partities automatisch opnieuw verdelen. In andere gevallen is herverdeling een beheertaak die uit twee fasen bestaat:

1. Bepaal een nieuwe partitioneringsstrategie.

   • Welke partities moeten worden gesplitst (of mogelijk gecombineerd)?
   • Wat is de nieuwe partitiesleutel?

2. Gegevens migreren van het oude partitioneringsschema naar de nieuwe set partities.

Afhankelijk van het gegevensarchief kunt u mogelijk gegevens migreren tussen partities terwijl ze in gebruik zijn. Dit wordt onlinemigratie genoemd. Als dat niet mogelijk is, moet u partities mogelijk niet beschikbaar maken terwijl de gegevens worden verplaatst (offlinemigratie).

Offlinemigratie

Offlinemigratie is doorgaans eenvoudiger omdat het de kans op conflicten vermindert. Conceptueel werkt offlinemigratie als volgt:

1. Markeer de partitie offline.
2. Split-merge en verplaats de gegevens naar de nieuwe partities.
3. Verify the data.
4. Breng de nieuwe partities online.
5. Verwijder de oude partitie.

U kunt desgewenst een partitie markeren als alleen-lezen in stap 1, zodat toepassingen de gegevens nog steeds kunnen lezen terwijl ze worden verplaatst.

Online migratie

Onlinemigratie is complexer om uit te voeren, maar minder verstorend. Het proces is vergelijkbaar met offlinemigratie, behalve dat de oorspronkelijke partitie niet als offline is gemarkeerd. Afhankelijk van de granulariteit van het migratieproces (bijvoorbeeld item per item versus shard by shard), moet de code voor gegevenstoegang in de clienttoepassingen mogelijk het lezen en schrijven van gegevens verwerken die op twee locaties zijn opgeslagen, de oorspronkelijke partitie en de nieuwe partitie.

Volgende stappen

• Meer informatie over partitioneringsstrategieën voor specifieke Azure-services. Zie Strategieën voor gegevenspartitionering voor meer informatie.
• Schaalbaarheids- en prestatiedoelen voor Azure Storage

Verwante resources

• Het juiste gegevensarchief kiezen

De volgende ontwerppatronen zijn mogelijk relevant voor uw scenario:

• Het sharding-patroon beschrijft enkele veelvoorkomende strategieën voor shardinggegevens.

• Het indextabelpatroon laat zien hoe u secundaire indexen maakt voor gegevens. Een toepassing kan met deze methode snel gegevens ophalen met behulp van query's die niet verwijzen naar de primaire sleutel van een verzameling.

• In het gerealiseerde weergavepatroon wordt beschreven hoe u vooraf ingevulde weergaven genereert die gegevens samenvatten om snelle querybewerkingen te ondersteunen. Deze methode kan nuttig zijn in een gepartitioneerde gegevensarchief als de partities die de samengevatte gegevens bevatten op meerdere sites worden gedistribueerd.