Horizontale, verticale en functionele gegevenspartities

In veel grootschalige oplossingen worden gegevens onderverdeeld in partities die afzonderlijk kunnen worden beheerd en gebruikt. 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 en nadelige effecten te minimaliseren.

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, elk gehost op een afzonderlijke server, kunt u het systeem bijna voor onbepaalde tijd uitschalen.

• Prestaties verbeteren. Bewerkingen voor gegevenstoegang op elke partitie vinden plaats over een kleinere hoeveelheid gegevens. Juist gedaan, partitionering 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 in verschillende partities scheiden en verschillende beveiligingscontroles toepassen op de gevoelige gegevens.

• Operationele flexibiliteit te bieden. Partitionering biedt veel mogelijkheden voor het afstemmen van bewerkingen, het maximaliseren van administratieve efficiëntie en het minimaliseren van 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 meer gestructureerde gegevens kunnen worden opgeslagen in een documentdatabase. Zie Het juiste gegevensarchief kiezen.

• Beschikbaarheid te verbeteren. Het scheiden van gegevens over meerdere servers voorkomt een Single Point of Failure. Als er één exemplaar uitvalt, zijn alleen de gegevens in die partitie niet beschikbaar. Bewerkingen op andere partities kunnen worden voortgezet. Voor beheerde PaaS-gegevensopslag 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 gegevensopslag, 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 de ene partitie en de productinventarisgegevens in een andere.

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

Horizontale partitionering (sharding)

Afbeelding 1 toont 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 het aantal spreidingen wordt beperkt en de prestaties worden verbeterd.

Afbeelding 1: horizontale partitionering (sharding) van gegevens op basis van een partitiesleutel.

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

De shards hoeven niet dezelfde grootte te hebben. Het is belangrijker om het aantal aanvragen in balans te brengen. 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 (wat betreft capaciteit en verwerkingsbronnen) van het gegevensopslag niet overschrijdt.

Vermijd het maken van 'hot' partities die van invloed kunnen zijn op de prestaties en beschikbaarheid. Als u bijvoorbeeld de eerste letter van de naam van een klant gebruikt, ontstaat er een onevenwichtige verdeling, 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 die toekomstige vereisten minimaliseert om grote shards te splitsen, kleine shards samen te brengen 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 tijdens de herconfiguratie kunnen worden uitgevoerd. De gegevens in de replica's kunnen bijvoorbeeld worden gemarkeerd als alleen-lezen om inconsistenties in gegevens te voorkomen.

Zie sharding pattern (sharding-patroon) voor meer informatie over horizontale partitionering.

Verticale partitionering

Het meest voorkomende gebruik voor verticale partitionering is het verlagen van de I/O- en prestatiekosten voor het ophalen van items die vaak worden gebruikt. 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 gebruikt, waaronder productnaam, beschrijving en prijs. Een andere partitie bevat inventarisgegevens: het aantal voorraad en de laatste geordende datum.

Afbeelding 2: gegevens verticaal partitioneren op 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. Het aantal voorraad en de laatste geordende datum worden op een afzonderlijke partitie geplaatst, 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 geordende datum). Gegevens die langzaam worden verplaatst, zijn een goede kandidaat voor een toepassing om in het cachegeheugen op te nemen.

• Gevoelige gegevens kunnen worden opgeslagen in een afzonderlijke partitie met extra 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 contextgrens te identificeren voor elk afzonderlijk bedrijfsgebied in een toepassing, is functionele partitionering een manier om de isolatie en prestaties van gegevenstoegang te verbeteren. Een ander veelgebruikt gebruik voor functionele partitionering is het scheiden van lees-/schrijfgegevens 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 op begrensde 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 belangrijk om de juiste shardsleutel te kiezen 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 aan de schaalbaarheidsvereisten te voldoen, wat betreft gegevensgrootte en doorvoer. Afhankelijk van het gegevensopslag 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 uitsplitsen, waarbij mogelijk twee of meer strategieën worden gecombineerd.
4. Controleer het systeem om te controleren of de gegevens zijn gedistribueerd zoals verwacht en of de partities de belasting kunnen verwerken. Het werkelijke gebruik komt niet altijd overeen met wat een analyse voorspelt. Zo ja, dan is het mogelijk om de partities opnieuw te verdelen of om een aantal onderdelen van het systeem opnieuw te ontwerpen om het vereiste saldo te verkrijgen.

In sommige cloudomgevingen worden resources toegewezen op het gebied 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 door één partitie in een bepaalde periode kan worden verwerkt. (Zie Schaalbaarheids- en prestatiedoelen voor Azure Storage voor meerinformatie. Voor een bezette shard zijn mogelijk meer resources nodig dan één partitie kan verwerken. Zo ja, dan moet de shard mogelijk opnieuw worden gepartitioneerd om de belasting te spreiden. 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 verspreiden.

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 de benodigde indexen hebt.

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 presteren.
   • 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 is één partitiestrategie voldoende, maar in sommige gevallen is het efficiënter om beide strategieën te combineren.

4. U kunt query's parallel uitvoeren over 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 essentiële bedrijfsinformatie zijn, zoals transacties, en welke gegevens minder kritieke operationele gegevens zijn, zoals logboekbestanden.

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

• Stel afzonderlijke beheer- en bewakingsprocedures op 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. Zo moet er mogelijk vaker een back-up worden van partities die transactiegegevens bevatten dan partities die logboekregistratie- of traceergegevens bevatten.

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

• 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 kost tijd om wijzigingen met elke replica te synchroniseren. Tijdens deze periode bevatten verschillende partities ook verschillende waarden.

Ontwerpoverwegingen voor toepassingen

Partitioneren 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 na afloop aanpakt, is dit lastiger omdat u al een live-systeem hebt om te onderhouden:

• De 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 kan voor sommige workloads het geval zijn, maar veel commerciële systemen moeten worden uitgebreid naarmate het aantal gebruikers toeneemt.

Bovendien profiteren niet alleen grote gegevensopslag 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 partities. Waar mogelijk, blijven gegevens voor de meest voorkomende databasebewerkingen samen in elke partitie, om bewerkingen met gegevenstoegang over meerdere partities te minimaliseren. Het uitvoeren van query's 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 een nadelige invloed hebben op andere sets query's. Als u query's moet uitvoeren op meerdere partities, minimaliseert u de querytijd door parallelle query's uit te voeren en de resultaten in de toepassing samen te brengen. (Deze aanpak is in sommige gevallen 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 deze gegevens in alle partities repliceren om afzonderlijke opzoekbewerkingen in verschillende partities te verminderen. Deze aanpak kan ook de kans verkleinen dat de referentiegegevens een 'hot' gegevensset worden, met veel verkeer van het hele systeem. Er zijn echter extra kosten verbonden aan het synchroniseren van wijzigingen in de referentiegegevens.

Joins tussen partities minimaliseren. 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 over meerdere partities samen te brengen zijn inefficiënt omdat de toepassing doorgaans opeenvolgende query's moet uitvoeren op basis van een sleutel en vervolgens een vreemde sleutel. Overweeg in plaats daarvan om de relevante gegevens te repliceren of denormaliseren. Als cross-partition joins nodig zijn, kunt u parallelle query's uitvoeren op de partities en de gegevens in de toepassing aan elkaar deelnemen.

Uiteindelijke consistentie is het streven. Evalueer of sterke consistentie daadwerkelijk vereist is. Een veelgebruikte 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 de partitie op natuurlijke wijze opgeven. Horizontale partitionering daarentegen kan het zoeken naar een item lastig maken, 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 om shards periodiek opnieuw te herbalanceren. Met horizontale partitionering kunnen herverdelings-shards helpen de gegevens gelijkmatig te verdelen op grootte en per werkbelasting om hotspots te minimaliseren, queryprestaties te maximaliseren en beperkingen van 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 uitvalt, 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. Om overmatige groei van partities te voorkomen, moet u regelmatig gegevens 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 het uitvoeren van een periodiek proces om problemen met de gegevensintegriteit op te sporen, zoals gegevens in de ene partitie die verwijzen naar ontbrekende informatie in een andere. Het proces kan proberen deze problemen automatisch op te lossen of een rapport genereren voor handmatige beoordeling.

Herverdeling van partities

Naarmate een systeem zich verder ontwikkeld, moet u mogelijk het partitieschema aanpassen. Afzonderlijke partities kunnen bijvoorbeeld een onevenredige hoeveelheid verkeer krijgen en warm worden, wat leidt tot overmatige splitsingen. Of misschien hebt u de hoeveelheid gegevens in sommige partities te laag ingescheed, waardoor sommige partities capaciteitslimieten benaderen.

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

1. Een nieuwe partitioneringsstrategie bepalen.

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

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

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

Offlinemigratie

Offlinemigratie is doorgaans eenvoudiger omdat dit de kans vermindert dat er sprake is van een probleem. Conceptueel gezien werkt offlinemigratie als volgt:

1. Markeer de partitie offline.
2. Splits de gegevens en verplaats ze naar de nieuwe partities.
3. Controleer de gegevens.
4. Breng de nieuwe partities online.
5. Verwijder de oude partitie.

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

Onlinemigratie

Onlinemigratie is complexer om uit te voeren, maar is 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 per shard), moet de code voor gegevenstoegang in de clienttoepassingen mogelijk het lezen en schrijven van gegevens verwerken die op twee locaties worden opgehouden, de oorspronkelijke partitie en de nieuwe partitie.

Verwante patronen

De volgende ontwerppatronen zijn mogelijk relevant voor uw scenario:

• Het sharding-patroon beschrijft enkele algemene strategieën voor sharding van gegevens.

• Het indextabelpatroon laat zien hoe u secundaire indexen maakt op basis van 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 patroon voor de materialized weergave wordt beschreven hoe u vooraf invulde 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.

Volgende stappen

• Meer informatie over partitioneringsstrategieën voor specifieke Azure-services. Zie Strategieën voor gegevenspartities