Richtlijnen voor gegevenspartitionering

Azure Blob Storage

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 en nadelige effecten te minimaliseren.

Notitie

In dit artikel staat de term partitioneren voor het proces van fysiek gegevens verdelen in afzonderlijke gegevensarchieven. Het is niet hetzelfde als het partitioneren van tabellen in SQL Server.

Waarom gegevens partitioneren?

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

  • Prestaties verbeteren. Bewerkingen voor gegevenstoegang op elke partitie vinden plaats over een kleinere hoeveelheid gegevens. Correct uitgevoerd, 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 in verschillende partities scheiden 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 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 één exemplaar mislukt, zijn alleen de gegevens in die partitie niet beschikbaar. Bewerkingen op andere partities kunnen worden voortgezet. Voor beheerde PaaS-gegevensarchieven 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 de ene partitie en productinventarisgegevens in een andere.

Deze strategieën kunnen worden gecombineerd en we raden u aan om ze allemaal in overweging te nemen 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 conflicten worden verminderd en de prestaties worden verbeterd.

Horizontale partitionering (sharding) van gegevens op basis van een partitiesleutel

Afbeelding 1: gegevens horizontaal partitioneren (sharden) 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 workload 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 verwerkingsresources) van het gegevensarchief niet overschrijdt.

Vermijd het maken van 'dynamische' partities die de prestaties en beschikbaarheid kunnen beïnvloeden. Het gebruik van de eerste letter van de naam van een klant veroorzaakt bijvoorbeeld 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 waarmee toekomstige vereisten voor het splitsen van grote shards, het samenvoegen van kleine shards in grotere partities of het wijzigen van het schema worden geminimaliseerd. 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 gegevensconsistentie te voorkomen.

Zie shardingpatroon 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 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 geopend, waaronder productnaam, beschrijving en prijs. Een andere partitie bevat inventarisgegevens: het voorraadaantal en de datum van de laatste bestelling.

Verticale partitionering van gegevens met het gebruikspatroon

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. Voorraadaantal en laatst bestelde datum worden bewaard in een afzonderlijke partitie, 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 meer dynamische gegevens (voorraadniveau en datum van laatste bestelling). Trage verplaatsing van gegevens is een goede kandidaat voor een toepassing om in het cachegeheugen te worden opgeslagen.

  • 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 gebonden context te identificeren voor elk afzonderlijk bedrijfsgebied in een toepassing, is functionele partitionering een manier om isolatie en prestaties van gegevenstoegang te verbeteren. Een andere veelgebruikte toepassing 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.

Functionele partitionering van gegevens naar begrensde context of subdomein

Afbeelding 3: Gegevens functioneel partitioneren op basis van 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 voor het afhandelen van de schaalbaarheidsvereisten, wat betreft gegevensgrootte en doorvoer. Afhankelijk van het gegevensarchief is er mogelijk een limiet voor de hoeveelheid opslagruimte, verwerkingskracht of netwerkbandbreedte per partitie. Als de vereisten deze limieten waarschijnlijk overschrijden, moet u mogelijk uw partitioneringsstrategie verfijnen of gegevens verder splitsen, mogelijk door twee of meer strategieën te combineren.
  4. Controleer 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, is het mogelijk om de partities opnieuw te verdelen of om sommige onderdelen van het systeem opnieuw te ontwerpen om de vereiste balans 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 Schaalbaarheids- en prestatiedoelen voor Azure Storage voor meer informatie.) Voor een bezet shard zijn mogelijk meer resources nodig dan één partitie kan verwerken. Als dat het zo is, 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 spreiden.

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

  4. Overweeg query's parallel uit te voeren tussen 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. Identificeer 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. Van partities met transactiegegevens moet bijvoorbeeld vaker een back-up worden gemaakt dan van 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. Bijvoorbeeld:

  • Als een partitie uitvalt, 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 achteraf gaat aanpakken, is het lastiger omdat u al een livesysteem 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 het systeem te kunnen blijven gebruiken tijdens de migratie.

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

Bovendien profiteren niet alleen grote gegevensarchieven 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:

Bewerkingen voor gegevenstoegang tussen partities minimaliseren. 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 negatieve invloed hebben op andere sets query's. Als u query's moet uitvoeren op meerdere partities, minimaliseer dan 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 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 benadering kan ook de kans verkleinen dat de referentiegegevens een 'dynamische' gegevensset worden, met intensief verkeer van het hele systeem. Er zijn echter extra kosten verbonden aan het synchroniseren van eventuele 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 handhaven van referentiële integriteit tussen partities. Query's waarmee gegevens over meerdere partities worden samengevoegd, 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 op de partities en voegt u de gegevens in de toepassing toe.

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 natuurlijk opgeven. Horizontale partitionering daarentegen kan 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 om shards regelmatig opnieuw te verdelen. Met horizontale partitionering kan het opnieuw verdelen van shards helpen om de gegevens gelijkmatig te verdelen op basis van grootte en workload 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 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 . 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 een periodiek proces uit te voeren om problemen met gegevensintegriteit te vinden, zoals gegevens in de ene partitie die verwijzen naar ontbrekende informatie in een andere partitie. Het proces kan proberen deze problemen automatisch op te lossen of een rapport genereren voor handmatige beoordeling.

Herverdeling van partities

Naarmate een systeem volwassener wordt, moet u mogelijk het partitieschema aanpassen. Afzonderlijke partities kunnen bijvoorbeeld een onevenredige hoeveelheid verkeer krijgen en dynamisch worden, wat leidt tot overmatige conflicten. Of misschien hebt u het volume van gegevens in sommige partities onderschat, waardoor sommige partities de 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. 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 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 hierdoor de kans op conflicten wordt verkleind. Conceptueel werkt offlinemigratie als volgt:

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

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

Onlinemigratie

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 voor item versus shard per shard), moet de code voor gegevenstoegang in de clienttoepassingen mogelijk het lezen en schrijven van gegevens afhandelen die op twee locaties zijn opgeslagen: de oorspronkelijke partitie en de nieuwe partitie.

Volgende stappen

De volgende ontwerppatronen kunnen relevant zijn voor uw scenario:

  • Het shardingspatroon beschrijft enkele algemene strategieën voor het sharden van gegevens.

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

  • Het gerealiseerde weergavepatroon beschrijft 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.