Vanliga frågor och svar om hierarkiska partitionsnycklar i Azure Cosmos DB

  • Vanliga frågor

GÄLLER FÖR: NoSQL MongoDB Kassandra Gremlin Bord

Med hierarkiska partitionsnycklar, eller underpartitonering, kan du konfigurera upp till en hierarki på tre nivåer för dina partitionsnycklar för att ytterligare optimera datadistributionen och aktivera högre skalning. Den här artikeln besvarar vanliga frågor om hierarkiska partitionsnycklar i Azure Cosmos DB.

Kan jag lägga till hierarkiska partitionsnycklar i befintliga containrar?

Det går inte att lägga till hierarkiska partitionsnycklar i befintliga containrar. Du kan dock skapa en ny container med önskad hierarkisk partitionsnyckel och köra ett containerkopieringsjobb för att kopiera data från din befintliga container till den nya. Mer information om hur du kopierar data finns i containerkopieringsjobb.

Finns det en lagringsgräns för storleken på en logisk partitionsnyckel?

Ja. Precis som i Azure Cosmos DB idag är den logiska partitionsstorleken fortfarande begränsad till 20 GB. Men med hierarkiska partitionsnycklar är den logiska partitionen nu hela sökvägen till partitionsnyckeln. Om du till exempel partitionerade med TenantId –> UserId skulle ett exempel på en logisk partition vara Contoso_Alice. Om du använder underpartitionering kan du ha 20 GB data där partitionsnyckelvärdet är Contoso_Alice. Mängden lagringsutrymme som tillåts för data i "Contoso" är i praktiken 20 GB * antal unika UserId:er för klientorganisationen "Contoso".

Finns det några ändringar i lagrings- och RU/s-gränserna för fysiska partitioner?

Nej. Precis som i Azure Cosmos DB idag kan en fysisk partition innehålla 50 GB lagringsutrymme och hantera upp till 10 000 RU/s. Men med hierarkiska partitionsnycklar innebär underpartitionering att det totala antalet RU/s som kan uppnås för ett enda TenantId kan överstiga 10 000 RU/s om data för ett visst partitionsnyckelprefix, till exempel TenantId, finns i flera fysiska partitioner.

Vad händer om jag frågar och bara anger en partitionsnyckel i "mitten" av sökvägen?

Frågan är en fråga mellan partitioner. Om du till exempel partitioneras efter TenantId –> UserId och endast anger UserId i frågan, kommer den här frågan att skickas till alla fysiska partitioner.

Om du vill ha en effektivt dirigerad fråga med hjälp av exemplet TenantId –> UserId finns det två alternativ:

  • Ange TenantId. Frågor går till alla fysiska partitioner som innehåller TenantId-data.
  • Ange både TenantId och UserId. Frågor går till den enda fysiska partitionen som innehåller TenantId och det specifika UserId.

Måste jag skapa en ny egenskap i mina dokument för att kunna använda den här funktionen?

Nej. Ange hierarkin för de partitionsnyckelsökvägar som du vill använda när containern skapas. Om du till exempel partitioneras efter TenantId –> UserId behöver du inte skapa en ny egenskap med dessa värden sammanfogade. Kontrollera att varje dokument har egenskapen TenantId och egenskapen UserId. Mer information finns i underpartitionering av kodexempel.

Jag skapade en hierarki med nycklar som inte har mycket kardinalitet. Vad ska jag göra?

Du kanske befinner dig i ett scenario där din arbetsbelastning bara når några fysiska partitioner av alla dina partitioner. Det här scenariot kan innebära att en eller flera nivåer av din hierarkiska partitionsnyckel har låg kardinalitet. För att felsöka scenariot rekommenderar vi alltid att du återskapar din hierarkiska partitionsnyckel och du kan använda DTS för att ändra din nyckel och kopiera över containerns data till den nya containern. Om det här steget inte är möjligt finns det två lösningar som vi föreslår för att säkerställa en enhetlig distribution av dina data

  • Metod 1:
  1. Du kan skapa en container med mindre än 10 000 RU:er för att se till att du bara har en fysisk partition.
  2. Mata in cirka 5 GB data för att säkerställa att det inte finns några partitionsdelningar.
  3. Skala upp till önskade RU:er, fortsätt att mata in data och Azure Cosmos DB ser till att dina fysiska partitioner delas jämnt.
  • Metod 2:
  1. Du kan öka ditt totala erbjudande till ett högre antal RU:er och mata in alla dina data.
  2. Utför sedan partitionssammanslagning för att säkerställa att arbetsbelastningens partitioner inte är fragmenterade och har en jämn distribution
  3. När sammanfogningen är klar skalar du ned till det ursprungliga önskade antalet RU:er.

Om du vill ha mer kontroll över hur mycket dataflöde varje partition har kan du också använda omdistribution av dataflöde för att säkerställa att de partitioner som din arbetsbelastning använder har tillräckligt med RU:er för dina framtida begäranden.

Nästa steg