Partitionering en horizontaal schalen in Azure Cosmos DB

  • Artikel
  • 10 minuten om te lezen

VAN TOEPASSING OP: SQL-API Cassandra-API Gremlin-API Table-API Azure Cosmos DB-API voor MongoDB

Azure Cosmos DB maakt gebruik van partitionering om afzonderlijke containers in een database te schalen om te voldoen aan de prestatiebehoeften van uw toepassing. Bij partitionering worden de items in een container onderverdeeld in afzonderlijke subsets die logische partities worden genoemd. Logische partities worden gevormd op basis van de waarde van een partitiesleutel die aan elk item in een container is gekoppeld. 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 als de partitiesleutel voor de items in de container fungeert en er 1000 unieke waarden zijn, worden UserID UserID 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). Door de partitiesleutel en de item-id te combineren, 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 best practices voor partitionering besproken en krijgt u een uitgebreid overzicht van hoe horizontaal schalen werkt in Azure Cosmos DB. Het is niet nodig om deze interne gegevens te begrijpen om uw partitiesleutel te selecteren, maar we hebben deze behandeld, zodat u meer inzicht hebt in hoe Azure Cosmos DB werkt.

Logische partities

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

Een logische partitie definieert ook het bereik van databasetransacties. U kunt items binnen een logische partitie bijwerken met behulp van een transactie met isolatie van momentopnamen. Wanneer nieuwe items worden toegevoegd aan een container, worden nieuwe logische partities transparant gemaakt door het systeem. 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 partitiesleutelkeuzes hebben een breed scala aan mogelijke waarden. In een container waarin alle items bijvoorbeeld een eigenschap bevatten, kunnen de gegevens binnen de logische partitie foodGroup Beef Products maximaal 20 GB groot zijn. Als u een partitiesleutel met een breed scala aan mogelijke waarden selecteert, zorgt u ervoor dat de container kan worden geschaald.

Fysieke partities

Een container wordt geschaald door gegevens en doorvoer over fysieke partities te verdelen. Intern worden een of meer logische partities aan één fysieke partitie toegesneden. Kleinere containers hebben doorgaans 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 worden ze volledig beheerd door Azure Cosmos DB.

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

  • Het aantal inrichtende 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 toe te kennen.

  • 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. Richt u bij het ontwikkelen van uw oplossingen niet op fysieke partities, omdat u deze niet kunt controleren. Richt u in plaats daarvan op uw partitiesleutels. Als u een partitiesleutel kiest die het doorvoerverbruik gelijkmatig verdeelt over logische partities, zorgt u ervoor dat het doorvoerverbruik over fysieke partities gelijkmatig wordt verdeeld.

Er is geen limiet voor het totale aantal fysieke partities in uw container. Naarmate uw inrichtende doorvoer of gegevensgrootte toeneemt, Azure Cosmos DB automatisch nieuwe fysieke partities maken 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 splitsing van een fysieke partitie maakt eenvoudig een nieuwe toewijzing van logische partities aan fysieke partities.

De doorvoer die voor een container is ingericht, wordt gelijkmatig verdeeld over fysieke partities. Een ontwerp voor een partitiesleutel die aanvragen niet gelijkmatig verdeelt, kan leiden tot te veel aanvragen die worden omgeleid naar een kleine subset van partities die 'hot' worden. Hotpartities leiden tot inefficiënt gebruik van inrichtende doorvoer, wat kan leiden tot snelheidsbeperking en hogere kosten.

U kunt de fysieke partities van uw container zien in Storage sectie van de blade Metrische gegevens van de Azure Portal:

Het aantal fysieke partities weergeven

In de bovenstaande schermopname heeft een container /foodGroup als de partitiesleutel. Elk van de drie balken in de grafiek vertegenwoordigt een fysieke partitie. In de afbeelding is het bereik van de partitiesleutel hetzelfde als een fysieke partitie. De geselecteerde fysieke partitie bevat de drie belangrijkste logische partities: Beef Products Vegetable and Vegetable Products , en Soups, Sauces, and Gravies .

Als u een doorvoer van 18.000 aanvraageenheden per seconde (RU/s) inrichten, kan elk van de drie fysieke partities 1/3 van de totale inrichtende doorvoer gebruiken. Binnen de geselecteerde fysieke partitie kunnen de logische partitiesleutels , en gezamenlijk de Beef Products Vegetable and Vegetable Products 6000 inrichtende RU/s van de fysieke Soups, Sauces, and Gravies partitie gebruiken. Omdat de inrichtende doorvoer gelijkmatig wordt verdeeld over de fysieke partities van uw container, is het belangrijk om een partitiesleutel te kiezen die het doorvoerverbruik gelijkmatig verdeelt door de juiste logische partitiesleutel te kiezen.

Logische partities beheren

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

Azure Cosmos DB maakt gebruik van hash-partitionering om logische partities over fysieke partities te verdelen. Azure Cosmos DB hasht de partitiesleutelwaarde van een item. Het gehashte resultaat bepaalt de fysieke partitie. Vervolgens wijst Azure Cosmos DB de sleutelruimte van partitiesleutelhashes gelijkmatig toe over 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 replicaset host een exemplaar van de database-engine. Een replicaset maakt de gegevens die zijn opgeslagen in de fysieke partitie duurzaam, zeer beschikbaar en consistent. Elke replica die de fysieke partitie maakt, 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.

Normaal gesproken hebben kleinere containers slechts één fysieke partitie nodig, maar ze hebben nog steeds ten minste 4 replica's.

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

Een afbeelding die het partitioneren Azure Cosmos DB gedemonstreerd

Een partitiesleutel kiezen

Een partitiesleutel heeft twee onderdelen: partitiesleutelpad en de partitiesleutelwaarde. Neem bijvoorbeeld een item { "userId" : "Andrew", "worksFor": "Microsoft" } als u "userId" als partitiesleutel kiest, zijn de volgende 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 partitiesleutelwaarde kan tekenreeks- of numerieke typen zijn.

Zie het artikel Azure Cosmos DB servicequota 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. Zodra u de partitiesleutel hebt geselecteerd, is het niet mogelijk om deze ter plaatsen te wijzigen. Als u de partitiesleutel wilt wijzigen, moet u uw gegevens verplaatsen naar een nieuwe container met de nieuwe gewenste partitiesleutel.

Voor alle containers moet uw partitiesleutel het volgende doen:

  • Een eigenschap zijn die een waarde heeft die niet verandert. Als een eigenschap uw partitiesleutel is, kunt u de waarde van die eigenschap niet bijwerken.

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

  • Ru-verbruik (aanvraageenheid) en gegevensopslag gelijkmatig verdelen over alle logische partities. Dit zorgt voor zelfs RU-verbruik en opslagdistributie over uw fysieke partities.

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 beperkt tot één logische partitie.

Partitiesleutels voor leeszware containers

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

Als de meeste aanvragen van uw workload query's zijn en de meeste van uw query's een gelijkheidsfilter hebben op dezelfde eigenschap, kan deze eigenschap een goede keuze zijn voor de partitiesleutel. Als u bijvoorbeeld vaak een query uitvoert die filtert op , vermindert het aantal partitiequery's als u als partitiesleutel UserID UserID selecteert.

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

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

  • Uw container heeft meer dan 30.000 RU's ingericht

  • In uw container wordt meer dan 100 GB aan gegevens opgeslagen

Item-id gebruiken als partitiesleutel

Als uw container een eigenschap heeft met een breed scala aan mogelijke waarden, is het waarschijnlijk een goede keuze voor een partitiesleutel. Een mogelijk voorbeeld van een dergelijke eigenschap is de item-id. Voor kleine lees-/schrijfcontainers van elke grootte is de item-id van nature een goede keuze voor de partitiesleutel.

De item-id van de systeem-eigenschap bestaat in elk item in uw container. Mogelijk hebt u andere eigenschappen die een logische id van uw item vertegenwoordigen. In veel gevallen zijn dit ook goede partitiesleutelkeuzes om dezelfde redenen als de item-id.

De item-id is om de volgende redenen een goede keuze voor een partitiesleutel:

  • Er is een breed scala aan mogelijke waarden (één unieke item-id per item).
  • Omdat er een unieke item-id per item is, is de item-id zeer goed in het gelijkmatig in balans brengen van RU-verbruik en gegevensopslag.
  • U kunt eenvoudig efficiënte puntlezen doen, omdat u altijd de partitiesleutel van een item kent als u de item-id kent.

Enkele dingen om rekening mee te houden bij het selecteren van de item-id als de partitiesleutel zijn onder andere:

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

Volgende stappen