Strategieën voor gegevenspartitionering

In dit artikel worden enkele strategieën beschreven voor het partitioneren van gegevens in verschillende Azure-gegevensarchieven. Zie Gegevenspartitionering voor algemene richtlijnen over het partitioneren van gegevens en aanbevolen procedures.

Partitioneren van 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. Met elastische pools kunt u uw gegevens partitioneren in shards die zijn verspreid over meerdere SQL-databases. U kunt ook shards toevoegen of verwijderen wanneer de hoeveelheid gegevens die u moet verwerken toeneemt of 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 (een shardlet genoemd). Elke database houdt metagegevens bij, die de shardlets beschrijven die deze bevat. Een shardlet kan één gegevensitem zijn of een groep items die dezelfde shardlet-sleutel delen. In een multitenant-toepassing kan de shardlet-sleutel bijvoorbeeld de tenant-id zijn en kunnen alle gegevens voor een tenant in dezelfde shardlet worden bewaard.

Clienttoepassingen zijn verantwoordelijk voor het koppelen van een gegevensset aan een shardlet-sleutel. Een afzonderlijke SQL Database fungeert als een globale shard-toewijzingsbeheerder. 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 toewijzing gebruikt om gegevensaanvragen naar de juiste shard te routeren. Deze functionaliteit is verborgen achter een reeks API's die zijn opgenomen in de elastic database-clientbibliotheek, die beschikbaar is voor Java en .NET.

Zie Uitschalen met Azure 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 Azure SQL Data Sync of Azure Data Factory gebruiken om de shard-toewijzingsbeheerdatabase in verschillende regio's te repliceren. Deze vorm van replicatie wordt periodiek uitgevoerd en is geschikter als de shard-toewijzing onregelmatig verandert en geen Premium-laag vereist.

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 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 de eerste, omdat tenants gegevensopslag delen, maar minder isolatie hebben.

  

  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 bereik-shardlets en lijst-shardlets in dezelfde shard combineren, hoewel ze worden aangepakt via verschillende kaarten. In het volgende diagram ziet u deze benadering:

Download een Visio-bestand van dit diagram.

Elastische pools maken het mogelijk om shards toe te voegen en te verwijderen naarmate het volume aan gegevens afneemt en groeit. Clienttoepassingen kunnen shards dynamisch maken en verwijderen en transparant het 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 SQL-database op eigen recht en joins tussen databases moeten aan de clientzijde worden uitgevoerd.

  Hoewel SQL Database geen ondersteuning biedt voor joins tussen databases, kunt u de elastic database-hulpprogramma's gebruiken om query's met meerdere shards uit te voeren. Een multi-shardquery verzendt afzonderlijke query's naar elke database en voegt de resultaten samen.

• Ontwerp geen systeem met afhankelijkheden tussen shards. Beperkingen voor referentiële integriteit, triggers en opgeslagen procedures in de ene database kunnen niet verwijzen naar objecten in een andere database.

• Als u referentiegegevens hebt die vaak door query's worden gebruikt, kunt u overwegen deze gegevens over shards te repliceren. Met deze methode kunt u de noodzaak om gegevens aan meerdere databases toe te voegen, verwijderen. 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.

• Shardlets die deel uitmaken van dezelfde shard-toewijzing moeten hetzelfde schema hebben. Deze regel wordt niet afgedwongen door SQL Database, maar gegevensbeheer en query's worden erg complex als elke shardlet een ander schema heeft. Maak in plaats daarvan afzonderlijke shard-toewijzingen voor elk schema. Houd er rekening mee dat gegevens die tot verschillende shardlets behoren, in dezelfde shard kunnen worden opgeslagen.

• Transactionele bewerkingen worden alleen ondersteund voor gegevens binnen een shard en niet voor shards. Transacties kunnen shardlets omvatten, zolang ze deel van de dezelfde shard uitmaken. Dus als uw bedrijfslogica transacties moet uitvoeren, slaat u de gegevens op in dezelfde shard of implementeert u uiteindelijke consistentie.

• 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. Hiervoor moeten de shardingsleutels mogelijk worden gehasht. Als u geolocatie van shards gebruikt, zorg dan ervoor dat de hash-sleutels worden toegewezen aan shardlets die zijn ondergebracht in shards dichtbij de gebruikers die toegang tot de gegevens hebben.

Azure Table Storage partitioneren

Azure Table Storage is een sleutel-waardearchief dat is ontworpen rond partitionering. Alle entiteiten worden opgeslagen in een partitie en partities worden intern beheerd door Azure Table Storage. Elke entiteit die in een tabel is opgeslagen, moet een tweeledige sleutel opgeven die het volgende omvat:

• De partitiesleutel. Dit is een tekenreekswaarde waarmee de partitie wordt bepaald waar Azure Table Storage de entiteit plaatst. Alle entiteiten met dezelfde partitiesleutel worden opgeslagen in dezelfde partitie.

• De rijsleutel. Dit is een tekenreekswaarde die de entiteit binnen de partitie identificeert. Alle entiteiten in een partitie worden lexicaal in oplopende volgorde met deze sleutel gesorteerd. De combinatie van partitiesleutel/rijsleutel moet uniek zijn voor elke entiteit en kan niet langer zijn dan 1 KB.

Als een entiteit wordt toegevoegd aan een tabel met een eerder ongebruikte partitiesleutel, maakt Azure Table Storage een nieuwe partitie voor deze entiteit. Andere entiteiten met dezelfde partitiesleutel worden opgeslagen in dezelfde partitie.

Dit mechanisme implementeert effectief een automatische strategie voor uitschalen. Elke partitie wordt op dezelfde server opgeslagen in een Azure-datacenter om ervoor te zorgen dat query's die gegevens ophalen uit één partitie snel worden uitgevoerd.

Microsoft heeft schaalbaarheidsdoelen gepubliceerd voor Azure Storage. Als uw systeem deze limieten waarschijnlijk overschrijdt, kunt u overwegen om entiteiten in meerdere tabellen te splitsen. Gebruik verticale partitionering om de velden te verdelen in de groepen die waarschijnlijk samen worden geopend.

In het volgende diagram ziet u de logische structuur van een voorbeeldopslagaccount. Het opslagaccount bevat drie tabellen: Klantgegevens, Productinformatie en Bestelgegevens.

Elke tabel heeft meerdere partities.

• In de tabel Klantgegevens worden de gegevens gepartitioneerd op basis van de plaats waar de klant zich bevindt. De rijsleutel bevat de klant-id.
• In de tabel Productgegevens worden producten gepartitioneerd op productcategorie en bevat de rijcode het productnummer.
• In de tabel Ordergegevens worden de orders gepartitioneerd op orderdatum en geeft de rijsleutel de tijd aan waarop de order is ontvangen. Alle gegevens worden geordend op basis van de rijsleutel in elke partitie.

Houd rekening met de volgende punten wanneer u uw entiteiten ontwerpt voor Azure Table Storage:

• Selecteer een partitiesleutel en rijsleutel door hoe de gegevens worden geopend. Kies een combinatie van partitiesleutels en recordsleutels die ondersteuning biedt voor het merendeel van uw query's. De meest efficiënt query's halen gegevens op door de partitiesleutel en de recordsleutel op te geven. Query's die een partitiesleutel en een bereik van de recordsleutels opgeven, kunnen worden uitgevoerd door één partitie te scannen. Dit is relatief snel omdat de gegevens worden bewaard in de belangrijkste recordsleutelvolgorde. Als query's niet opgeven welke partitie moet worden gescand, moet elke partitie worden gescand.

• Als een entiteit een natuurlijke sleutel heeft, gebruik deze dan als de partitiesleutel en geef een lege tekenreeks op als de recordsleutel. Als een entiteit een samengestelde sleutel heeft die bestaat uit twee eigenschappen, selecteert u de langzaamst veranderende eigenschap als de partitiesleutel en de andere als rijsleutel. Als een entiteit meer dan twee sleuteleigenschappen heeft, voeg dan de eigenschappen samen om de partitie- en recordsleutels op te geven.

• Als u regelmatig query's uitvoert waarmee gegevens worden opgezoekd met behulp van andere velden dan de partitie- en rijsleutels, kunt u het patroon Indextabel implementeren of overwegen een ander gegevensarchief te gebruiken dat indexering ondersteunt, zoals Azure Cosmos DB.

• Als u partitiesleutels genereert met behulp van een monotone reeks (zoals '0001', '0002', '0003') en elke partitie slechts een beperkte hoeveelheid gegevens bevat, kan Azure Table Storage deze partities fysiek groeperen op dezelfde server. In Azure Storage wordt ervan uitgegaan dat de toepassing waarschijnlijk query's uitvoert voor een aaneengesloten bereik van partities (bereikquery's) en is geoptimaliseerd voor dit geval. Deze aanpak kan echter leiden tot hotspots, omdat alle invoegingen van nieuwe entiteiten waarschijnlijk aan één uiteinde het aaneengesloten bereik zijn geconcentreerd. De aanpak kan ook de schaalbaarheid verminderen. Als u de belasting gelijkmatiger wilt verdelen, kunt u overwegen om de partitiesleutel te hashen.

• Azure Table Storage ondersteunt transactionele bewerkingen voor entiteiten die deel uitmaken van dezelfde partitie. Een toepassing kan meerdere bewerkingen voor invoegen, bijwerken, verwijderen, vervangen of samenvoegen uitvoeren als een atomische eenheid, zolang de transactie niet meer dan 100 entiteiten bevat en de nettolading van de aanvraag niet groter is dan 4 MB. Bewerkingen die meerdere partities omvatten, zijn niet transactioneel en vereisen mogelijk dat u uiteindelijke consistentie implementeert. Zie Transacties voor entiteitsgroepen uitvoeren voor meer informatie over tabelopslag en transacties.

• Houd rekening met de granulariteit van de partitiesleutel:

  • Het gebruik van dezelfde partitiesleutel voor elke entiteit resulteert in één partitie die op één server wordt bewaard. Hiermee voorkomt u dat de partitie wordt uitgeschaald en wordt de belasting op één server gericht. Als gevolg hiervan is deze benadering alleen geschikt voor het opslaan van een klein aantal entiteiten. Het zorgt er echter voor dat alle entiteiten kunnen deelnemen aan entiteitsgroeptransacties.

  • Als u een unieke partitiesleutel gebruikt voor elke entiteit, zorgt u ervoor dat de table storage-service een afzonderlijke partitie voor elke entiteit maakt, wat mogelijk resulteert in een groot aantal kleine partities. Deze aanpak is beter schaalbaar dan het gebruik van een enkele partitiesleutel, maar entiteit-groepstransacties zijn niet mogelijk. Bovendien moet bij query's die meer dan één entiteit ophalen mogelijk van meer dan één server worden gelezen. Als de toepassing echter bereikquery's uitvoert, kan het gebruik van een monotone reeks voor de partitiesleutels helpen om deze query's te optimaliseren.

  • Als u de partitiesleutel deelt in een subset van entiteiten, kunt u gerelateerde entiteiten in dezelfde partitie groeperen. Bewerkingen die betrekking hebben op gerelateerde entiteiten kunnen worden uitgevoerd met behulp van de entiteit-groepstransacties. Query's die een set van gerelateerde entiteiten ophalen kunnen door het openen van één server worden voldaan.

Zie de ontwerphandleiding voor Azure Storage-tabellen en de strategie voor schaalbare partitionering voor meer informatie.

Azure Blob Storage partitioneren

Met Azure Blob Storage kunt u grote binaire objecten opslaan. Gebruik blok-blobs in scenario's wanneer 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 nodig is.

Elke blob (blok of pagina) wordt bewaard in een container in een Azure Storage-account. U kunt de containers gebruiken voor het groeperen van gerelateerde blobs 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 accountnaam + containernaam + blob-naam. De partitiesleutel wordt gebruikt om gegevens te partitioneren in bereiken en deze bereiken worden verdeeld over het systeem. Blobs kunnen over veel servers worden gedistribueerd om de toegang ertoe uit te schalen, maar één blob kan alleen worden geleverd door één server.

Als uw naamgevingsschema tijdstempels of numerieke id's gebruikt, kan dit leiden tot overmatig verkeer naar één partitie, waardoor het systeem wordt beperkt tot effectieve taakverdeling. Als u bijvoorbeeld dagelijkse bewerkingen hebt die gebruikmaken van een blobobject met een tijdstempel zoals jjjj-mm-dd, wordt al het verkeer voor die bewerking naar één partitieserver verzonden. In plaats daarvan kunt u de naam vooraf laten gaan door een hash met 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 dat niet. Als u consistentie moet garanderen bij het uitvoeren van schrijfbewerkingen over meerdere blokken, pagina's en blobs, neemt u een schrijfvergrendeling met behulp van een blob-lease.

Azure Storage-wachtrijen partitioneren

Met Azure Storage-wachtrijen kunt u asynchrone berichten tussen processen implementeren. Een Azure Storage-account kan een willekeurig aantal wachtrijen bevatten en elke wachtrij kan een willekeurig aantal berichten bevatten. De enige beperking is de ruimte die beschikbaar is in het opslagaccount. De maximale grootte van een afzonderlijk bericht is 64 KB. Als u berichten nodig hebt die groter zijn dan deze limiet, overweeg dan in plaats daarvan het gebruik van Azure Service Bus-wachtrijen.

Elke opslagwachtrij heeft een unieke naam binnen het opslagaccount waarvan deze deel uitmaakt. Azure partitioneert wachtrijen op basis van de naam. Alle berichten voor dezelfde wachtrij worden opgeslagen in dezelfde partitie, die wordt beheerd door één server. Verschillende wachtrijen kunnen worden beheerd door verschillende servers om de belasting te verdelen. De toewijzing van wachtrijen naar servers is transparant voor toepassingen en gebruikers.

Gebruik in een grootschalige toepassing niet dezelfde opslagwachtrij voor alle exemplaren van de toepassing, omdat deze methode ertoe kan leiden dat de server die als host fungeert voor de wachtrij een hot spot wordt. Gebruik in plaats daarvan verschillende wachtrijen voor verschillende functionele aspecten van de toepassing. Azure Storage-wachtrijen bieden geen ondersteuning voor transacties, dus het doorsturen van berichten naar verschillende wachtrijen heeft weinig invloed op de consistentie van berichten.

Een Azure Storage-wachtrij kan maximaal 2000 berichten per seconde verwerken. Als u met een hogere frequentie dan dit berichten wilt verwerken, kunt u meerdere wachtrijen maken. Maak bijvoorbeeld in een algemene toepassing afzonderlijke opslagwachtrijen in afzonderlijke opslagaccounts voor het afhandelen van instanties van een toepassing die in elke regio worden uitgevoerd.

Partitionering van Azure Service Bus

Azure Service Bus maakt gebruik van een berichtenbroker om berichten te verwerken die zijn verzonden naar een Service Bus-wachtrij of onderwerp. Standaard worden alle berichten die worden verzonden naar een wachtrij of onderwerp afgehandeld door hetzelfde berichtenbroker-proces. Deze architectuur kan een limiet opleggen aan de totale doorvoer van de berichtenwachtrij. U kunt echter ook een wachtrij of onderwerp partitioneren wanneer deze worden gemaakt. U dit doen door de eigenschap EnablePartitioning van de wachtrij of onderwerpbeschrijving op true in te stellen.

Een gepartitioneerde wachtrij of onderwerp is onderverdeeld in meerdere fragmenten, die elk worden ondersteund door een afzonderlijk berichtenarchief en berichtenbroker. Service Bus neemt de verantwoordelijkheid voor het maken en beheren van deze fragmenten. Wanneer een toepassing een bericht naar een gepartitioneerde wachtrij of onderwerp verzendt, wijst Service Bus het bericht toe aan een fragment voor die wachtrij of dat onderwerp. Wanneer een toepassing een bericht van een wachtrij of een abonnement ontvangt, controleert Service Bus elk fragment op het volgende beschikbare bericht en geeft het vervolgens door aan de toepassing ter verwerking.

Deze structuur helpt met het verdelen van de belasting over berichtenbrokers en berichtenarchieven, en verbetert daardoor de schaalbaarheid en beschikbaarheid. Als de berichtenbroker of het berichtenarchief voor één fragment tijdelijk niet beschikbaar is, kan Service Bus berichten ophalen uit een van de resterende beschikbare fragmenten.

Service Bus wijst een bericht als volgt toe aan een fragment:

• Als het bericht deel uitmaakt van een sessie, worden alle berichten met dezelfde waarde voor de eigenschap SessionId naar hetzelfde fragment verzonden.

• Als het bericht niet tot een sessie behoort, maar de afzender een waarde heeft opgegeven voor de eigenschap PartitionKey, worden vervolgens alle berichten met dezelfde waarde voor PartitionKey verzonden naar hetzelfde fragment.

  Notitie

  Als de eigenschappen SessionId en PartitionKey beide zijn opgegeven, moeten zij vervolgens worden ingesteld op dezelfde waarde, anders wordt het bericht geweigerd.

• Als de eigenschappen SessionId en PartitionKey niet zijn opgegeven voor een bericht, maar de detectie van duplicaten is ingeschakeld, wordt de eigenschap MessageId gebruikt. Alle berichten met dezelfde MessageId worden omgeleid naar de hetzelfde fragment.

• Als berichten geen SessionID, PartitionKey, of MessageId-eigenschap hebben, wijst Service Bus berichten sequentieel toe aan fragmenten. Als een fragment niet beschikbaar is, zal Service Bus verdergaan naar het volgende. Dit betekent dat een tijdelijke fout in de berichteninfrastructuur er niet toe leidt niet dat de bewerking voor het verzenden van een bericht mislukt.

Houd rekening met de volgende punten wanneer u beslist of en hoe u een Service Bus-berichtenwachtrij of onderwerp partitioneert:

• Service Bus-wachtrijen en onderwerpen worden binnen het bereik van een Service Bus-naamruimte gemaakt. Service Bus staat momenteel maximaal 100 gepartitioneerde wachtrijen en onderwerpen per naamruimte toe.

• Elke Service Bus-naamruimte legt quota op voor de beschikbare resources, zoals het aantal abonnementen per onderwerp, het aantal gelijktijdige aanvragen voor verzenden en ontvangen per seconde en het maximale aantal gelijktijdige verbindingen dat tot stand kan worden gebracht. Deze quota worden beschreven in Service Bus-quota. Als u verwacht deze waarden te overschrijden, maak dan aanvullende naamruimten met hun eigen wachtrijen en onderwerpen en verdeel het werk over deze naamruimten. Maak in een algemene toepassing bijvoorbeeld afzonderlijke naamruimten in elke regio en configureer instanties van een toepassing om de wachtrijen en onderwerpen in de dichtstbijzijnde naamruimte te gebruiken.

• Berichten die worden verzonden als onderdeel van een transactie moeten een partitiesleutel opgeven. Dit kan een SessionId-, PartitionKey-, of MessageId-eigenschap zijn. Alle berichten die worden verzonden als onderdeel van dezelfde transactie moeten dezelfde partitiesleutel opgeven, omdat ze door hetzelfde berichtenbroker-proces moeten worden afgehandeld. U kunt geen berichten verzenden naar verschillende wachtrijen en onderwerpen binnen dezelfde transactie.

• Gepartitioneerde wachtrijen en onderwerpen kunnen niet worden geconfigureerd om automatisch te worden verwijderd wanneer deze niet actief zijn.

• Op dit moment kunnen gepartitioneerde wachtrijen en onderwerpen niet worden gebruikt met het Advanced Message Queuing Protocol (AMQP) als u platformoverschrijdende of hybride oplossingen compileert.

Partitioneren van Azure Cosmos DB

Azure Cosmos DB for NoSQL is een NoSQL-database voor het opslaan van JSON-documenten. Een document in een Azure Cosmos DB-database is een JSON-geserialiseerde weergave van een object of ander stukje gegevens. Er worden geen vaste schema's afgedwongen, behalve dat elk document een unieke ID moet bevatten.

Documenten worden ingedeeld in verzamelingen. U kunt gerelateerde documenten samen in een verzameling groeperen. U kunt bijvoorbeeld in een systeem dat blogberichten onderhoudt, de inhoud van elk blogbericht opslaan als een document in een verzameling. U kunt ook verzamelingen voor elk type onderwerp maken. Daarnaast kunt u ook in een multitenant-toepassing, zoals een systeem waarop verschillende auteurs hun eigen blogberichten controleren en beheren, ook blogs partitioneren op auteur, en afzonderlijke verzamelingen voor elke auteur maken. De opslagruimte die is toegewezen aan verzamelingen is elastisch en kan indien nodig kleiner of groter worden.

Azure Cosmos DB biedt ondersteuning voor het automatisch partitioneren van gegevens op basis van een door de toepassing gedefinieerde partitiesleutel. Een logische partitie is een partitie waarin de gegevens voor de sleutelwaarde van één partitie zijn opgeslagen. Alle documenten met dezelfde waarde voor de partitiesleutel worden binnen dezelfde logische partitie geplaatst. Azure Cosmos DB distribueert waarden volgens hash van de partitiesleutel. Een logische partitie heeft een maximale grootte van 20 GB. De keuze van de partitiesleutel is daarom een belangrijke beslissing tijdens de ontwerpfase. Kies een eigenschap met een breed scala aan waarden en zelfs toegangspatronen. Zie voor meer informatie Partitioneren en schalen in Azure Cosmos DB.

Als het partitioneringsmechanisme dat Azure Cosmos DB biedt niet voldoende is, moet u de gegevens mogelijk sharden op toepassingsniveau. Documentenverzamelingen bieden een natuurlijk mechanisme voor het partitioneren van gegevens binnen een individuele database. De eenvoudigste manier voor het implementeren van sharding is een verzameling voor elke shard maken. Containers zijn logische resources en kunnen een of meer servers omvatten. Containers met een vaste grootte hebben een maximale doorvoer van 20 GB en 10.000 RU/s. Onbeperkte containers hebben geen maximale opslaggrootte, maar moeten een partitiesleutel opgeven. Met sharding van toepassingen moet de clienttoepassing aanvragen naar de juiste shard sturen. Dit gebeurt meestal door het implementeren van een eigen mechanisme voor toewijzing op basis van enkele kenmerken van de gegevens die de shard-sleutel definiëren.

Alle databases worden gemaakt in de context van een Azure Cosmos DB-databaseaccount. Een enkel account mag verschillende databases bevatten en geeft aan in welke regio's de databases worden gemaakt. Elk account dwingt ook een eigen toegangsbeheer af. U kunt Azure Cosmos DB-accounts gebruiken om shards (verzamelingen binnen databases) dicht bij de gebruikers te vinden die toegang nodig hebben en beperkingen af te dwingen, zodat alleen die gebruikers verbinding met hen kunnen maken.

Houd rekening met de volgende punten bij het bepalen hoe u gegevens partitioneert met Azure Cosmos DB for NoSQL:

• De resources die beschikbaar zijn voor een Azure Cosmos DB-database, zijn onderhevig aan de quotumbeperkingen van het account. Elke database kan een aantal verzamelingen bevatten en elke verzameling is gekoppeld aan een prestatieniveau die de frequentielimiet van de RU (gereserveerde doorvoer) voor die verzameling regelt. Zie Azure-abonnement en servicelimieten, quota en beperkingen voor meer informatie.

• Elk document moet een uniek kenmerk hebben dat kan worden gebruikt voor het aanduiden van dat document binnen de verzameling waarin het wordt bewaard. Dit kenmerk is anders dan de shard-sleutel, waarmee wordt gedefinieerd welke verzameling het document bevat. Een verzameling kan een groot aantal documenten bevatten. In theorie wordt deze alleen beperkt door de maximale lengte van de document-ID. De document-ID mag maximaal 255 tekens lang zijn.

• Alle bewerkingen op basis van een document worden in de context van een transactie uitgevoerd. Transacties worden afgestemd op de verzameling waarin het document is opgenomen. Als een bewerking is mislukt, wordt het uitgevoerde werk teruggedraaid. Wanneer een document onderworpen is aan een bewerking, zijn alle wijzigingen die zijn aangebracht onderworpen aan momentopname-isolatie. Dit mechanisme garandeert dat als bijvoorbeeld een aanvraag voor het maken van een nieuw document mislukt, een andere gebruiker die gelijktijdig query’s in de database uitvoert, geen gedeeltelijk document ziet dat vervolgens wordt verwijderd.

• Het bereik van Database-query's ligt ook bij het verzamelingsniveau. Een enkele query kan uit slechts één verzameling gegevens ophalen. Als u gegevens uit meerdere verzamelingen wilt ophalen, moet u een afzonderlijke query uitvoeren op elke verzameling en de resultaten samenvoegen in uw toepassingscode.

• Azure Cosmos DB ondersteunt programmeerbare items die allemaal naast documenten kunnen worden opgeslagen in een verzameling. Het gaat hierbij om opgeslagen procedures, door de gebruiker gedefinieerde functies en triggers (geschreven in JavaScript). Deze items hebben toegang tot elk document binnen dezelfde verzameling. Bovendien worden deze items uitgevoerd binnen het bereik van de ambient transactie (in het geval van een trigger die wordt geactiveerd als resultaat van een bewerking voor het maken, verwijderen of vervangen die wordt uitgevoerd op een document), of door een nieuwe transactie te starten (in het geval van een opgeslagen procedure die wordt uitgevoerd als gevolg van een aanvraag van een expliciete client). Als de code in een programmeerbaar item een uitzondering genereert, wordt de transactie teruggedraaid. U kunt opgeslagen procedures en triggers gebruiken om integriteit en consistentie tussen documenten te onderhouden, maar deze documenten moeten allemaal deel uitmaken van dezelfde verzameling.

• Het moet voor de verzamelingen die u van plan bent om in de databases te houden onwaarschijnlijk zijn dat ze langer zijn dan de doorvoerlimieten die zijn gedefinieerd door de prestaties van de verzamelingen. Zie Aanvraageenheden in Azure Cosmos DB voor meer informatie. Als u verwacht deze limieten te bereiken, kunt u overwegen verzamelingen voor databases in verschillende accounts op te splitsen om de belasting per verzameling te verminderen.

Partitionering van Azure Search

De mogelijkheid om gegevens te zoeken is vaak de primaire methode voor navigatie en verkennen die door veel webtoepassingen wordt geleverd. Dit helpt gebruikers informatiebronnen snel te vinden (bijvoorbeeld producten in een e-commerce toepassing) op basis van combinaties van zoekcriteria. De Azure Search-service biedt mogelijkheden voor zoeken in volledige tekst via webinhoud en bevat functies zoals automatisch aangevulde, voorgestelde query's op basis van near-matches en meervoudige navigatie. Zie Wat is Azure Search? voor meer informatie.

Azure Search slaat doorzoekbare inhoud op als JSON-documenten in een database. U definieert indexen die de doorzoekbare velden in deze documenten opgeven en levert deze definities aan Azure Search. Wanneer een gebruiker een zoekaanvraag verzendt, maakt Azure Search gebruik van de juiste indexen om overeenkomende items te vinden.

Om conflicten te vermijden kan de opslag die wordt gebruikt door Azure Search worden onderverdeeld in 1, 2, 3, 4, 6 of 12 partities, en elke partitie kan maximaal 6 keer worden gerepliceerd. Het product van het aantal partities vermenigvuldigd met het aantal replica's wordt de zoekeenheid (SU) genoemd. Eén instantie van Azure Search kan tot maximaal 36 SU's bevatten (een database met partities 12 ondersteunt maximaal 3 replica's).

U wordt gefactureerd voor elke SU die is toegewezen aan uw service. Wanneer het volume van doorzoekbare inhoud toeneemt of het aantal zoekaanvragen groeit, kunt u SU's toevoegen aan een bestaande instantie van Azure Search om de extra belasting te verwerken. Azure Search verdeelt de documenten zelf gelijkmatig over de partities. Er worden momenteel geen handmatige partitioneringsstrategieën ondersteund.

Elke partitie kan maximaal 15 miljoen documenten bevatten of 300 GB aan opslagruimte (afhankelijk van wat kleiner is) in beslag nemen. U kunt maximaal 50 indexen maken. De prestaties van de service variëren en zijn afhankelijk van de complexiteit van de documenten, de beschikbare indexen en de gevolgen van netwerklatentie. Gemiddeld moet een enkele replica (1 SU) in staat zijn tot het afhandelen van 15 query's per seconde (QPS), hoewel we aanraden om benchmarking met uw eigen gegevens uit te voeren om een nauwkeurigere meting van de doorvoer te verkrijgen. Zie Servicelimieten in Azure Search voor meer informatie.

U hebt beperkte controle over hoe Azure Search de gegevens voor elke instantie van de service partitioneert. U kunt echter misschien in een globale omgeving de prestaties verbeteren en de latentie en conflicten verder beperken door het partitioneren van de service zelf, met behulp van de volgende strategieën:

• Maak een exemplaar van Azure Search in elke geografische regio en zorg ervoor dat clienttoepassingen worden omgeleid naar het dichtstbijzijnde beschikbare exemplaar. Deze strategie vereist dat alle updates aan doorzoekbare inhoud tijdig worden gerepliceerd over alle exemplaren van de service.

• Maak twee lagen van Azure Search:

  • Een lokale service in elke regio met gegevens die het vaakst worden aangesproken door gebruikers in deze regio. Gebruikers kunnen hier aanvragen heen sturen voor snelle maar beperkte resultaten.
  • Een globale service die alle gegevens omvat. Gebruikers kunnen hier aanvragen heen sturen voor langzamere maar complete resultaten.

Deze aanpak is het meest geschikt wanneer er een aanzienlijke regionale variatie is in de gegevens die worden doorzocht.

Partitionering Azure Cache voor Redis

Azure Cache voor Redis biedt een gedeelde cacheservice in de cloud die is gebaseerd op het redis-sleutel-waardegegevensarchief. Zoals de naam al aangeeft, is Azure Cache voor Redis bedoeld als een cacheoplossing. Gebruik dit alleen voor de opslag van tijdelijke gegevens en niet als een permanent gegevensarchief. Toepassingen die gebruikmaken van Azure Cache voor Redis moeten kunnen blijven functioneren als de cache niet beschikbaar is. Azure Cache voor Redis ondersteunt primaire/secundaire replicatie om hoge beschikbaarheid te bieden, maar beperkt momenteel de maximale cachegrootte tot 53 GB. Als u meer ruimte nodig hebt dan dit, moet u extra caches maken. Zie Azure Cache voor Redis voor meer informatie.

Een Redis-gegevensarchief partitioneren omvat het splitsen van de gegevens over instanties van de Redis-service. Onder elk instantie wordt één partitie verstaan. Azure Cache voor Redis abstraheert de Redis-diensten achter een gevel en maakt ze niet rechtstreeks zichtbaar. De eenvoudigste manier om partitionering te implementeren, is door meerdere Azure Cache voor Redis exemplaren te maken en de gegevens over deze exemplaren te verdelen.

U kunt elk gegevensitem koppelen met een ID (een partitiesleutel) die aangeeft in welke cache het gegevensitem staat. De client-toepassingslogica kan vervolgens deze ID gebruiken voor het routeren van aanvragen naar de gewenste partitie. Dit schema is heel eenvoudig, maar als het partitioneringsschema verandert (bijvoorbeeld als er extra Azure Cache voor Redis exemplaren worden gemaakt), moeten clienttoepassingen mogelijk opnieuw worden geconfigureerd.

Systeemeigen Redis (niet Azure Cache voor Redis) ondersteunt partitionering aan de serverzijde op basis van Redis-clustering. In deze benadering kunt u de gegevens gelijkmatig over servers verdelen met behulp van een hash-mechanisme. Elke Redis-server slaat metagegevens op met een beschrijving van het bereik van de hash-sleutels die in de partitie aanwezig zijn en bevat tevens informatie over welke hash-sleutels zich in de partities op andere servers bevinden.

Clienttoepassingen doen niet meer dan aanvragen versturen naar een van de deelnemende Redis-servers (waarschijnlijk de dichtstbijzijnde). De Redis-server onderzoekt de aanvraag van de client. Als het lokaal kan worden opgelost, kan de aangevraagde bewerking worden uitgevoerd. Zo niet, dan wordt de aanvraag doorgestuurd naar een geschikte server.

Dit model wordt geïmplementeerd door Redis-clustering en wordt in meer detail beschreven op de pagina Zelfstudie Redis-cluster op de website van Redis. Redis clustering is transparant voor clienttoepassingen. Extra Redis-servers kunnen worden toegevoegd aan het cluster (en de gegevens kunnen opnieuw worden gepartitioneerd) zonder dat u de clients opnieuw hoeft te configureren.

Op de pagina Partitionering: het splitsen van gegevens tussen meerdere exemplaren van Redis op de Redis website vindt u meer informatie over het implementeren van partitioneren met Redis. De rest van deze sectie gaat ervan uit dat u partitioneren implementeert van clientzijde of met proxy-ondersteuning.

Houd rekening met de volgende punten bij het bepalen hoe u gegevens partitioneren met Azure Cache voor Redis:

• Azure Cache voor Redis is niet bedoeld om te fungeren als een permanent gegevensarchief, dus ongeacht het partitioneringsschema dat u implementeert, moet uw toepassingscode gegevens kunnen ophalen van een locatie die niet de cache is.

• Gegevens die vaak samen worden aangesproken moeten worden opgeslagen in dezelfde partitie. Redis is een krachtig sleutel-waardearchief dat verschillende maximaal geoptimaliseerde mechanismen biedt voor het structureren van gegevens. Deze mechanismen kunnen zijn:

  • Eenvoudige tekenreeksen (binaire gegevens met een lengte van maximaal 512 MB)
  • Cumulatieve typen zoals lijsten (die kunnen fungeren als wachtrijen en stacks)
  • Sets (geordend en niet-geordend)
  • Hashes (die verwante velden kunnen groeperen, zoals de items die staan voor de velden in een object)

• Met de cumulatieve typen kunt u veel gerelateerde waarden koppelen met dezelfde sleutel. Een Redis-sleutel geeft een lijst, set, of hash in plaats van de gegevensitems die deze bevat. Deze typen zijn allemaal beschikbaar met Azure Cache voor Redis en worden beschreven door de pagina Gegevenstypen op de Redis-website. Zo kunnen bijvoorbeeld in een e-commerce-systeem dat de orders bijhoudt, die door klanten worden geplaatst, de details van elke klant worden opgeslagen in een Redis-hash die is opgegeven met behulp van de klant-ID. Elke hash kan een verzameling van order-ID's bevatten voor de klant. Een aparte Redis-set kan de orders bevatten, opnieuw gestructureerd als hashes en versleuteld met behulp van de order-ID. Deze structuur wordt in afbeelding 8 getoond. Houd er rekening mee dat Redis geen enkele vorm van referentiële integriteit implementeert, zodat het de verantwoordelijkheid van de ontwikkelaar is om de relaties tussen klanten en orders te onderhouden.

Afbeelding 8. Voorgestelde structuur in Redis-opslag voor het vastleggen van klantorders en hun details.

• U kunt verticale partities implementeren door verwante informatie in andere aggregaties in dezelfde database op te slaan. U kunt bijvoorbeeld in een e-commerce-toepassing vaak gebruikte informatie over producten in één Redis-hash en minder vaak gebruikte gedetailleerde informatie in een andere opslaan. Beide hashes kunnen dezelfde product-ID gebruiken als onderdeel van de sleutel. U kunt bijvoorbeeld 'product: nn' (waarbij nn de product-id is) gebruiken voor de productgegevens en 'product_details: nn' voor de gedetailleerde gegevens. Deze strategie kan helpen de hoeveelheid gegevens te verminderen die door de meeste query's kunnen worden opgehaald.

• U een Redis gegevensarchief opnieuw partitioneren, maar houd er rekening mee dat dit een complexe en tijdrovende taak is. Redis-clustering kan gegevens automatisch opnieuw partitioneren, maar deze mogelijkheid is niet beschikbaar met Azure Cache voor Redis. Laat daarom bij het ontwerpen van uw partitieschema voldoende vrije ruimte in elke partitie om de verwachte groei van de gegevens gedurende een bepaalde periode toe te staan. Houd er echter rekening mee dat Azure Cache voor Redis is bedoeld om gegevens tijdelijk in de cache op te cachen en dat gegevens die in de cache zijn opgeslagen, een beperkte levensduur kunnen hebben die is opgegeven als een TTL-waarde (Time-to-Live). Voor relatief vluchtige gegevens, kan de TTL kort zijn, maar voor statische gegevens is de TTL mogelijk veel langer. Vermijd de opslag van grote hoeveelheden gegevens met lange levensduur in de cache als door het volume van deze gegevens de cache vol kan raken. U kunt een verwijderingsbeleid opgeven dat ervoor zorgt dat Azure Cache voor Redis gegevens verwijdert als er ruimte is in een premium.

  Notitie

  Wanneer u Azure Cache voor Redis gebruikt, geeft u de maximale grootte van de cache op (van 250 MB tot 53 GB) door de juiste prijscategorie te selecteren. Nadat een Azure Cache voor Redis is gemaakt, kunt u de grootte echter niet vergroten (of verkleinen).

• Redis batches en transacties kunnen niet meerdere verbindingen omvatten, daarom moeten alle gegevens die door een batch of transactie worden beïnvloed, worden bewaard in dezelfde database (shard).

  Notitie

  Een reeks bewerkingen in een Redis-transactie is niet per se atomisch. De opdrachten waaruit een transactie is samengesteld worden gecontroleerd en in de wachtrij geplaatst voordat ze worden uitgevoerd. Als er een fout optreedt tijdens deze fase, wordt de hele wachtrij genegeerd. Nadat de transactie is ingediend, worden de opdrachten in de wachtrij echter achtereenvolgens uitgevoerd. Als een opdracht mislukt, wordt alleen deze opdracht gestopt. Alle vorige en volgende opdrachten in de wachtrij worden uitgevoerd. Ga voor meer informatie naar de pagina Transacties op de Redis-website.

• Redis biedt ondersteuning voor een beperkt aantal atomische bewerkingen. De enige bewerkingen van dit type die ondersteuning bieden voor meerdere sleutels en waarden zijn MGET- en MSET-bewerkingen. MGET-bewerkingen retourneren een verzameling waarden voor een opgegeven lijst met sleutels en MSET-bewerkingen slaan een verzameling van waarden op voor een opgegeven lijst met sleutels. Als u deze bewerkingen wilt gebruiken, moeten de sleutel-waardeparen waarnaar wordt verwezen door de MSET- en MGET-opdrachten binnen dezelfde database worden opgeslagen.

Partitioneren van Azure Service Fabric

Azure Service Fabric is een microservices-platform dat een runtime biedt voor gedistribueerde toepassingen in de cloud. Service Fabric biedt ondersteuning voor uitvoerbare .NET-gastbestanden, stateful en stateless services en containers. Stateful services bieden een betrouwbare verzameling om permanent gegevens op te slaan in een sleutel/waarde-verzameling in de Service Fabric-cluster. Zie Richtlijnen en aanbevelingen voor betrouwbare verzamelingen in Azure Service Fabric voor meer informatie over strategieën voor het partitioneren van sleutels in een betrouwbare verzameling.

Volgende stappen

• Overzicht van Azure Service Fabric bevat een inleiding tot Azure Service Fabric.

• Op Partition Service Fabric betrouwbare services vindt u meer informatie over betrouwbare services in Azure Service Fabric.

Azure Event Hubs partitioneren

Azure Event Hubs is ontworpen voor grootschalig streaming, en partitioneren van gegevens is ingebouwd in de service om horizontaal schalen mogelijk te maken. Elke consument leest slechts een specifieke partitie van de berichtenstroom.

De gebeurtenisuitgever is alleen op de hoogte van de partitiesleutel en niet van de partitie waarop de gebeurtenissen worden gepubliceerd. Deze ontkoppeling van sleutel en partitie schermt de afzender af, zodat deze niet te veel te weten hoeft te komen over de downstreamverwerking. (Het is ook mogelijk gebeurtenissen rechtstreeks naar een bepaalde partitie te sturen, maar doorgaans wordt dit niet aanbevolen.)

Houd rekening met schalen op lange termijn wanneer u het aantal partities selecteert. Nadat een event hub is gemaakt, kunt u het aantal partities niet wijzigen.

Volgende stappen

Zie Wat is Event Hubs? voor meer informatie over het gebruik van partities in Event Hubs.

Zie Beschikbaarheid en consistentie in Event Hubs voor overwegingen over de wisselwerking tussen beschikbaarheid en consistentie.