Aanbevelingen voor gegevenspartitionering

Artikel
11/15/2023

Is van toepassing op deze aanbeveling voor de controlelijst voor betrouwbaarheid 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. Met deze strategie kunt u de betrouwbaarheid van uw gegevensomgeving verbeteren.

Belangrijke ontwerpstrategieën

In veel grootschalige oplossingen worden partities gebruikt om gegevens te verdelen, zodat ze 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 door 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. Het verschilt van sql Server-tabelpartitionering.

U kunt gegevens partitioneren naar:

Schaalbaarheid te verbeteren. Wanneer u één databasesysteem omhoog schaalt, bereikt de database uiteindelijk een fysieke hardwarelimiet. 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 te verbeteren. In elke partitie worden gegevenstoegangsbewerkingen uitgevoerd via een kleiner aantal 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 scheiden in verschillende partities 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 op een ander type gegevensarchief op basis van de kosten en de ingebouwde functies die het gegevensarchief biedt. U kunt bijvoorbeeld grote binaire gegevens opslaan in blobopslag en gestructureerde gegevens opslaan in een documentdatabase. Zie Modellen voor gegevensopslag begrijpen voor meer informatie.
Beschikbaarheid te verbeteren. Als u een single point of failure wilt voorkomen, kunt u gegevens op meerdere servers scheiden. Als één exemplaar mislukt, zijn alleen de gegevens in die partitie niet beschikbaar. Bewerkingen worden voortgezet in andere partities. Deze overweging is minder relevant voor paaS-gegevensarchieven (Managed Platform as a Service), omdat ze ingebouwde redundantie hebben.

De juiste partitioneringsstrategie selecteren

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 samengevoegd op basis van de wijze waarop elke gebonden context in het systeem de gegevens gebruikt. Een e-commercesysteem kan bijvoorbeeld factuurgegevens opslaan in één partitie en productinventarisgegevens in een andere.

Overweeg deze strategieën te combineren 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 de volgende afbeelding ziet u een voorbeeld van horizontale partitionering of sharding. In dit voorbeeld worden productinventarisgegevens 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 verspreid over meer computers, waardoor conflicten worden verminderd en de prestaties worden verbeterd.

De belangrijkste factor is de sharding-sleutel die u kiest. 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 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, wat betreft 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, kan deze een niet-verdeelde 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 waarmee de toekomstige noodzaak om grote shards te splitsen, kleine shards in grotere partities te combineren of het schema te wijzigen. Deze bewerkingen zijn tijdrovend en vereisen mogelijk dat u een of meer shards offline neemt.

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

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 veelgebruikte items. 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, waaronder productnaam, beschrijving en prijs. Een andere partitie bevat inventarisgegevens, inclusief het aantal aandelen en de laatste bestelde datum.

In dit voorbeeld voert de toepassing regelmatig een query uit op de productnaam, beschrijving en prijs wanneer de productgegevens worden weergegeven aan klanten. Het aantal aandelen 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 dynamischere gegevens (voorraadniveau en laatste bestelde datum). Gegevens die langzaam worden verplaatst, 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 beveiligingsbesturingselementen.
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 de gegevens in een verzameling kolommen waarschijnlijk niet veranderen, 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 isolatie en prestaties van gegevenstoegang verbeteren. Een ander veelvoorkomend gebruik voor functionele partitionering is het scheiden van alleen-lezen gegevens van alleen-lezengegevens. 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. Balancer ze zodat gegevens worden gedistribueerd om maximale schaalbaarheid te bereiken. U moet echter ook de gegevens 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 gegevenstoegangspatronen, zoals de grootte van de resultatenset die elke query retourneert, frequentie van toegang, inherente latentie en verwerkingsvereisten aan de serverzijde. In veel gevallen vragen enkele grote entiteiten de meeste verwerkingsbronnen.
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. Kies voor horizontale partitionering de juiste shardsleutel om gelijkmatige distributie te garanderen. Zie Sharding-patroon voor meer informatie.
Zorg ervoor dat elke partitie voldoende resources heeft voor het afhandelen van de schaalbaarheidsvereisten in termen van de gegevensgrootte en doorvoer. Afhankelijk van het gegevensarchief is er mogelijk een limiet voor elke partitie voor de hoeveelheid opslagruimte, verwerkingskracht of netwerkbandbreedte. Als de vereisten deze limieten waarschijnlijk overschrijden, moet u mogelijk uw partitioneringsstrategie verfijnen of gegevens verder splitsen. Mogelijk moet u twee of meer strategieën combineren.
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. Mogelijk moet u de partities opnieuw verdelen of een deel van het systeem opnieuw ontwerpen om het vereiste saldo te krijgen.

Sommige cloudomgevingen wijzen resources toe op basis van infrastructuurgrenzen. Zorg ervoor dat de limieten van uw 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. Een bezet shard vereist mogelijk meer resources 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 verdelen.

Partities ontwerpen voor queryprestaties

U kunt de queryprestaties verbeteren met behulp van kleine gegevenssets en parallelle query's uitvoeren. Elke partitie moet een klein deel van de hele gegevensset bevatten. Deze vermindering van het volume kan de prestaties van query's verbeteren. Partitionering 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 langzaam worden uitgevoerd.
- Bepaal de query's die het vaakst worden uitgevoerd. Zelfs als één query een minimale kosten heeft, kan cumulatief 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 die is gebaseerd op die entiteit. Als deze toewijzing nog steeds niet aan de vereisten voldoet, kunt u horizontale partitionering toevoegen. Een strategie voor één partitionering is meestal voldoende, maar in sommige gevallen is het efficiënter om beide strategieën te combineren.
Voer query's parallel uit op meerdere 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 afzonderlijke subsets van de gegevensset onafhankelijk kunt beheren.

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

Bepaal de kritiek 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.
Stel afzonderlijke beheer- en bewakingsprocedures in voor verschillende gegevenssets.
Plaats gegevens met hetzelfde kritieke niveau in dezelfde partitie, zodat er een back-up van kan worden gemaakt met dezelfde frequentie. Mogelijk moet u bijvoorbeeld een back-up maken van partities die transactiegegevens vaker 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 mislukt, 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 op daluren plaatsvinden voor elke locatie. Zorg ervoor dat partities niet zo groot zijn dat gepland onderhoud tijdens deze periode niet kan worden 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.

Toepassingscode optimaliseren voor het gebruik van partities

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 als een achteraf adresseert, is het lastig omdat u al een live systeem hebt om te onderhouden. U kunt het volgende doen:

U moet logica voor gegevenstoegang wijzigen.
U moet grote hoeveelheden bestaande gegevens migreren om deze over partities te verdelen.
Er treden uitdagingen op omdat gebruikers verwachten dat ze het systeem blijven gebruiken tijdens de migratie.

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

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

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

Minimaliseer bewerkingen voor gegevenstoegang tussen meerdere partities. Probeer gegevens bij elkaar te houden voor de meest voorkomende databasebewerkingen in een partitie om gegevenstoegangsbewerkingen tussen partities te minimaliseren. Het kan tijdrovender zijn om query's uit te voeren op meerdere partities in plaats van query's uit te voeren binnen één partitie. Het optimaliseren van partities voor één set query's kan echter 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. 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 verminderen dat de referentiegegevens een dynamische gegevensset worden met veel verkeer van over 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 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 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 over de partities en voegt u de gegevens in de toepassing toe.

Uiteindelijke consistentie is het streven. Evalueer of sterke consistentie een vereiste 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 de updates zijn voltooid. De toepassingslogica verwerkt ook de inconsistenties die ontstaan door 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 vinden, is dit 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 vinden van een item moeilijk maken 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 kunt u shards gelijkmatig verdelen op grootte en workload. Shards opnieuw verdelen om hotspots te minimaliseren, queryprestaties te maximaliseren en fysieke opslagbeperkingen te omzeilen. Deze taak is complex en vereist vaak een aangepast hulpprogramma of proces.

Partities repliceren. Repliceer elke partitie om extra beveiliging te bieden tegen fouten. 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 zich al op databaseniveau bevindt en er fysieke beperkingen zijn, moet u mogelijk partities vinden of repliceren in meerdere hostingaccounts.

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 garanderen dat het systeem correct en efficiënt presteert.

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 ondersteunen mogelijk geen shard-gegevensbewerkingen, zoals het laden van gegevens in de juiste partitie.
Gegevens regelmatig archiveren en verwijderen. Om te voorkomen dat partities te groot worden, kunt u gegevens elke maand archiveren en verwijderen. Mogelijk moet u de gegevens transformeren zodat deze overeenkomen met een ander archiefschema.
Problemen met gegevensintegriteit vinden. 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 automatisch proberen om deze problemen op te lossen of een rapport genereren voor handmatige controle.

Partities opnieuw verdelen

Als een systeem volwassen wordt, moet u mogelijk het partitioneringsschema aanpassen. Afzonderlijke partities kunnen bijvoorbeeld een onevenredig volume aan verkeer ontvangen en heet worden, wat leidt tot overmatige conflicten. Of u hebt het volume van 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 in twee fasen opnieuw verdelen:

Bepaal een nieuwe partitioneringsstrategie.
- Welke partities moeten worden gesplitst of gecombineerd?
- Wat is de nieuwe partitiesleutel?
Gegevens migreren van het oude partitioneringsschema 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.
Split-merge en verplaats de gegevens naar de nieuwe partities.
Verify the data.
Breng de nieuwe partities online.
Verwijder de oude partitie.

Online migratie

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 per item versus shard by 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 wanneer het gegevensvolume toeneemt en afneemt. Elastische pools kunnen ook helpen conflicten te 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 heeft metagegevens die de shardlets beschrijven die deze bevat. Een shardlet kan één gegevensitem of een groep items zijn die dezelfde shardletsleutel delen. In een multitenant-toepassing 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. Hiermee wordt de shard-toewijzing lokaal in de cache opgeslagen en wordt de kaart 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 globale database van shard-toewijzingsbeheer repliceren. Met de premium-prijscategorieën kunt u actieve geo-replicatie configureren om continu gegevens naar databases in verschillende regio's te kopiëren.

U kunt ook SQL Data Sync gebruiken voor SQL Database of Azure Data Factory om de shard-toewijzingsbeheerdatabase te repliceren in verschillende regio's. Deze vorm van replicatie wordt periodiek uitgevoerd en is geschikter als de shard-toewijzing niet regelmatig 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-shard-toewijzing 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 bewaard.

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

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 lijstshardlets in dezelfde shardlets combineren, maar vervolgens worden ze geadresseerd via verschillende kaarten. 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 het gegevensvolume toeneemt en verkleint. Clienttoepassingen kunnen shards dynamisch en transparant maken en verwijderen en de shard-toewijzingsbeheer bijwerken. 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 moet splitsen in twee afzonderlijke shards of shards moet combineren, gebruikt u het hulpprogramma 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 worden gebruikt in dezelfde shard en vermijd bewerkingen die toegang hebben tot gegevens uit meerdere shards. Een shard is een EIGEN SQL-database en joins tussen databases moeten aan de clientzijde worden uitgevoerd wanneer bewerkingen toegang hebben tot meerdere shards.

Hoewel SQL Database geen ondersteuning biedt voor joins tussen databases, kunt u elastische databasehulpprogramma's gebruiken om multi-shardquery'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 over shards te repliceren als u referentiegegevens hebt die vaak worden gebruikt door query's. Met deze aanpak hoeft u geen gegevens in meerdere databases samen te voegen. In het ideale geval moeten dergelijke gegevens statisch of langzaam worden verplaatst om de replicatie-inspanning te minimaliseren en de kans op verlopen gegevens te verminderen.
Gebruik hetzelfde schema voor shardlets die deel uitmaken van dezelfde shard-toewijzing. 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 opslaan die deel uitmaken van verschillende shardlets in dezelfde shard.
Sla gegevens op in dezelfde shard of implementeer uiteindelijke consistentie als uw bedrijfslogica transacties moet uitvoeren. Transactionele bewerkingen worden alleen ondersteund voor gegevens die zich in een shard bevinden 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 hash-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 waarvoor 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 bewaard in een container in een Azure-opslagaccount. Gebruik containers om gerelateerde blobs te groeperen 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 in bereiken te partitioneren. Deze bereiken zijn verdeeld over het systeem. Blobs kunnen op veel servers worden gedistribueerd om de toegang tot deze blobs uit te schalen. Eén blob kan slechts worden bediend door één server.

Als uw naamgevingsschema tijdstempels of numerieke id's gebruikt, kan dit leiden tot overmatig verkeer naar één partitie. Het voorkomt dat het systeem taakverdeling effectief kan verdelen. 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. Geef in plaats daarvan het voorvoegsel van de naam met een hash van drie cijfers. Zie Naamconventie voor partities voor meer informatie.

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

Overwegingen

Gegevenspartitionering introduceert enkele uitdagingen en complexiteiten die u moet overwegen.

Gegevenssynchronisatie tussen de partities kan een uitdaging worden. Zorg ervoor dat updates of wijzigingen in één partitie tijdig en consistent worden doorgegeven aan de andere partities.
Failover- en herstelprocessen worden complex wanneer u de back-up en herstel van meerdere partities moet coördineren. Problemen met gegevensintegriteit kunnen optreden als sommige partities of hun back-ups beschadigd of niet beschikbaar zijn.
Gegevenspartitionering kan van invloed zijn op de prestaties en betrouwbaarheid 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

Delen via

Aanbevelingen voor gegevenspartitionering

Belangrijke ontwerpstrategieën