Een partitiesleutel kiezen

Houd er rekening mee dat gegevens in JSON-documenten worden opgeslagen in Azure Cosmos DB-databases binnen containers die op hun beurt worden gedistribueerd over fysieke partities en waar de gegevens worden gerouteerd naar de juiste fysieke partitie op basis van de waarde van een partitiesleutel.

De partitiesleutel is een vereiste documenteigenschap die ervoor zorgt dat documenten met dezelfde partitiesleutelwaarde worden gerouteerd naar en opgeslagen binnen een specifieke fysieke partitie. Een fysieke partitie ondersteunt een vaste maximale hoeveelheid opslag en doorvoer (RU/s). Azure Cosmos DB distribueert automatisch de logische partities over de beschikbare fysieke partities, opnieuw met behulp van de waarde van de partitiesleutel om dit op een voorspelbare manier te doen.

In deze les leert u meer over logische partities en hoe u dynamische partities kunt voorkomen. Deze informatie helpt ons bij het kiezen van de juiste partitiesleutel voor de klantgegevens in ons scenario.

In Azure Cosmos DB verhoogt u de opslag en doorvoer door meer fysieke partities toe te voegen voor toegang tot en het opslaan van gegevens. De maximale opslaggrootte van een fysieke partitie is 50 GB en de maximale doorvoer is 10.000 RU/s.

Logische partities in Azure Cosmos DB

Een logische partitie is een abstractie boven de onderliggende fysieke partities. Meerdere logische partities kunnen worden opgeslagen binnen één fysieke partitie. Een container kan een onbeperkt aantal logische partities hebben. Afzonderlijke logische partities worden verplaatst naar nieuwe fysieke partities naarmate ze groter worden om een optimaal opslaggebruik en een optimale groei te garanderen. Het verplaatsen van logische partities als een eenheid zorgt ervoor dat alle documenten in de partitie zich op dezelfde fysieke partitie bevinden. De maximale grootte voor een logische partitie is 20 GB. Door een partitiesleutel met een hoge kardinaliteit te gebruiken, kunt u deze limiet van 20 GB voorkomen door uw gegevens over een groter aantal logische partities te spreiden. U kunt ook hiërarchische partitiesleutels gebruiken die partitiesleutelwaarden in een hiërarchie organiseren om deze limiet te voorkomen. Deze worden behandeld in een ander leertraject.

Een partitiesleutel biedt een manier om gegevens voor een logische partitie te routeren. Het is een eigenschap die bestaat in elk document in uw container waarmee uw gegevens worden gerouteerd. Een container is een andere abstractie voor alle gegevens die zijn opgeslagen met dezelfde partitiesleutel. De partitiesleutel wordt gedefinieerd wanneer u een container maakt.

In het volgende voorbeeld heeft de container een partitiesleutel van /username.

Vermijd dynamische partities

Wanneer u gegevens modelleert voor Azure Cosmos DB, is het van cruciaal belang dat de partitiesleutel die u kiest, resulteert in een gelijkmatige distributie van gegevens en aanvragen in zowel logische als extensie, de fysieke partities in uw container. Dit geldt vooral wanneer containers groter worden en een toenemend aantal fysieke partities hebben.

Als u het ontwerp van uw database tijdens de ontwikkeling niet test, wordt er mogelijk pas een slechte keuze voor de partitiesleutel weergegeven als de toepassing in productie is en belangrijke gegevens al zijn geschreven.

Wanneer gegevens niet correct zijn gepartitioneerd, kan dit leiden tot dynamische partities. Dynamische partities voorkomen dat uw toepassingsworkload kan worden geschaald en ze kunnen zich voordoen op zowel opslag als doorvoer.

Dynamische opslagpartities

Een dynamische partitie in opslag treedt op wanneer u een partitiesleutel hebt die resulteert in zeer asymmetrische opslagpatronen. Denk bijvoorbeeld aan een multitenant-toepassing die TenantId als partitiesleutel gebruikt met zes tenants: A tot F. Tenants B, C, E en F zijn erg klein, Tenant D heeft wat meer gegevens. Tenant A is echter enorm en bereikt snel de limiet van 20 GB voor de partitie. In dit scenario moeten we een andere partitiesleutel selecteren die de opslag verspreidt over meer logische partities.

Dynamische doorvoerpartities

Doorvoer kan last hebben van dynamische partities wanneer de meeste of alle aanvragen naar dezelfde logische partitie gaan.

Het is belangrijk om inzicht te krijgen in de toegangspatronen voor uw toepassing om ervoor te zorgen dat aanvragen zo gelijkmatig mogelijk worden verdeeld over partitiesleutelwaarden. Wanneer doorvoer wordt ingericht voor een container in Azure Cosmos DB, wordt deze gelijkmatig toegewezen aan alle fysieke partities binnen een container.

Als u bijvoorbeeld een container met 30.000 RU/s hebt, wordt deze workload verdeeld over de drie fysieke partities voor dezelfde zes tenants die eerder zijn vermeld. Elke fysieke partitie krijgt dus 10.000 RU/s. Als tenant D alle 10.000 RU/s verbruikt, wordt deze snelheid beperkt omdat de doorvoer die is toegewezen aan de andere partities niet kan worden verbruikt. Dit resulteert in slechte prestaties voor tenant C en D en het verlaten van ongebruikte rekencapaciteit in de andere fysieke partities en resterende tenants. Uiteindelijk resulteert deze partitiesleutel in een databaseontwerp waarbij de workload van de toepassing niet kan worden geschaald.

Wanneer gegevens en aanvragen gelijkmatig worden verspreid, kan de database groeien op een manier die volledig gebruikmaakt van zowel de opslag als doorvoer. Het resultaat is de best mogelijke prestaties en de hoogste efficiëntie. Kortom, het databaseontwerp wordt geschaald.

Leesbewerkingen versus schrijfbewerkingen overwegen

Wanneer u een partitiesleutel kiest, moet u ook overwegen of de gegevens zwaar worden gelezen of zwaar worden geschreven. U moet aanvragen met veel schrijfbewerkingen distribueren met een partitiesleutel met een hoge kardinaliteit.

Voor leesintensieve workloads moet u ervoor zorgen dat query's worden verwerkt door een of een beperkt aantal partities door een WHERE component met een gelijkheidsfilter op de partitiesleutel of een IN-operator op een subset van partitiesleutelwaarden in uw query's op te nemen.

In scenario's waarin de werkbelasting van de toepassing zowel zware schrijf- als leesintensief is, is er een oplossing. Dat verkennen we in de volgende module.

In de volgende afbeelding ziet u een container die is gepartitioneerd op gebruikersnaam. Deze query raakt slechts één logische partitie, dus de prestaties zijn altijd goed.

Een query die filtert op een andere eigenschap, zoals favoriteColor, zou 'uitwaaieren' voor alle partities in de container. Dit wordt ook wel een query voor meerdere partities genoemd. Een dergelijke query wordt uitgevoerd zoals verwacht wanneer de container klein is en slechts één partitie in beslag neemt. Naarmate de container groeit en er steeds meer fysieke partities zijn, wordt deze query langzamer en duurder, omdat deze elke partitie moet controleren om de resultaten te verkrijgen, ongeacht of de fysieke partitie gegevens bevat die betrekking hebben op de query of niet.

Een partitiesleutel kiezen voor klanten

Nu u inzicht hebt in partitionering in Azure Cosmos DB, kunnen we beslissen over een partitiesleutel voor onze klantgegevens. Zoals we eerder hebben besproken, voeren we drie bewerkingen uit op klanten: een klant maken, een klant bijwerken en een klant ophalen. In dit geval halen we de klant op met hun id. Omdat deze bewerking het meest wordt aangeroepen, is het zinvol om de id van de klant de partitiesleutel voor de container te maken.

U kunt zich hier zorgen maken dat het maken van de id van de partitiesleutel betekent dat we net zoveel logische partities hebben als er klanten zijn, waarbij elke logische partitie slechts één document bevat. Miljoenen klanten zouden leiden tot miljoenen logische partities.

Maar dit is perfect! Logische partities zijn een virtueel concept en er is geen limiet voor het aantal logische partities dat u kunt hebben. Azure Cosmos DB plaatst meerdere logische partities op dezelfde fysieke partitie. Naarmate logische partities in getal of grootte toenemen, worden deze door Cosmos DB naar nieuwe fysieke partities verplaatst wanneer dat nodig is.