Partitionering en horizontaal schalen in Azure Cosmos DB

VAN TOEPASSING OP: NoSQL MongoDB Cassandra Gremlin Tafel

Azure Cosmos DB maakt gebruik van partitionering om afzonderlijke containers in een database te schalen om te voldoen aan de prestatiebehoeften van uw toepassing. De items in een container zijn onderverdeeld in afzonderlijke subsets die logische partities worden genoemd. Logische partities worden gevormd op basis van de waarde van een partitiesleutel die is gekoppeld aan elk item in een container. Alle items in een logische partitie hebben dezelfde partitiesleutelwaarde.

Een container bevat bijvoorbeeld items. Elk item heeft een unieke waarde voor de UserID eigenschap. Als UserID deze fungeert als de partitiesleutel voor de items in de container en er 1000 unieke UserID waarden zijn, worden er 1000 logische partities gemaakt voor de container.

Naast een partitiesleutel die de logische partitie van het item bepaalt, heeft elk item in een container een item-id (uniek binnen een logische partitie). Als u de partitiesleutel en de item-id combineert, wordt de index van het item gemaakt, waarmee het item uniek wordt geïdentificeerd. Het kiezen van een partitiesleutel is een belangrijke beslissing die van invloed is op de prestaties van uw toepassing.

In dit artikel wordt de relatie tussen logische en fysieke partities uitgelegd. Ook worden aanbevolen procedures voor partitionering besproken en krijgt u een uitgebreide weergave van de werking van horizontaal schalen in Azure Cosmos DB. Het is niet nodig om deze interne gegevens te begrijpen om uw partitiesleutel te selecteren, maar we behandelen deze zodat u meer duidelijkheid hebt over de werking van Azure Cosmos DB.

Logische partities

Een logische partitie bestaat uit een set items met dezelfde partitiesleutel. In een container die bijvoorbeeld gegevens over voedselvoeding bevat, bevatten alle items een foodGroup eigenschap. U kunt deze gebruiken foodGroup als partitiesleutel voor de container. Groepen items met specifieke waarden voor foodGroup, zoals Beef Products, Baked Productsen Sausages and Luncheon Meats, vormen afzonderlijke logische partities.

Een logische partitie definieert ook het bereik van databasetransacties. U kunt items in een logische partitie bijwerken met behulp van een transactie met isolatie van momentopnamen. Wanneer nieuwe items worden toegevoegd aan een container, maakt het systeem transparant nieuwe logische partities. U hoeft zich geen zorgen te maken over het verwijderen van een logische partitie wanneer de onderliggende gegevens worden verwijderd.

Er is geen limiet voor het aantal logische partities in uw container. Elke logische partitie kan maximaal 20 GB aan gegevens opslaan. Goede opties voor partitiesleutels hebben een breed scala aan mogelijke waarden. In een container waarin alle items een foodGroup eigenschap bevatten, kunnen de gegevens in de Beef Products logische partitie bijvoorbeeld oplopen tot 20 GB. Als u een partitiesleutel met een breed scala aan mogelijke waarden selecteert, zorgt u ervoor dat de container kan worden geschaald.

U kunt Azure Monitor-waarschuwingen gebruiken om te controleren of de grootte van een logische partitie 20 GB nadert.

Fysieke partities

Een container wordt geschaald door gegevens en doorvoer te distribueren over fysieke partities. Intern worden een of meer logische partities toegewezen aan één fysieke partitie. Meestal hebben kleinere containers veel logische partities, maar ze vereisen slechts één fysieke partitie. In tegenstelling tot logische partities zijn fysieke partities een interne implementatie van het systeem en beheert Azure Cosmos DB volledig fysieke partities.

Het aantal fysieke partities in uw container is afhankelijk van de volgende kenmerken:

• De hoeveelheid ingerichte doorvoer (elke afzonderlijke fysieke partitie kan een doorvoer van maximaal 10.000 aanvraageenheden per seconde bieden). De limiet van 10.000 RU/s voor fysieke partities impliceert dat logische partities ook een limiet van 10.000 RU/s hebben, omdat elke logische partitie slechts aan één fysieke partitie is toegewezen.

• De totale gegevensopslag (elke afzonderlijke fysieke partitie kan maximaal 50 GB aan gegevens opslaan).

Notitie

Fysieke partities zijn een interne implementatie van het systeem en worden volledig beheerd door Azure Cosmos DB. Wanneer u uw oplossingen ontwikkelt, richt u zich niet op fysieke partities, omdat u deze niet kunt beheren. Richt u in plaats daarvan op uw partitiesleutels. Als u een partitiesleutel kiest waarmee het doorvoerverbruik gelijkmatig wordt verdeeld over logische partities, zorgt u ervoor dat het doorvoerverbruik voor fysieke partities wordt verdeeld.

Er is geen limiet voor het totale aantal fysieke partities in uw container. Naarmate uw ingerichte doorvoer of gegevensgrootte groeit, worden in Azure Cosmos DB automatisch nieuwe fysieke partities gemaakt door bestaande partities te splitsen. Fysieke partitiesplitsingen hebben geen invloed op de beschikbaarheid van uw toepassing. Nadat de fysieke partitie is gesplitst, worden alle gegevens binnen één logische partitie nog steeds opgeslagen op dezelfde fysieke partitie. Een fysieke partitiesplitsing maakt eenvoudigweg een nieuwe toewijzing van logische partities aan fysieke partities.

De doorvoer die is ingericht voor een container, wordt gelijkmatig verdeeld over fysieke partities. Een partitiesleutelontwerp dat aanvragen niet gelijkmatig distribueert, kan ertoe leiden dat er te veel aanvragen worden omgeleid naar een kleine subset van partities die 'dynamisch' worden. Dynamische partities leiden tot inefficiënt gebruik van ingerichte doorvoer, wat kan leiden tot snelheidsbeperking en hogere kosten.

Denk bijvoorbeeld aan een container met het pad /foodGroup dat is opgegeven als de partitiesleutel. De container kan een willekeurig aantal fysieke partities hebben, maar in dit voorbeeld wordt ervan uitgegaan dat deze drie partities heeft. Eén fysieke partitie kan meerdere partitiesleutels bevatten. Als voorbeeld kan de grootste fysieke partitie de belangrijkste drie belangrijkste logische partities bevatten: Beef Products, Vegetable and Vegetable Productsen Soups, Sauces, and Gravies.

Als u een doorvoer van 18.000 aanvraageenheden per seconde (RU/s) toewijst, kan elk van de drie fysieke partities 1/3 van de totale ingerichte doorvoer gebruiken. Binnen de geselecteerde fysieke partitie kunnen de logische partitiesleutels Beef Productsen Vegetable and Vegetable ProductsSoups, Sauces, and Gravies gezamenlijk gebruikmaken van de 6000 ingerichte RU/s van de fysieke partitie. Omdat ingerichte doorvoer gelijkmatig is verdeeld over de fysieke partities van uw container, is het belangrijk om een partitiesleutel te kiezen waarmee het doorvoerverbruik gelijkmatig wordt verdeeld. Zie het kiezen van de juiste logische partitiesleutel voor meer informatie.

Logische partities beheren

Azure Cosmos DB beheert de plaatsing van logische partities op fysieke partities transparant en automatisch om efficiënt te voldoen aan de schaalbaarheids- en prestatiebehoeften van de container. Naarmate de doorvoer- en opslagvereisten van een toepassing toenemen, verplaatst Azure Cosmos DB logische partities om de belasting automatisch over een groter aantal fysieke partities te verdelen. Meer informatie over fysieke partities.

Azure Cosmos DB maakt gebruik van hash-partities om logische partities over fysieke partities te verdelen. Azure Cosmos DB hashes de partitiesleutelwaarde van een item. Het gehashte resultaat bepaalt de logische partitie. Vervolgens wijst Azure Cosmos DB de sleutelruimte van partitiesleutelhashes gelijkmatig toe aan de fysieke partities.

Transacties (in opgeslagen procedures of triggers) zijn alleen toegestaan voor items in één logische partitie.

Replicasets

Elke fysieke partitie bestaat uit een set replica's, ook wel een replicaset genoemd. Elke replica fungeert als host voor een exemplaar van de database-engine. Een replicaset maakt het gegevensarchief in de fysieke partitie duurzaam, maximaal beschikbaar en consistent. Elke replica waaruit de fysieke partitie bestaat, neemt het opslagquotum van de partitie over. Alle replica's van een fysieke partitie ondersteunen gezamenlijk de doorvoer die is toegewezen aan de fysieke partitie. Azure Cosmos DB beheert automatisch replicasets.

Voor kleinere containers is doorgaans slechts één fysieke partitie vereist, maar ze hebben nog steeds ten minste vier replica's.

In de volgende afbeelding ziet u hoe logische partities worden toegewezen aan fysieke partities die wereldwijd worden gedistribueerd. Partitieset in de installatiekopieën verwijst naar een groep fysieke partities die dezelfde logische partitiesleutels in meerdere regio's beheren:

Een partitiesleutel kiezen

Een partitiesleutel heeft twee onderdelen: het partitiesleutelpad en de waarde van de partitiesleutel. Denk bijvoorbeeld aan een item { "userId" : "Andrew", "worksFor": "Microsoft" } als u 'userId' als partitiesleutel kiest, het volgende zijn de twee partitiesleutelonderdelen:

• Het pad naar de partitiesleutel (bijvoorbeeld: '/userId'). Het pad naar de partitiesleutel accepteert alfanumerieke tekens en onderstrepingstekens (_). U kunt ook geneste objecten gebruiken met behulp van de standaardpad notatie(/).

• De waarde van de partitiesleutel (bijvoorbeeld: 'Andrew'). De waarde van de partitiesleutel kan bestaan uit tekenreeks- of numerieke typen.

Zie het artikel Over de quota van de Azure Cosmos DB-service voor meer informatie over de limieten voor doorvoer, opslag en lengte van de partitiesleutel.

Het selecteren van uw partitiesleutel is een eenvoudige maar belangrijke ontwerpkeuze in Azure Cosmos DB. Nadat u uw partitiesleutel hebt geselecteerd, is het niet mogelijk om deze in-place te wijzigen. Als u de partitiesleutel wilt wijzigen, moet u uw gegevens verplaatsen naar een nieuwe container met de nieuwe gewenste partitiesleutel. (Hulp bij het kopiëren van containers voor dit proces.)

Voor alle containers moet uw partitiesleutel het volgende doen:

• Wees een eigenschap met een waarde die niet verandert. Als een eigenschap uw partitiesleutel is, kunt u de waarde van die eigenschap niet bijwerken.

• Mag alleen waarden bevatten String , of getallen moeten idealiter worden geconverteerd naar een String, als er een kans is dat ze buiten de grenzen van dubbele precisie getallen zijn volgens IEEE 754 binary64. De Json-specificatie noemt de redenen waarom het gebruik van getallen buiten deze grens in het algemeen een slechte gewoonte is vanwege waarschijnlijke interoperabiliteitsproblemen. Deze problemen zijn met name relevant voor de partitiesleutelkolom, omdat deze onveranderbaar is en gegevensmigratie later moet worden gewijzigd.

• Moet een hoge kardinaliteit hebben. Met andere woorden, de eigenschap moet een breed scala aan mogelijke waarden hebben.

• Verbruik van aanvraageenheden (RU) en gegevensopslag gelijkmatig verdelen over alle logische partities. Deze verdeling zorgt voor zelfs RU-verbruik en opslagdistributie over uw fysieke partities.

• Waarden hebben die doorgaans niet groter zijn dan 2048 bytes of 101 bytes als grote partitiesleutels niet zijn ingeschakeld. Zie voor meer informatie grote partitiesleutels

Als u ACID-transacties met meerdere items nodig hebt in Azure Cosmos DB, moet u opgeslagen procedures of triggers gebruiken. Alle op JavaScript gebaseerde opgeslagen procedures en triggers zijn gericht op één logische partitie.

Notitie

Als u slechts één fysieke partitie hebt, is de waarde van de partitiesleutel mogelijk niet relevant omdat alle query's zich richten op dezelfde fysieke partitie.

Typen partitiesleutels

Partitioneringsstrategie	Gebruik	Voordelen	Nadelen
Reguliere partitiesleutel (bijvoorbeeld CustomerId, OrderId)	- Gebruik deze optie wanneer de partitiesleutel een hoge kardinaliteit heeft en wordt uitgelijnd met querypatronen (bijvoorbeeld filteren op CustomerId). - Geschikt voor workloads waarbij query's voornamelijk gericht zijn op de gegevens van één klant (bijvoorbeeld het ophalen van alle orders voor een klant).	- Eenvoudig te beheren. - Efficiënte query's wanneer het toegangspatroon overeenkomt met de partitiesleutel (bijvoorbeeld het uitvoeren van query's op alle orders op CustomerId). - Voorkomt query's tussen partities als toegangspatronen consistent zijn.	- Risico op dynamische partities als sommige waarden (bijvoorbeeld een paar klanten met veel verkeer) aanzienlijk meer gegevens genereren dan andere. - Kan de limiet van 20 GB per logische partitie bereiken als het gegevensvolume voor een specifieke sleutel snel groeit.
Synthetische partitiesleutel (bijvoorbeeld CustomerId + OrderDate)	- Gebruik dit veld wanneer geen enkel veld zowel een hoge kardinaliteit heeft als overeenkomen met querypatronen. - Geschikt voor schrijfintensieve werkbelastingen waarbij gegevens gelijkmatig moeten worden verdeeld over fysieke partities (bijvoorbeeld veel bestellingen die op dezelfde datum zijn geplaatst).	- Helpt bij het gelijkmatig verdelen van gegevens over partities, waardoor dynamische partities worden verminderd (bijvoorbeeld het distribueren van orders door zowel CustomerId als OrderDate). - Spreidt schrijfbewerkingen over meerdere partities, waardoor de doorvoer wordt verbeterd.	- Query's die slechts op één veld filteren (bijvoorbeeld alleen CustomerId) kunnen leiden tot query's tussen partities. - Query's tussen partities kunnen leiden tot een hoger RU-verbruik (2-3 RU/s extra kosten voor elke fysieke partitie die bestaat) en extra latentie.
Hiërarchische partitiesleutel (HPK) (bijvoorbeeld CustomerId/OrderId, StoreId/ProductId)	- Gebruik deze functie wanneer u partitionering op meerdere niveaus nodig hebt om grootschalige gegevenssets te ondersteunen. - Ideaal wanneer query's filteren op de eerste en tweede niveaus van de hiërarchie.	- Helpt de limiet van 20 GB te voorkomen door meerdere partitieniveaus te maken. - Efficiënt query's uitvoeren op beide hiërarchische niveaus (bijvoorbeeld eerst filteren op CustomerID en vervolgens op OrderID). - Minimaliseert query's voor meerdere partities voor query's die gericht zijn op het hoogste niveau (bijvoorbeeld het ophalen van alle gegevens uit een specifieke CustomerID).	- Vereist zorgvuldige planning om ervoor te zorgen dat de sleutel op het eerste niveau een hoge kardinaliteit heeft en is opgenomen in de meeste query's. - Complexer om te beheren dan een gewone partitiesleutel. - Als query's niet zijn afgestemd op de hiërarchie (bijvoorbeeld alleen filteren op OrderID wanneer CustomerID het eerste niveau is), kunnen de queryprestaties lijden.

Partitiesleutels voor leesintensieve containers

Voor de meeste containers zijn de bovenstaande criteria alles wat u moet overwegen bij het kiezen van een partitiesleutel. Voor grote leesintensieve containers wilt u echter mogelijk een partitiesleutel kiezen die vaak wordt weergegeven als filter in uw query's. Query's kunnen efficiënt worden gerouteerd naar alleen de relevante fysieke partities door de partitiesleutel op te nemen in het filterpredicaat.

Deze eigenschap kan een goede keuze voor partitiesleutels zijn als de meeste aanvragen van uw workload query's zijn en de meeste query's een gelijkheidsfilter hebben voor dezelfde eigenschap. Als u bijvoorbeeld vaak een query uitvoert waarop filters worden toegepastUserID, vermindert u het aantal query's tussen partities als u selecteert UserID als de partitiesleutel.

Als uw container echter klein is, hebt u waarschijnlijk niet voldoende fysieke partities om zich zorgen te maken over de prestaties van query's tussen partities. Voor de meeste kleine containers in Azure Cosmos DB zijn slechts één of twee fysieke partities vereist.

Als uw container kan groeien tot meer dan een paar fysieke partities, moet u ervoor zorgen dat u een partitiesleutel kiest die query's tussen partities minimaliseert. Uw container vereist meer dan een paar fysieke partities wanneer een van de volgende waarden waar is:

• Uw container heeft meer dan 30.000 RU's ingericht

• Uw container slaat meer dan 100 GB aan gegevens op

Item-id gebruiken als partitiesleutel

Notitie

Deze sectie is voornamelijk van toepassing op de API voor NoSQL. Andere API's, zoals de API voor Gremlin, bieden geen ondersteuning voor de unieke id als de partitiesleutel.

Als uw container een eigenschap heeft met een breed scala aan mogelijke waarden, is het waarschijnlijk een uitstekende keuze voor partitiesleutels. Een mogelijk voorbeeld van een dergelijke eigenschap is de item-id. Voor kleine, leesintensieve containers of schrijfintensieve containers van elke grootte is de item-id (/id) natuurlijk een uitstekende keuze voor de partitiesleutel.

De item-id van de systeemeigenschap bestaat in elk item in uw container. Mogelijk hebt u andere eigenschappen die een logische id van uw item vertegenwoordigen. In veel gevallen zijn deze id's ook geweldige opties voor partitiesleutels om dezelfde redenen als de item-id.

De item-id is een uitstekende keuze voor partitiesleutels om de volgende redenen:

• Er is een breed scala aan mogelijke waarden (één unieke item-id per item).
• Omdat er een unieke item-id per item is, doet de item-id een uitstekende taak bij het gelijkmatig verdelen van RU-verbruik en gegevensopslag.
• U kunt eenvoudig efficiënte puntleesbewerkingen uitvoeren omdat u altijd de partitiesleutel van een item kent als u de item-id kent.

Enkele aandachtspunten bij het selecteren van de item-id als partitiesleutel zijn:

• Als de item-id de partitiesleutel is, wordt deze een unieke id in de hele container. U kunt geen items maken met dubbele item-id's.
• Als u een container met veel leesintensieve partities hebt, zijn query's efficiënter als ze een gelijkheidsfilter hebben met de item-id.
• U kunt geen opgeslagen procedures of triggers uitvoeren die gericht zijn op meerdere logische partities.

Gerelateerde inhoud

• Ingerichte doorvoer in Azure Cosmos DB.
• Wereldwijde distributie in Azure Cosmos DB.
• Training: uw gegevens modelleren en partitioneren in Azure Cosmos DB.