Partitionering en horizontaal schalen in Azure Cosmos DB

Azure Cosmos DB maakt gebruik van partitionering om 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. Formulier logische partities 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.

Elk item in een container heeft een partitiesleutel die de logische partitie en een item-id uniek binnen die partitie bepaalt. 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, worden aanbevolen procedures voor partitionering besproken en wordt een uitgebreid overzicht geboden van de werking van horizontaal schalen in Azure Cosmos DB. U hoeft deze interne gegevens niet te begrijpen om uw partitiesleutel te selecteren, maar in dit artikel wordt uitgelegd hoe Azure Cosmos DB werkt.

Logische partities

Een logische partitie is een set items die dezelfde partitiesleutel delen. In een container die bijvoorbeeld gegevens over voedselvoeding bevat, bevatten alle items een foodGroup eigenschap. Gebruik foodGroup deze 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 een container. Elke logische partitie kan maximaal 20 GB aan gegevens opslaan. Effectieve 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.

Gebruik Azure Monitor-waarschuwingen 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. Kleinere containers hebben doorgaans veel logische partities, maar vereisen slechts één fysieke partitie. In tegenstelling tot logische partities zijn fysieke partities een interne systeem-implementatie en worden deze volledig beheerd door Azure Cosmos DB.

Het aantal fysieke partities in een container is afhankelijk van deze 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 gigabyte aan gegevens opslaan).

Er is geen limiet voor het totale aantal fysieke partities in een 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.

Ingerichte doorvoer voor een container verdeelt gelijkmatig 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 veroorzaken 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, gebruikt elk van de drie fysieke partities een derde van de totale ingerichte doorvoer. 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 De juiste logische partitiesleutel kiezen voor meer informatie.

Logische partities beheren

Azure Cosmos DB beheert automatisch de plaatsing van logische partities op fysieke partities om te voldoen aan de schaalbaarheids- en prestatiebehoeften van de container. Wanneer de doorvoer- en opslagvereisten van een toepassing toenemen, verplaatst Azure Cosmos DB logische partities om de belasting over meer fysieke partities te verdelen. Meer informatie over fysieke partities.

Azure Cosmos DB maakt gebruik van op hash gebaseerde partitionering om logische partities over fysieke partities te distribueren. 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 in de fysieke partitie neemt het opslagquotum van de partitie over. Alle replica's van een fysieke partitie ondersteunen gezamenlijk de doorvoer die aan die fysieke partitie is toegewezen. Azure Cosmos DB beheert automatisch replicasets.

Kleinere containers vereisen meestal één fysieke partitie, maar ze hebben nog steeds ten minste vier replica's.

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

Meer informatie over de limieten voor doorvoer, opslag en partitiesleutellengte in het artikel over quota voor azure Cosmos DB-service.

Het selecteren van uw partitiesleutel is een eenvoudige maar belangrijke ontwerpkeuze in Azure Cosmos DB. Zodra u de partitiesleutel hebt geselecteerd, kunt u deze niet meer wijzigen. Als u de partitiesleutel wilt wijzigen, verplaatst u uw gegevens naar een nieuwe container met de gewenste partitiesleutel. Taken voor het kopiëren van containers helpen bij dit proces. U kunt ook globale secundaire indexen (preview) toevoegen om een kopie van uw gegevens te maken met verschillende partitiesleutels die zijn geoptimaliseerd voor specifieke querypatronen.

Voor alle containers moet de 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.

• String Alleen waarden bevatten, of getallen converteren naar een String als ze de grenzen van dubbele precisienummers kunnen overschrijden volgens het IEEE (Institute of Electrical and Electronics Engineers) 754 binary64. In de Json-specificatie wordt uitgelegd waarom het gebruik van getallen buiten deze grens een slechte procedure is vanwege 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.

Typen partitiesleutels

Partitiesleutels voor leesintensieve containers

Voor de meeste containers zijn deze 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. Door de partitiesleutel in het filterpredicaat op te nemen, kunnen query's efficiënt worden gerouteerd naar alleen de relevante fysieke partities.

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

Als uw container klein is, hebt u waarschijnlijk niet voldoende fysieke partities om u 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 heeft meer dan een paar fysieke partities nodig als een van de volgende scenario's waar is:

• Uw container heeft meer dan 30.000 aanvraageenheden ingericht

• Uw container slaat meer dan 100 GB aan gegevens op

Globale secundaire indexen voor queries tussen partities

Als uw toepassing efficiënt query's moet uitvoeren op gegevens met meerdere verschillende eigenschappen, bieden globale secundaire indexen (preview) een alternatief voor het gebruik van één strategie voor partitiesleutels voor de gegevensset. Globale secundaire indexen zijn extra containers met verschillende partitiesleutels, die automatisch worden gesynchroniseerd met gegevens uit uw broncontainer.

Houd rekening met globale secundaire indexen wanneer:

• U hebt meerdere querypatronen die niet kunnen worden voldaan door één strategie voor partitiesleutels
• Het wijzigen van uw bestaande partitiesleutel zou verstorend zijn
• U moet analytische of zoekworkloads isoleren van transactionele bewerkingen

Globale secundaire indexen helpen query's tussen partities te voorkomen door dezelfde gegevens op te slaan met verschillende partitiesleutels die zijn geoptimaliseerd voor specifieke querypatronen. Deze aanpak kan het RU-verbruik aanzienlijk verminderen en de queryprestaties verbeteren voor scenario's waarbij alleen optimalisatie van partitiesleutels niet voldoende is.

Item-id gebruiken als partitiesleutel

Als uw container een eigenschap heeft met een breed scala aan mogelijke waarden, is dit waarschijnlijk een uitstekende keuze voor partitiesleutels. Een 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 is aanwezig in elk item in uw container. Mogelijk hebt u andere eigenschappen die een logische id van uw item vertegenwoordigen. In veel gevallen zijn deze unieke 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.

Houd rekening met de volgende opmerkingen bij het selecteren van de item-id als partitiesleutel:

• Als de item-id de partitiesleutel is, wordt deze een unieke id voor uw hele container. U kunt geen items met dubbele id's maken.
• Als u een container met veel leesintensieve partities hebt, zijn query's efficiënter als ze een gelijkheidsfilter hebben met de item-id.
• Opgeslagen procedures of triggers kunnen niet 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