Aanbevelingen voor gegevenspartitionering

Artikel
11/15/2023

Is van toepassing op deze aanbeveling voor de betrouwbaarheidschecklist van Azure Well-Architected Framework:

RE:06	Implementeer een tijdige en betrouwbare schaalstrategie op toepassings-, gegevens- en infrastructuurniveau.

Verwante handleiding:Schalen

In deze handleiding worden de aanbevelingen beschreven voor het ontwerpen van een strategie voor gegevenspartitionering voor de database en gegevensopslagtechnologie die u implementeert. Deze strategie helpt u de betrouwbaarheid van uw gegevensdomein te verbeteren.

Belangrijke ontwerpstrategieën

In veel grootschalige oplossingen worden partities gebruikt om gegevens te verdelen, zodat deze afzonderlijk kunnen worden beheerd en geopend. Het partitioneren van gegevens verbetert de schaalbaarheid, vermindert conflicten en optimaliseert de prestaties. Implementeer gegevenspartitionering om gegevens te delen op basis van gebruikspatroon. U kunt bijvoorbeeld oudere gegevens archiveren in goedkope gegevensopslag. Kies uw partitioneringsstrategie zorgvuldig 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. Dit verschilt van SQL Server tabelpartitionering.

Waarom gegevens partitioneren?

Schaalbaarheid te verbeteren. Wanneer u één databasesysteem omhoog schaalt, bereikt de database uiteindelijk een limiet voor fysieke hardware. Als u gegevens over meerdere partities verdeelt, waarbij elke partitie op een afzonderlijke server wordt gehost, kunt u het systeem bijna voor onbepaalde tijd uitschalen.
Prestaties verbeteren. In elke partitie worden gegevenstoegangsbewerkingen uitgevoerd op een kleiner volume gegevens in vergelijking met gegevens die niet zijn gepartitioneerd. Partitioneer gegevens om uw systeem efficiënter te 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. U kunt gegevens partitioneren om bewerkingen af te stemmen, de administratieve efficiëntie te maximaliseren en de kosten te minimaliseren. U kunt bijvoorbeeld strategieën definiëren voor beheer, bewaking, back-up en herstel en andere beheertaken op basis van het belang van de gegevens in elke partitie.
Het gegevensarchief aanpassen aan het gebruikspatroon. U kunt elke partitie implementeren in een ander type gegevensarchief op basis van de kosten en de ingebouwde functies van het gegevensarchief. U kunt bijvoorbeeld grote binaire gegevens opslaan in blobopslag en gestructureerde gegevens opslaan in een documentdatabase. Zie Inzicht in modellen voor gegevensopslag voor meer informatie.
Beschikbaarheid te verbeteren. Om een Single Point of Failure te voorkomen, kunt u gegevens over meerdere servers scheiden. Als één exemplaar mislukt, zijn alleen de gegevens in die partitie niet beschikbaar. Bewerkingen worden uitgevoerd in andere partities. Deze overweging is minder relevant voor beheerde PaaS-gegevensarchieven (Platform as a Service), omdat deze ingebouwde redundantie hebben.

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 subset van de gegevens, zoals een set klantorders.
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 geaggregeerd op basis van hoe elke begrensde context in het systeem de gegevens gebruikt. Een e-commercesysteem kan bijvoorbeeld factuurgegevens opslaan in de ene partitie en productinventarisatiegegevens in een andere.

Overweeg deze strategieën te combineren 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)

In de volgende afbeelding ziet u een voorbeeld van horizontale partitionering of sharding. In dit voorbeeld worden productinventarisatiegegevens onderverdeeld in shards die zijn gebaseerd op de productcode. Elke shard bevat de gegevens voor een aaneengesloten reeks shard-sleutels (A-G en H-Z), alfabetisch gerangschikt. Wanneer u sharding uitvoert, wordt de belasting verdeeld over meer computers, waardoor conflicten worden verminderd en de prestaties worden verbeterd.

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

De shards hoeven niet even groot te zijn. Het is belangrijker om het aantal aanvragen te verdelen. Sommige shards kunnen groot zijn, maar elk item in de shard heeft een laag aantal toegangsbewerkingen. Andere shards zijn mogelijk kleiner, maar elk item in de shard wordt vaker geopend. Het is ook belangrijk om ervoor te zorgen dat één shard de schaallimieten van het gegevensarchief niet overschrijdt, wat betreft capaciteit en verwerkingsresources.

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, kan dit een onevenwichtige verdeling maken omdat sommige letters vaker voorkomen dan andere. Gebruik in plaats daarvan een hash van de klant-id om gegevens gelijkmatig over partities te verdelen.

Kies een shardingsleutel die de toekomstige noodzaak minimaliseert om grote shards te splitsen, kleine shards te combineren in grotere partities of het schema te wijzigen. Deze bewerkingen zijn tijdrovend en vereisen mogelijk dat u een of meer shards offline moet halen.

Als shards worden gerepliceerd, kunt u sommige replica's online houden terwijl andere worden gesplitst, samengevoegd of opnieuw geconfigureerd. Het systeem kan echter de bewerkingen beperken die tijdens de herconfiguratie kunnen worden uitgevoerd. De gegevens in de replica's kunnen bijvoorbeeld worden gemarkeerd als alleen-lezen om inconistentie van gegevens te voorkomen.

Zie Sharding-patroon voor meer informatie.

Verticale partitionering

Verticale partitionering wordt meestal gebruikt om de I/O- en prestatiekosten te verlagen die gepaard gaan met het ophalen van items die vaak worden gebruikt. In de volgende afbeelding ziet u 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, zoals productnaam, beschrijving en prijs. Een andere partitie bevat inventarisgegevens, waaronder het aantal voorraad en de laatst bestelde datum.

In dit voorbeeld vraagt de toepassing regelmatig de productnaam, beschrijving en prijs op wanneer de productgegevens aan klanten worden weergegeven. Het voorraadaantal en de laatste bestelde datum bevinden zich in een afzonderlijke partitie, omdat deze twee items vaak samen worden gebruikt.

Bekijk de volgende voordelen van verticale partitionering:

U kunt relatief langzaam bewegende gegevens (productnaam, beschrijving en prijs) scheiden van meer dynamische gegevens (voorraadniveau en datum van laatste bestelling). Langzaam bewegende gegevens zijn een goede kandidaat voor een toepassing om in het geheugen op te cachen.
U kunt gevoelige gegevens opslaan 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 kolomgeoriënteerde gegevensarchieven, zoals HBase en Cassandra. Als het onwaarschijnlijk is dat de gegevens in een verzameling kolommen worden gewijzigd, kunt u overwegen om kolomarchieven in SQL Server te gebruiken.

Functionele partitionering

Wanneer een gebonden context kan worden geïdentificeerd voor elk afzonderlijk bedrijfsgebied in een toepassing, kan functionele partitionering de prestaties van isolatie en gegevenstoegang verbeteren. Een ander algemeen gebruik voor functionele partitionering is het scheiden van alleen-lezen-schrijfgegevens van alleen-lezen gegevens. In de volgende afbeelding ziet u een overzicht van functionele partitionering met inventarisgegevens gescheiden van klantgegevens.

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

Partities ontwerpen voor schaalbaarheid

Het is essentieel om rekening te houden met de grootte en workload voor elke partitie. Breng ze in balans zodat gegevens worden gedistribueerd om maximale schaalbaarheid te bereiken. U moet de gegevens echter ook partitioneren zodat deze de schaallimieten van één partitiearchief niet overschrijden.

Volg deze stappen wanneer u partities ontwerpt voor schaalbaarheid:

Analyseer de toepassing om inzicht te krijgen in de patronen voor gegevenstoegang, zoals de grootte van de resultatenset die elke query retourneert, de toegangsfrequentie, de inherente latentie en de vereisten voor rekenverwerking aan de serverzijde. In veel gevallen is voor een paar grote entiteiten de meeste verwerkingsresources nodig.
Gebruik deze analyse om de huidige en toekomstige schaalbaarheidsdoelen te bepalen, zoals de gegevensgrootte en workload. Verdeel vervolgens de gegevens over de partities om te voldoen aan het schaalbaarheidsdoel. Voor horizontale partitionering kiest u de juiste shardsleutel om een gelijkmatige verdeling te garanderen. Zie Sharding-patroon voor meer informatie.
Zorg ervoor dat elke partitie voldoende resources heeft voor het afhandelen van de schaalbaarheidsvereisten met betrekking tot de gegevensgrootte en doorvoer. Afhankelijk van het gegevensarchief kan er voor elke partitie een limiet gelden voor de hoeveelheid opslagruimte, verwerkingskracht of netwerkbandbreedte. Als de vereisten deze limieten waarschijnlijk overschrijden, moet u mogelijk uw partitiestrategie verfijnen of gegevens verder splitsen. Mogelijk moet u twee of meer strategieën combineren.
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. Mogelijk moet u de partities opnieuw verdelen of sommige onderdelen van het systeem opnieuw ontwerpen om het vereiste saldo te verkrijgen.

Sommige cloudomgevingen wijzen resources toe op basis van infrastructuurgrenzen. Zorg ervoor dat de limieten van de geselecteerde grens voldoende ruimte bieden voor verwachte groei in gegevensvolume, gegevensopslag, verwerkingskracht en bandbreedte.

Als u bijvoorbeeld Azure Table Storage gebruikt, is er een limiet voor het aantal aanvragen dat een enkele partitie in een bepaalde periode kan verwerken. Zie Schaalbaarheids- en prestatiedoelen voor standaardopslagaccounts voor meer informatie. Voor een bezet shard zijn mogelijk meer resources nodig dan één partitie kan verwerken. Mogelijk moet u de shard opnieuw partitioneren om de belasting te verdelen. Als de totale grootte of doorvoer van deze tabellen de capaciteit van een opslagaccount overschrijdt, moet u mogelijk meer opslagaccounts maken en de tabellen over deze accounts spreiden.

Partities ontwerpen voor queryprestaties

U kunt de queryprestaties verbeteren door kleine gegevenssets te gebruiken en parallelle query's uit te voeren. 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 juiste databaseontwerp en de juiste configuratie. Zorg ervoor dat u de benodigde indexen implementeert.

Volg deze stappen wanneer u partities ontwerpt voor queryprestaties:

Bekijk de toepassingsvereisten en prestaties.
- Gebruik bedrijfsvereisten om de kritieke query's te bepalen die altijd snel moeten worden uitgevoerd.
- Bewaak het systeem om query's te identificeren die traag worden uitgevoerd.
- Bepaal welke query's het vaakst worden uitgevoerd. Zelfs als een enkele query minimale kosten heeft, kan het cumulatieve resourceverbruik aanzienlijk zijn.
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. Deze specificatie voorkomt dat de query elke partitie scant.
- Denk na over de locatie van een partitie. Probeer gegevens te bewaren in partities die zich geografisch dicht bij de toepassingen en gebruikers bevinden die er toegang toe hebben.
Als een entiteit vereisten voor doorvoer en queryprestaties heeft, gebruikt u functionele partitionering op basis van die entiteit. Als deze toewijzing nog steeds niet aan de vereisten voldoet, kunt u horizontale partitionering toevoegen. Een enkele partitioneringsstrategie is meestal voldoende, maar in sommige gevallen is het efficiënter om beide strategieën te combineren.
Voer query's parallel uit tussen partities om de prestaties te verbeteren.

Partities ontwerpen voor beschikbaarheid

Partitioneer gegevens om de beschikbaarheid van toepassingen te verbeteren. Partitionering zorgt ervoor dat de hele gegevensset geen Single Point of Failure heeft en u kunt afzonderlijke subsets van de gegevensset onafhankelijk beheren.

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

Bepaal de ernst van de gegevens. Identificeer de kritieke bedrijfsgegevens, zoals transacties, en de minder kritieke operationele gegevens, zoals logboekbestanden.

Sla kritieke gegevens op in maximaal beschikbare partities en maak een geschikt back-upplan.
Afzonderlijke beheer- en bewakingsprocedures instellen voor verschillende gegevenssets.
Plaats gegevens met hetzelfde kritieke niveau in dezelfde partitie, zodat er met dezelfde frequentie een back-up van kan worden gemaakt. U moet bijvoorbeeld vaker back-ups maken van partities die transactiegegevens bevatten dan partities die logboek- of traceringsgegevens bevatten.

Afzonderlijke partities beheren. Ontwerp partities ter ondersteuning van onafhankelijk beheer en onderhoud. Deze praktijk 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 te partitioneren per geografisch gebied kunnen geplande onderhoudstaken worden uitgevoerd tijdens daluren voor elke locatie. Zorg ervoor dat partities niet zo groot zijn dat ze voorkomen dat gepland onderhoud tijdens deze periode wordt afgerond.

Kritieke gegevens repliceren tussen partities. Deze strategie verbetert de beschikbaarheid en prestaties, maar kan ook consistentieproblemen veroorzaken. Het duurt even om wijzigingen met elke replica te synchroniseren. Tijdens de synchronisatie bevatten verschillende partities verschillende gegevenswaarden.

Ontwerpoverwegingen voor toepassingen

Partitionering voegt complexiteit toe aan het ontwerp en de ontwikkeling van uw systeem. Partitioneer gegevens als een fundamenteel onderdeel van uw systeemontwerp, zelfs als het systeem in eerste instantie slechts één partitie bevat. Als u partitionering achteraf aan de hand hebt, is het lastig omdat u al een livesysteem hebt om te onderhouden. U kunt het volgende doen:

De logica voor gegevenstoegang moet worden gewijzigd.
Grote hoeveelheden bestaande gegevens moeten worden gemigreerd om deze over partities te verdelen.
Loop tegen uitdagingen aan omdat gebruikers verwachten het systeem te blijven gebruiken tijdens de migratie.

In sommige gevallen is partitioneren niet belangrijk omdat de eerste gegevensset klein is en één server deze eenvoudig kan verwerken. Sommige workloads kunnen zonder partities worden uitgevoerd, maar veel commerciële systemen moeten worden uitgebreid naarmate het aantal gebruikers toeneemt.

Sommige kleine gegevensarchieven profiteren ook van partitionering. Honderden gelijktijdige clients hebben bijvoorbeeld toegang tot een klein gegevensarchief. Als u de gegevens in deze situatie partitionert, kan dit helpen om conflicten te verminderen en de doorvoer te verbeteren.

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

Bewerkingen voor gegevenstoegang tussen partities minimaliseren. Probeer gegevens voor de meest voorkomende databasebewerkingen bij elkaar te houden in een partitie om bewerkingen voor gegevenstoegang tussen partities te minimaliseren. Het kan tijdrovender zijn om query's uit te voeren op meerdere partities in plaats van query's binnen één partitie uit te voeren. Het optimaliseren van partities voor één set query's kan echter 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. In sommige gevallen kunt u deze methode niet gebruiken, bijvoorbeeld als het resultaat van de ene query wordt gebruikt in de volgende query.

Statische referentiegegevens 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 verkleinen dat de referentiegegevens een dynamische gegevensset worden met veel verkeer van het hele systeem. Er zijn 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 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 uitvoert die zijn gebaseerd op 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 een vereiste 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 de updates worden voltooid. De toepassingslogica verwerkt ook de inconsistenties die het gevolg zijn van het uitvoeren van query's op 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 vinden, is dit aanzienlijk van invloed op de prestaties, zelfs wanneer meerdere parallelle query's worden uitgevoerd. Met verticale en functionele partitionering kunnen query's de partitie opgeven. Aan de andere kant kan horizontale partitionering het lastig maken om een item te vinden, omdat elke shard hetzelfde schema heeft. Een typische oplossing is het onderhouden van een kaart die wordt gebruikt om de shardlocatie van items op te zoeken. Implementeer deze kaart in de shardinglogica van de toepassing. Het kan ook worden onderhouden door het gegevensarchief als het gegevensarchief transparante sharding ondersteunt.

Shards periodiek opnieuw verdelen. Met horizontale partitionering kan het opnieuw verdelen van shards helpen om de gegevens gelijkmatig te verdelen op basis van grootte en workload. Shards opnieuw verdelen om hotspots te minimaliseren, queryprestaties te maximaliseren en beperkingen van fysieke opslag te omzeilen. Deze taak is complex en vereist vaak een aangepast hulpprogramma of proces.

Partities repliceren. Repliceer elke partitie om extra bescherming tegen fouten te bieden. Als één replica mislukt, worden query's omgeleid naar een werkende kopie.

Schaalbaarheid uitbreiden naar een ander niveau. 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 partitionering al op databaseniveau is en er fysieke beperkingen zijn, moet u mogelijk partities in meerdere hostingaccounts zoeken of repliceren.

Voorkom dat transacties gegevens in meerdere partities aanspreken. Sommige gegevensarchieven implementeren transactionele consistentie en integriteit voor bewerkingen die gegevens wijzigen, maar alleen wanneer de gegevens zich in één partitie bevinden. Als u transactionele ondersteuning voor meerdere partities nodig hebt, implementeert u deze als onderdeel van uw toepassingslogica, omdat de meeste partitioneringssystemen geen systeemeigen ondersteuning bieden.

Alle gegevensarchieven vereisen enig operationeel beheer en enige controleactiviteit. Deze taken omvatten het laden van gegevens, het maken van back-ups en het herstellen van gegevens, het opnieuw organiseren van gegevens en het controleren of het systeem correct en efficiënt werkt.

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

Implementeer de juiste beheer- en operationele taken wanneer de gegevens worden gepartitioneerd. Deze taken kunnen onder meer back-ups maken en herstellen, gegevens archiveren, het systeem bewaken en andere beheertaken omvatten. Het kan bijvoorbeeld lastig zijn om logische consistentie te behouden tijdens back-up- en herstelbewerkingen.
Laad gegevens in meerdere partities en voeg nieuwe gegevens toe die afkomstig zijn van andere bronnen. Sommige hulpprogramma's en hulpprogramma's bieden mogelijk geen ondersteuning voor shard-gegevensbewerkingen, zoals het laden van gegevens in de juiste partitie.
Gegevens regelmatig archiveren en verwijderen. Om de overmatige groei van partities te voorkomen, moet u gegevens elke maand archiveren en verwijderen. Mogelijk moet u de gegevens transformeren zodat deze overeenkomen met een ander archiefschema.
Problemen met gegevensintegriteit zoeken. Overweeg een periodiek proces uit te voeren om problemen met gegevensintegriteit op te sporen, zoals gegevens in de ene partitie die verwijzen naar ontbrekende informatie in een andere partitie. Het proces kan automatisch proberen deze problemen op te lossen of een rapport genereren voor handmatige beoordeling.

Partities opnieuw verdelen

Naarmate een systeem volwassener wordt, moet u mogelijk het partitieschema aanpassen. Afzonderlijke partities kunnen bijvoorbeeld een onevenredig grote hoeveelheid verkeer krijgen en hot worden, wat leidt tot overmatige conflicten. Of misschien hebt u de hoeveelheid gegevens in sommige partities onderschat, waardoor de partities capaciteitslimieten naderen.

Sommige gegevensarchieven, zoals Azure Cosmos DB, kunnen partities automatisch opnieuw verdelen. In andere gevallen kunt u partities opnieuw verdelen in twee fasen:

Een nieuwe partitioneringsstrategie bepalen.
- Welke partities moeten worden gesplitst of gecombineerd?
- Wat is de nieuwe partitiesleutel?
Gegevens migreren van het oude partitieschema naar de nieuwe set partities.

Mogelijk moet u partities niet beschikbaar maken tijdens het verplaatsen van gegevens. Dit wordt offlinemigratie genoemd. Afhankelijk van het gegevensarchief kunt u gegevens migreren tussen partities terwijl ze in gebruik zijn. Deze techniek wordt onlinemigratie genoemd.

Offlinemigratie

Offlinemigratie vermindert de kans op conflicten. Offlinemigratie uitvoeren:

Markeer de partitie als offline. U kunt een partitie markeren als alleen-lezen, zodat toepassingen de gegevens nog steeds kunnen lezen terwijl u deze verplaatst.
Splits samenvoegen en verplaats de gegevens naar de nieuwe partities.
Controleer de gegevens.
Breng de nieuwe partities online.
Verwijder de oude partitie.

Onlinemigratie

Onlinemigratie is complexer, maar minder verstorend in vergelijking met offlinemigratie. Het proces is vergelijkbaar met offlinemigratie, maar u markeert de oorspronkelijke partitie niet als offline. Afhankelijk van de granulariteit van het migratieproces, bijvoorbeeld item voor item versus shard voor shard, moet de code voor gegevenstoegang in de clienttoepassingen mogelijk gegevens lezen en schrijven die zich op twee locaties bevinden: de oorspronkelijke partitie en de nieuwe partitie.

Azure-facilitering

In de volgende secties worden aanbevelingen beschreven voor het partitioneren van gegevens die zijn opgeslagen in Azure-services.

Partitie in Azure SQL Database

Een enkele SQL-database heeft een limiet voor het volume van gegevens die deze kan bevatten. Doorvoer wordt beperkt door factoren van de architectuur en het aantal gelijktijdige verbindingen dat wordt ondersteund.

Elastische pools ondersteunen horizontaal schalen voor een SQL-database. Gebruik elastische pools om uw gegevens te partitioneren in shards die zijn verdeeld over meerdere SQL-databases. U kunt ook shards toevoegen of verwijderen naarmate de hoeveelheid gegevens groeit en afneemt. Elastische pools kunnen ook conflicten verminderen door de belasting over databases te verdelen.

Elke shard wordt geïmplementeerd als een SQL-database. Een shard kan meer dan één gegevensset bevatten. Elke gegevensset wordt een shardlet genoemd. Elke database bevat metagegevens die de shardlets beschrijven die de database bevat. Een shardlet kan één gegevensitem of een groep items zijn die dezelfde shardletsleutel delen. In een toepassing met meerdere tenants kan de shardletsleutel bijvoorbeeld de tenant-id zijn en kunnen alle gegevens voor een tenant zich in dezelfde shardlet bevinden.

Toepassingen zijn verantwoordelijk voor het koppelen van een gegevensset aan een shardlet-sleutel. Een afzonderlijke SQL-database fungeert als een beheerder voor globale shard-toewijzing. Deze database bevat een lijst met alle shards en shardlets in het systeem. De toepassing maakt verbinding met de shard-toewijzingsbeheerdatabase om een kopie van de shard-toewijzing te verkrijgen. De shardtoewijzing wordt lokaal in de cache opgeslagen en de kaart wordt gebruikt om gegevensaanvragen naar de juiste shard te routeren. Deze functionaliteit is verborgen achter een reeks API's die zijn opgenomen in de clientbibliotheek van de functie Elastic Database van SQL Database, die beschikbaar is voor Java en .NET.

Zie Uitschalen met SQL Database voor meer informatie over elastische pools.

Als u de latentie wilt verminderen en de beschikbaarheid wilt verbeteren, kunt u de global shard map manager-database repliceren. Met de premium-prijscategorieën kunt u actieve geo-replicatie configureren om continu gegevens te kopiëren naar databases in verschillende regio's.

U kunt ook SQL Data Sync voor SQL Database of Azure Data Factory gebruiken om de shardtoewijzingsbeheerdatabase te repliceren tussen regio's. Deze vorm van replicatie wordt periodiek uitgevoerd en is beter geschikt als de shardtoewijzing niet vaak wordt gewijzigd en de Premium-laag niet nodig is.

Elastic Database biedt twee schema's voor de toewijzing van gegevens aan shardlets en om ze op te slaan in shards:

Een lijst-shardtoewijzing koppelt één sleutel aan een shardlet. In een multitenant-systeem kunnen bijvoorbeeld de gegevens voor elke tenant aan een unieke sleutel worden gekoppeld en in een eigen shardlet worden opgeslagen. Om isolatie te garanderen, kan elke shardlet binnen een eigen shard worden gehouden.

Download een Visio-bestand van dit diagram.
Een bereikshardtoewijzing koppelt een set aaneengesloten sleutelwaarden aan een shardlet. U kunt bijvoorbeeld de gegevens voor een set tenants groeperen, elk met een eigen sleutel, binnen dezelfde shardlet. Dit schema is goedkoper dan een lijstshardtoewijzing omdat tenants gegevensopslag delen, maar minder isolatie biedt.

Een Visio-bestand van dit diagram downloaden

Eén shard kan de gegevens voor verschillende shardlets bevatten. U kunt bijvoorbeeld lijst-shardlets gebruiken voor het opslaan van gegevens voor andere niet-aaneengesloten tenants in dezelfde shard. U kunt ook bereikshardlets en lijst-shardlets in dezelfde shard combineren, maar ze worden vervolgens via verschillende kaarten aangepakt. In het volgende diagram ziet u deze benadering:

Download een Visio-bestand van dit diagram.

Met elastische pools kunt u shards toevoegen en verwijderen naarmate de hoeveelheid gegevens groeit en kleiner wordt. Clienttoepassingen kunnen shards dynamisch en transparant bijwerken van het shard-toewijzingsbeheer maken en verwijderen. Het verwijderen van een shard is echter een destructieve bewerking waarvoor ook de gegevens in die shard moeten worden verwijderd.

Als een toepassing een shard in twee afzonderlijke shards moet splitsen of shards moet combineren, gebruikt u het hulpprogramma voor splitsen en samenvoegen. Dit hulpprogramma wordt uitgevoerd als een Azure-webservice en migreert gegevens veilig tussen shards.

Het partitioneringsschema kan de prestaties van uw systeem aanzienlijk beïnvloeden. Het kan ook van invloed zijn op de snelheid waarmee shards moeten worden toegevoegd of verwijderd, of dat gegevens opnieuw moeten worden gepartitioneerd tussen shards. Overweeg het volgende:

Groepeer gegevens die samen in dezelfde shard worden gebruikt en vermijd bewerkingen die toegang hebben tot gegevens van meerdere shards. Een shard is op zichzelf een SQL-database en cross-database joins moeten worden uitgevoerd aan de clientzijde wanneer bewerkingen toegang hebben tot meerdere shards.

Hoewel SQL Database geen ondersteuning biedt voor joins tussen databases, kunt u hulpprogramma's voor elastische databases gebruiken om multi-shard-query's uit te voeren. Een multi-shardquery verzendt afzonderlijke query's naar elke database en voegt de resultaten samen.
Ontwerp een systeem dat geen afhankelijkheden tussen shards heeft. Beperkingen voor referentiële integriteit, triggers en opgeslagen procedures in de ene database kunnen niet verwijzen naar objecten in een andere database.
Overweeg om gegevens te repliceren tussen shards als u referentiegegevens hebt die vaak worden gebruikt door query's. Op deze manier hoeft u geen gegevens samen te voegen tussen databases. In het ideale geval moeten dergelijke gegevens statisch of traag zijn om de replicatie-inspanning te minimaliseren en de kans te verkleinen dat ze verlopen.
Gebruik hetzelfde schema voor shardlets die tot dezelfde shardtoewijzing behoren. Deze richtlijnen worden niet afgedwongen door SQL Database, maar gegevensbeheer en query's zijn complex als elke shardlet een ander schema heeft. Maak in plaats daarvan afzonderlijke shard-toewijzingen voor elk schema. U kunt gegevens die deel uitmaken van verschillende shardlets in dezelfde shard opslaan.
Sla gegevens op in dezelfde shard of implementeer uiteindelijke consistentie als uw bedrijfslogica transacties moet uitvoeren. Transactionele bewerkingen worden alleen ondersteund voor gegevens in een shard en niet voor shards. Transacties kunnen shardlets omvatten als ze deel uitmaken van dezelfde shard.
Plaats shards dicht bij de gebruikers die toegang hebben tot de gegevens in die shards. Deze strategie helpt met het verminderen van de latentie.
Vermijd een combinatie van zeer actieve en relatief inactieve shards. Probeer de belasting gelijkmatig te verdelen over de shards. Mogelijk moet u de shardingsleutels hashen. Als u shards geolocatiet, moet u ervoor zorgen dat de gehashte sleutels worden toegewezen aan shardlets die zijn opgeslagen in shards die dicht bij de gebruikers zijn opgeslagen die toegang hebben tot die gegevens.

Partitie in Azure Blob Storage

Met Blob Storage kunt u grote binaire objecten opslaan. Gebruik blok-blobs in scenario's waarin u snel grote hoeveelheden gegevens moet uploaden of downloaden. Gebruik pagina-blobs voor toepassingen waarvoor willekeurige, in plaats van seriële toegang tot delen van de gegevens is vereist.

Elke blok-blob of pagina-blob wordt opgeslagen in een container in een Azure-opslagaccount. Gebruik containers om gerelateerde blobs te groepeer die dezelfde beveiligingsvereisten hebben. Deze groepering is logisch in plaats van fysiek. Binnen een container heeft elke blob een unieke naam.

De partitiesleutel voor een blob is de accountnaam, de containernaam en de blobnaam. De partitiesleutel wordt gebruikt om gegevens te partitioneren in bereiken. Deze bereiken worden verdeeld over het hele systeem. Blobs kunnen worden gedistribueerd over veel servers om de toegang tot deze servers uit te schalen. Eén blob kan slechts door één server worden bediend.

Als uw naamgevingsschema tijdstempels of numerieke id's gebruikt, kan dit leiden tot overmatig verkeer naar één partitie. Hiermee voorkomt u dat de taakverdeling van het systeem effectief wordt uitgevoerd. Als u bijvoorbeeld dagelijkse bewerkingen hebt die gebruikmaken van een blobobject met een tijdstempel, zoals jjjj-mm-dd, gaat al het verkeer voor die bewerking naar één partitieserver. In plaats daarvan kunt u de naam vooraf laten gaan door een hash van drie cijfers. Zie Naamconventie voor partities voor meer informatie.

De acties van het schrijven van één blok of pagina zijn atomisch, maar bewerkingen die blokken, pagina's of blobs omvatten, zijn dat niet. Als u consistentie wilt garanderen wanneer schrijfbewerkingen worden uitgevoerd in blokken, pagina's en blobs, neemt u een schrijfvergrendeling met behulp van een blob-lease.

Overwegingen

Gegevenspartitionering brengt enkele uitdagingen en complexiteit met zich mee waarmee u rekening moet houden.

Gegevenssynchronisatie tussen de partities kan een uitdaging worden. Zorg ervoor dat updates of wijzigingen aan de ene partitie tijdig en consistent worden doorgegeven aan de andere partities.
Failover- en herstelprocessen na noodgevallen worden complex wanneer u de back-up en herstel van meerdere partities moet coördineren. Problemen met de gegevensintegriteit kunnen zich voordoen als sommige partities of de bijbehorende back-ups beschadigd zijn of niet beschikbaar zijn.
Gegevenspartitionering kan de prestaties en betrouwbaarheid beïnvloeden als u query's moet uitvoeren op meerdere partities en wanneer u de partities opnieuw in balans brengt als de gegevens ongelijkmatig groeien.

Controlelijst voor betrouwbaarheid

Raadpleeg de volledige set aanbevelingen.

Controlelijst voor betrouwbaarheid

Aanbevelingen voor gegevenspartitionering