Poznámka:
Přístup k této stránce vyžaduje autorizaci. Můžete se zkusit přihlásit nebo změnit adresáře.
Přístup k této stránce vyžaduje autorizaci. Můžete zkusit změnit adresáře.
PLATÍ PRO: NoSQL
Azure Cosmos DB distribuuje vaše data mezi logické a fyzické oddíly na základě klíčů oddílů, aby podporovala horizontální škálování. Pomocí hierarchických klíčů oddílů (označovaných také jako dílčí dělení) můžete pro klíče oddílů nakonfigurovat až tříúrovňovou hierarchii, abyste mohli dále optimalizovat distribuci dat a vyšší úroveň škálování.
Pokud dnes používáte syntetické klíče, máte scénáře, ve kterých klíče oddílů můžou překročit 20 GB dat, nebo byste chtěli zajistit, aby se dokument každého tenanta mapoval na vlastní logický oddíl, může pomoct dílčí dělení. Pokud použijete tuto funkci, předpony logického klíče oddílu mohou překročit 20 GB a 10 000 jednotek žádostí za sekundu (RU/s). Dotazy podle předpony se efektivně směrují na podmnožinu oddílů, které obsahují data.
Zvolte své hierarchické klíče oddílů
Pokud máte víceklientské aplikace a aktuálně izolujete klienty podle klíče oddílu, mohou být pro vás užitečné hierarchické oddíly. Hierarchické oddíly umožňují škálovat nad rámec limitu logického klíče oddílu 20 GB a jsou dobrým řešením, pokud chcete zajistit, aby se dokumenty jednotlivých tenantů mohly škálovat neomezeně. Pokud váš aktuální klíč oddílu nebo pokud jeden klíč oddílu často dosahuje 20 GB, jsou hierarchické oddíly pro vaši úlohu skvělou volbou.
V závislosti na povaze vaší pracovní zátěže a na tom, jak zásadní je váš klíč na první úrovni, mohou však existovat určité kompromisy, které podrobně rozebíráme na stránce s hierarchickými scénáři rozdělení.
Když zvolíte každou úroveň hierarchického klíče oddílu, je důležité mít na paměti následující obecné koncepty dělení a porozumět tomu, jak každý z nich může ovlivnit vaše úlohy:
Pro všechny kontejnery by každá úroveň úplné cesty (počínaje první úrovní) vašeho hierarchického klíče oddílů měla:
Mají vysokou kardinalitu. První, druhý a třetí klíč hierarchického oddílu by měl mít širokou škálu možných hodnot, pokud je to relevantní.
- Mít nízkou kardinalitu na první úrovni hierarchického klíče partitionu omezuje vaše operace zápisu při přijímání dat na jeden fyzický oddíl, dokud tento oddíl nedosáhne 50 GB a nerozdělí se na dva fyzické oddíly. Předpokládejme například, že váš klíč první úrovně je na
TenantIda máte pouze pět jedinečných tenantů. Všechny operace těchto tenantů jsou omezené jenom na jeden fyzický oddíl, což omezuje spotřebu propustnosti jenom na to, co je v daném fyzickém oddílu. Důvodem je, že hierarchické oddíly optimalizují umístění všech dokumentů se stejným klíčem první úrovně, aby byly umístěny na stejném fyzickém oddílu a předešlo se dotazům s plným rozšířením. - I když to může být v pořádku pro úlohy, kdy jednorázově načteme všechna data našich tenantů a následující operace jsou především orientovány na čtení, může to být nevhodné pro úlohy, kde vaše obchodní požadavky vyžadují příjem dat v rámci určitého časového okna. Například pokud máte přísné obchodní požadavky k zamezení latencí, maximální propustnost, které může vaše úloha teoreticky dosáhnout pro ingestování dat, je počet fyzických oddílů × 10 tisíc. Pokud má klíč nejvyšší úrovně nízkou kardinalitu, je pravděpodobné, že počet fyzických oddílů je 1, pokud není dostatek dat pro klíč úrovně 1 na to, aby se po rozdělení rozložil mezi více oddílů, což může trvat 4 až 6 hodin.
- Mít nízkou kardinalitu na první úrovni hierarchického klíče partitionu omezuje vaše operace zápisu při přijímání dat na jeden fyzický oddíl, dokud tento oddíl nedosáhne 50 GB a nerozdělí se na dva fyzické oddíly. Předpokládejme například, že váš klíč první úrovně je na
Rovnoměrně rozprostřete spotřebu RU a úložiště dat napříč všemi logickými oddíly. Toto rozložení zajišťuje rovnoměrnou spotřebu RU a distribuci úložiště napříč fyzickými oddíly.
- Pokud zvolíte klíč první úrovně, který vypadá jako vysoká kardinalita
UserId, ale v praxi vaše úloha provádí operace pouze na jednom konkrétnímUserIdoddílu, pak pravděpodobně narazíte na horký oddíl, protože všechny operace jsou vymezeny pouze na jeden nebo několik fyzických oddílů.
- Pokud zvolíte klíč první úrovně, který vypadá jako vysoká kardinalita
Úlohy náročné na čtení: Doporučujeme zvolit hierarchické klíče oddílů, které se často zobrazují v dotazech.
- Například úloha, která často spouští dotazy, jež vyfiltrují konkrétní uživatelské relace ve víceklientských aplikacích, může těžit z hierarchických klíčů oddílů
TenantId,UserIdaSessionIdv uvedeném pořadí. Dotazy lze efektivně směrovat pouze na relevantní fyzické oddíly zahrnutím klíče oddílu do predikátu filtru. Další informace o výběru oddílových klíčů pro úlohy náročné na čtení najdete v přehledu dělení.
- Například úloha, která často spouští dotazy, jež vyfiltrují konkrétní uživatelské relace ve víceklientských aplikacích, může těžit z hierarchických klíčů oddílů
Úlohy náročné na zápis: Pro první úroveň vašeho hierarchického klíče oddílu doporučujeme použít vysokou kardinalitu. Vysoká kardinalita znamená, že klíč první úrovně (a také klíče dalších úrovní) má alespoň tisíce jedinečných hodnot a více jedinečných hodnot, než kolik je vašich fyzických oddílů.
Předpokládejme například, že máme úlohu, která izoluje tenanty podle klíče oddílu a má několik velkých tenantů, které jsou náročnější na zápis než jiné. Dnes Azure Cosmos DB přestane přijímat data na libovolnou hodnotu klíče oddílu, pokud překročí 20 GB dat. V tomto pracovním zatížení jsou společnosti Microsoft a Contoso velkými nájemci a předpokládáme, že porostou mnohem rychleji než naši ostatní nájemci. Aby se zabránilo riziku, že nebude možné načít data pro tyto tenanty, hierarchické klíče pro oddíly nám umožňují rozšířit tyto tenanty nad rámec limitu 20 GB. Můžeme přidat další úrovně jako
UserIdaSessionIdpro zajištění vyšší škálovatelnosti napříč tenanty.Pokud chcete zajistit, aby vaše úloha vyhovovala zápisům pro všechny dokumenty se stejným klíčem první úrovně, zvažte použití ID položky jako klíče druhé nebo třetí úrovně.
Pokud vaše první úroveň nemá vysokou kardinalitu a dosáhnete limitu 20 GB logického oddílu u klíče oddílu ještě dnes, doporučujeme místo hierarchického klíče oddílu použít syntetický klíč oddílu.
Příklad případu použití
Předpokládejme, že máte scénář s více tenanty, ve kterém ukládáte informace o událostech pro uživatele v každém tenantovi. Informace o akcích mohou zahrnovat věci jako přihlášení, clickstream nebo platební události.
V reálném scénáři můžou někteří tenanti růst s tisíci uživatelů, zatímco mnoho dalších tenantů je menší a má několik uživatelů. Dělení podle /TenantId může vést k překročení limitu úložiště Azure Cosmos DB 20 GB na jednom logickém oddílu. Rozdělení pomocí /UserId způsobí, že všechny dotazy na nájemci procházejí mezi oddíly. Oba přístupy mají významné nevýhody.
Použití syntetického klíče oddílu, který kombinuje TenantId a UserId, přidává aplikaci složitost. Dotazy na syntetické klíče oddílu pro tenanta jsou navíc stále rozdělené mezi oddíly, pokud nejsou všichni uživatelé známi a nezadávají se předem.
Pokud má vaše výpočetní zátěž tenanty s přibližně stejnými vzory, hierarchický klíč pro dělení může pomoci. Pomocí hierarchických klíčů oddílů můžete nejprve rozdělit oddíl na TenantIda pak na UserId. Pokud očekáváte, že TenantId a UserId kombinace vytvoří oddíly, které překračují 20 GB, můžete dokonce dále rozdělit na jinou úroveň, například na SessionId. Celková hloubka nesmí překročit tři úrovně. Když fyzický oddíl překročí 50 GB úložiště, Azure Cosmos DB automaticky rozdělí fyzický oddíl tak, aby přibližně polovina dat byla na jednom fyzickém oddílu a polovina je na druhém. V podstatě subpartitioning znamená, že jedna TenantId hodnota může překročit 20 GB dat a je možné, aby TenantId data byla rozložena přes více fyzických oddílů.
Dotazy, které specifikují buď TenantId, nebo obě TenantId a UserId, jsou efektivně směrovány pouze na tu podmnožinu fyzických oddílů, které obsahují relevantní data. Zadáním úplné nebo předponové cesty klíče podrozděleného oddílu se účinně vyhnete úplnému fan-out dotazu. Pokud by například kontejner měl 1 000 fyzických oddílů, ale konkrétní TenantId hodnota byla pouze na pěti fyzických oddílech, dotaz by se směroval na menší počet relevantních fyzických oddílů.
Použití ID položky v hierarchii
Pokud má váš kontejner vlastnost s velkým rozsahem možných hodnot, je pravděpodobně skvělou volbou jako klíč oddílu pro nejspodnější úroveň vaší hierarchie. Jedním z možných příkladů tohoto typu vlastnosti je ID položky. ID systémové vlastnosti existuje u každé položky v kontejneru. Přidání ID položky jako další úrovně zaručuje, že můžete provádět škálování nad rámec limitu klíče logické partition ve velikosti 20 GB. Můžete škálovat nad rámec tohoto limitu pro první úroveň nebo pro první a druhou úroveň klíčů.
Můžete mít například kontejner pro víceklientskou úlohu rozdělenou podle TenantId a UserId. Pokud je možné, aby jedna kombinace TenantId a UserId překročila 20 GB, doporučujeme rozčlenit pomocí tří úrovní klíčů, přičemž klíč třetí úrovně má vysokou kardinalitu. Příkladem tohoto scénáře je, když klíč třetí úrovně je GUID, který má přirozeně vysokou kardinalitu. Je nepravděpodobné, že kombinace TenantId, UserId a GUID překračuje 20 GB, takže kombinace TenantId a UserId může efektivně škálovat nad 20 GB.
Další informace o použití ID položky jako klíče oddílu najdete v přehledu particionování.
Začínáme
Důležité
Práce s kontejnery, které používají hierarchické klíče oddílů, je podporována pouze v následujících verzích sady SDK. Podporovanou sadu SDK musíte použít k vytvoření nových kontejnerů s hierarchickými klíči oddílu a k provádění operací vytváření, čtení, aktualizace a odstraňování (CRUD) nebo dotazování na data. Pokud chcete použít sadu SDK nebo konektor, který se v současné době nepodporuje, vytvořte žádost na našem komunitním fóru.
Vyhledejte nejnovější verzi Preview každé podporované sady SDK:
| sada SDK | Podporované verze | Odkaz správce balíčků |
|---|---|---|
| .NET SDK v3 | >= 3,33,0 | https://www.nuget.org/packages/Microsoft.Azure.Cosmos/3.33.0/ |
| Sada Java SDK v4 | >= 4,42,0 | https://github.com/Azure/azure-sdk-for-java/blob/main/sdk/cosmos/azure-cosmos/CHANGELOG.md#4420-2023-03-17/ |
| JavaScript SDK v4 | 4.0.0 | https://www.npmjs.com/package/@azure/cosmos/ |
| Python SDK | >= 4.6.0 | https://pypi.org/project/azure-cosmos/4.6.0/ |
Vytvoření kontejneru pomocí hierarchických klíčů pro oddíly
Začněte vytvořením nového kontejneru pomocí předdefinovaného seznamu klíčových cest pododdílů až do tří úrovní hloubky.
Nový kontejner můžete vytvořit pomocí jedné z těchto možností:
- Azure Portal
- sada SDK
- Šablona Azure Resource Manageru
- Emulátor služby Azure Cosmos DB
Azure Portal
Nejjednodušší způsob, jak vytvořit kontejner a zadat hierarchické klíče oddílů, je použití webu Azure Portal.
Přihlaste se k portálu Azure.
Přejděte na existující stránku účtu Azure Cosmos DB for NoSQL.
V nabídce vlevo vyberte Průzkumník dat.
Ve Průzkumníku dat vyberte možnost Nový kontejner.
V novém kontejneru zadejte hodnotu pro klíč oddílu,
/TenantId. U zbývajících polí zadejte libovolnou hodnotu, která odpovídá vašemu scénáři.Poznámka:
Jako příklad zde použijeme
/TenantId. Při implementaci hierarchických klíčů oddílů do vlastních kontejnerů můžete zadat libovolný klíč pro první úroveň.Dvakrát vyberte Přidat hierarchický klíč oddílu.
Pro druhou a třetí úroveň dílčího dělení zadejte
/UserIda/SessionIdv uvedeném pořadí.Tlačítkem OK vytvořte kontejner.
sada SDK
Při vytváření nového kontejneru pomocí sady SDK definujte seznam cest klíčů dílčích oddílů až do tří úrovní hloubky. Seznam klíčů dílčích oddílů použijte při konfiguraci vlastností nového kontejneru.
// List of partition keys, in hierarchical order. You can have up to three levels of keys.
List<string> subpartitionKeyPaths = new List<string> {
"/TenantId",
"/UserId",
"/SessionId"
};
// Create a container properties object
ContainerProperties containerProperties = new ContainerProperties(
id: "<container-name>",
partitionKeyPaths: subpartitionKeyPaths
);
// Create a container that's subpartitioned by TenantId > UserId > SessionId
Container container = await database.CreateContainerIfNotExistsAsync(containerProperties, throughput: 400);
Šablony Azure Resource Manageru
Šablona Azure Resource Manageru pro kontejner s dílčími oddíly je téměř identická se standardním kontejnerem. Jediným klíčovým rozdílem je hodnota properties/partitionKey cesty. Další informace o vytvoření šablony Azure Resource Manageru pro prostředek Azure Cosmos DB najdete v referenčních informacích k šabloně Azure Resource Manageru pro službu Azure Cosmos DB.
partitionKey Nakonfigurujte objekt pomocí hodnot v následující tabulce a vytvořte tak kontejner s dílčími oddíly:
| Cesta | Hodnota |
|---|---|
paths |
Seznam hierarchických klíčů oddílů (maximálně tři úrovně) |
kind |
MultiHash |
version |
2 |
Příklad definice klíče oddílu
Předpokládejme například, že máte hierarchický klíč oddílu, který se skládá z TenantId>UserId>SessionId. Objekt partitionKey by byl nakonfigurován tak, aby zahrnoval všechny tři hodnoty ve paths vlastnosti, kind hodnotu MultiHasha version hodnotu 2.
partitionKey: {
paths: [
'/TenantId'
'/UserId'
'/SessionId'
]
kind: 'MultiHash'
version: 2
}
Další informace o objektu partitionKey naleznete ve specifikaci ContainerPartitionKey.
Emulátor služby Azure Cosmos DB
Funkci dílčího dělení můžete otestovat pomocí nejnovější verze místního emulátoru služby Azure Cosmos DB. Pokud chcete povolit podparticionování v emulátoru, spusťte emulátor z instalačního adresáře s příznakem /EnablePreview.
.\CosmosDB.Emulator.exe /EnablePreview
Varování
Emulátor v současné době nepodporuje všechny funkce hierarchického klíče oddílu, jako portál. Emulátor v současné době nepodporuje:
- Použití nástroje Data Explorer k vytvoření kontejnerů s hierarchickými klíči pro rozdělení dat
- Použití Průzkumníka dat k přechodu na položky a interakci s nimi pomocí hierarchických klíčů oddílů
Další informace najdete v tématu Emulátor služby Azure Cosmos DB.
Použijte SDK k práci s kontejnery, které mají hierarchické klíče oddílů
Pokud máte kontejner s hierarchickými klíči oddílů, použijte dříve zadané verze sad .NET nebo Java SDK k provedení operací a spuštění dotazů na tomto kontejneru.
Přidání položky do kontejneru
Existují dvě možnosti přidání nové položky do kontejneru s povolenými hierarchickými klíči oddílů:
- Automatická extrakce
- Ruční zadání cesty
Automatická extrakce
Pokud předáte objekt se sadou hodnot klíče oddílu, sada SDK může automaticky extrahovat úplnou cestu klíče oddílu.
// Create a new item
UserSession item = new UserSession()
{
id = "f7da01b0-090b-41d2-8416-dacae09fbb4a",
TenantId = "Microsoft",
UserId = "00aa00aa-bb11-cc22-dd33-44ee44ee44ee",
SessionId = "0000-11-0000-1111"
};
// Pass in the object, and the SDK automatically extracts the full partition key path
ItemResponse<UserSession> createResponse = await container.CreateItemAsync(item);
Ruční zadání cesty
Třída PartitionKeyBuilder v sadě SDK může vytvořit hodnotu pro dříve definovanou hierarchickou cestu klíče oddílu. Tuto třídu použijte, když přidáte novou položku do kontejneru, který má povolenou dílčí dělení.
Návod
Ve velkém měřítku může být výkon zlepšen tím, že zadáte úplnou cestu klíče oddílu, i když SDK může cestu extrahovat z objektu.
// Create a new item object
PaymentEvent item = new PaymentEvent()
{
id = Guid.NewGuid().ToString(),
TenantId = "Microsoft",
UserId = "00aa00aa-bb11-cc22-dd33-44ee44ee44ee",
SessionId = "0000-11-0000-1111"
};
// Specify the full partition key path when creating the item
PartitionKey partitionKey = new PartitionKeyBuilder()
.Add(item.TenantId)
.Add(item.UserId)
.Add(item.SessionId)
.Build();
// Create the item in the container
ItemResponse<PaymentEvent> createResponse = await container.CreateItemAsync(item, partitionKey);
Vyhledání položky pomocí klíče/hodnoty (přímé čtení)
Vyhledávání klíč/hodnota (čtení bodů) se provádí způsobem, který se podobá kontejneru, který není součástí oddílu. Předpokládejme například, že máte hierarchický klíč oddílu, který se skládá z TenantId>UserId>SessionId. Jedinečný identifikátor položky je identifikátor GUID. Představuje se jako řetězec, který slouží jako jedinečný identifikátor transakce dokumentu. Chcete-li provést čtení bodu u jedné položky, předejte id vlastnost položky a úplnou hodnotu klíče oddílu, včetně všech tří součástí cesty.
// Store the unique identifier
string id = "f7da01b0-090b-41d2-8416-dacae09fbb4a";
// Build the full partition key path
PartitionKey partitionKey = new PartitionKeyBuilder()
.Add("Microsoft") //TenantId
.Add("00aa00aa-bb11-cc22-dd33-44ee44ee44ee") //UserId
.Add("0000-11-0000-1111") //SessionId
.Build();
// Perform a point read
ItemResponse<UserSession> readResponse = await container.ReadItemAsync<UserSession>(
id,
partitionKey
);
Spuštění dotazu
SDK kód, který používáte ke spuštění dotazu v kontejneru s pododdíly, je stejný jako při spuštění dotazu v kontejneru bez pododdílů.
Když dotaz určuje všechny hodnoty klíčů oddílů ve WHERE filtru nebo v předponě hierarchie klíčů, sada SDK automaticky směruje dotaz do odpovídajících fyzických oddílů. Dotazy, které poskytují pouze "prostřední" část hierarchie, jsou dotazy, které operují napříč oddíly.
Představte si například hierarchický klíč oddílu, který se skládá z TenantId>UserId>SessionId. Komponenty filtru dotazu určují, zda se jedná o dotaz v rámci jednoho oddílu, cílený dotaz napříč oddíly nebo dotaz rozšířený na více oddílů.
| Dotaz | Směrování |
|---|---|
SELECT * FROM c WHERE c.TenantId = 'Microsoft' AND c.UserId = '00aa00aa-bb11-cc22-dd33-44ee44ee44ee' AND c.SessionId = '0000-11-0000-1111' |
Směrováno do jednoho logického a fyzického oddílu, který obsahuje data pro zadané hodnoty , TenantIdUserIda SessionId. |
SELECT * FROM c WHERE c.TenantId = 'Microsoft' AND c.UserId = '00aa00aa-bb11-cc22-dd33-44ee44ee44ee' |
Směrováno pouze na cílovou podmnožinu logických a fyzických oddílů , které obsahují data pro zadané hodnoty TenantId a UserId. Tento dotaz je cílený dotaz napříč oddíly, který vrací data pro konkrétního uživatele v nájemci. |
SELECT * FROM c WHERE c.TenantId = 'Microsoft' |
Směrováno pouze na cílenou podmnožinu logických a fyzických oddílů, které obsahují data pro zadanou hodnotu TenantId. Tento dotaz je cílový dotaz napříč oddíly, který vrací data pro všechny uživatele v tenantovi. |
SELECT * FROM c WHERE c.UserId = '00aa00aa-bb11-cc22-dd33-44ee44ee44ee' |
Směrováno na všechny fyzické oddíly, což vede k rozšířenému dotazu přes oddíly. |
SELECT * FROM c WHERE c.SessionId = '0000-11-0000-1111' |
Směrováno na všechny fyzické oddíly, což vede k rozšířenému dotazu přes oddíly. |
Dotaz na jeden oddíl v podrozděleném kontejneru
Tady je příklad spuštění dotazu, který zahrnuje všechny úrovně dílčích oddílů, čímž se dotaz efektivně vytvoří jako dotaz s jedním oddílem.
// Define a single-partition query that specifies the full partition key path
QueryDefinition query = new QueryDefinition(
"SELECT * FROM c WHERE c.TenantId = @tenant-id AND c.UserId = @user-id AND c.SessionId = @session-id")
.WithParameter("@tenant-id", "Microsoft")
.WithParameter("@user-id", "00aa00aa-bb11-cc22-dd33-44ee44ee44ee")
.WithParameter("@session-id", "0000-11-0000-1111");
// Retrieve an iterator for the result set
using FeedIterator<PaymentEvent> results = container.GetItemQueryIterator<PaymentEvent>(query);
while (results.HasMoreResults)
{
FeedResponse<UserSession> resultsPage = await resultSet.ReadNextAsync();
foreach(UserSession result in resultsPage)
{
// Process result
}
}
Cílený dotaz na více oddílů v kontejneru s pododdíly
Tady je příklad dotazu, který obsahuje podmnožinu úrovní dílčího oddílení, účinně činí tento dotaz cíleným víceparciovým dotazem.
// Define a targeted cross-partition query specifying prefix path[s]
QueryDefinition query = new QueryDefinition(
"SELECT * FROM c WHERE c.TenantId = @tenant-id")
.WithParameter("@tenant-id", "Microsoft")
// Retrieve an iterator for the result set
using FeedIterator<PaymentEvent> results = container.GetItemQueryIterator<PaymentEvent>(query);
while (results.HasMoreResults)
{
FeedResponse<UserSession> resultsPage = await resultSet.ReadNextAsync();
foreach(UserSession result in resultsPage)
{
// Process result
}
}
Omezení a známé problémy
- Práce s kontejnery, které používají hierarchické klíče oddílů, se podporuje pouze v sadě .NET v3 SDK, v sadě Java SDK v4, v sadě Python SDK a ve verzi Preview sady JavaScript SDK. K vytvoření nových kontejnerů s hierarchickými klíči oddílů a provádění operací CRUD nebo dotazování na data musíte použít podporovanou sadu SDK. Podpora jiných sad SDK, včetně Pythonu, není momentálně dostupná.
- Existují omezení různých konektorů služby Azure Cosmos DB (například u služby Azure Data Factory).
- Hierarchické klíče oddílů můžete zadat pouze až do tří úrovní hloubky.
- Hierarchické klíče oddílů je v současné době možné povolit jenom u nových kontejnerů. Cesty ke klíči oddílu musíte nastavit při vytváření kontejneru a později je nemůžete změnit. Pokud chcete pro existující kontejnery používat hierarchické oddíly, vytvořte nový kontejner s nastavenými hierarchickými klíči oddílu a přesuňte data pomocí úloh kopírování kontejneru.
- Hierarchické klíče oddílů jsou v současné době podporovány pouze pro účty API pro NoSQL. Rozhraní API pro MongoDB a Cassandra nejsou v současné době podporována.
- U uživatelů a oprávnění se v současné době nepodporují hierarchické klíče oddílů. Nemůžete přiřadit oprávnění k částečné předponě hierarchického klíče oddílu. Oprávnění je možné přiřadit pouze k celé logické cestě klíče oddílu. Pokud jste například rozdělili oddíly
TenantIdpodle – >UserId, nemůžete přiřadit oprávnění, která je určena pro určitou hodnotuTenantId. Můžete však přiřadit oprávnění pro klíč oddílu, pokud zadáte hodnotu proTenantIdiUserId.