Partager via

Clés de partition hiérarchiques dans Azure Cosmos DB

  • Article

S’APPLIQUE À : NoSQL

Azure Cosmos DB distribue vos données sur des partitions logiques et physiques en fonction de vos clés de partition pour prendre en charge la mise à l’échelle horizontale. À l’aide des clés de partition hiérarchique (également appelées sous-partitionnement, vous pouvez configurer jusqu’à trois niveaux de hiérarchie pour vos clés de partition afin d’optimiser la distribution des données et de permettre une mise à l’échelle plus élevée.

Si vous utilisez des clés synthétiques aujourd’hui, avez des scénarios dans lesquels les clés de partition peuvent dépasser 20 Go de données ou souhaitez vous assurer que le document de chaque locataire est mappé à sa propre partition logique, le sous-partitionnement peut vous aider. Si vous utilisez cette fonctionnalité, les préfixes des clés de partition logique peuvent dépasser 20 Go et 10 000 unités de requête par seconde (RU/s). Les requêtes par préfixe sont acheminées efficacement vers le sous-ensemble de partitions qui contiennent les données.

Choisir vos clés de partition hiérarchique

Si vous avez des applications multilocataires et que vous isolez actuellement des locataires par clé de partition, vous pouvez tirer parti des partitions hiérarchiques. Les partitions hiérarchiques vous permettent d’effectuer une mise à l’échelle au-delà de la limite de clé de partition logique de 20 Go et constituent une bonne solution si vous souhaitez vous assurer que chacun des documents de vos locataires peut être mis à l’échelle infiniment. Si votre clé de partition actuelle ou une clé de partition unique atteint fréquemment 20 Go, les partitions hiérarchiques sont un excellent choix pour votre charge de travail.

Toutefois, en fonction de la nature de votre charge de travail et de la cardinalité de votre clé de premier niveau, il peut y avoir des compromis que nous abordons dans notre page de scénarios de partition hiérarchique.

Lorsque vous choisissez chaque niveau de votre clé de partition hiérarchique, il est important de garder à l’esprit les concepts de partitionnement généraux suivants et de comprendre comment chacun d’eux peut affecter votre charge de travail :

  • Pour tous les conteneurs, chaque niveau du chemin complet (débutant au tout premier niveau) de votre clé de partition hiérarchique doit :

    • Avoir une cardinalité élevée. Les première, deuxième et (éventuellement) troisième clés de la partition hiérarchique doivent toutes offrir une plage de valeurs possibles étendue.

      • Une faible cardinalité au premier niveau de la clé de partition hiérarchique limite toutes vos opérations d’écriture au moment de l’ingestion à une seule partition physique jusqu’à ce qu’elle atteigne 50 Go et se divise en deux partitions physiques. Par exemple, supposons que votre clé de premier niveau soit sur TenantId et ne dispose que de 5 locataires uniques. Les opérations de chacun de ces locataires seront limitées à une seule partition physique, ce qui limite votre consommation de débit uniquement à ce qui se trouve sur cette partition physique. Cela est dû à l’optimisation des partitions hiérarchiques pour tous les documents avec la même clé de premier niveau pour être colocalisés sur la même partition physique afin d’éviter les requêtes de distribution ramifiée complète.
      • Bien que cela puisse convenir aux charges de travail où nous effectuons une ingestion ponctuelle de toutes les données de nos locataires et que les opérations suivantes sont principalement lourdes en lecture par la suite, cela peut être difficile pour les charges de travail où vos besoins métier impliquent l’ingestion de données dans un délai spécifique. Par exemple, si vous avez des exigences métier strictes pour éviter les latences, le débit maximal que votre charge de travail peut théoriquement atteindre pour ingérer des données est 10 000 fois le nombre de partitions physiques. Si votre clé de niveau supérieur a une faible cardinalité, vous aurez probablement 1 partition physique, sauf s’il existe suffisamment de données pour que la clé de niveau 1 soit répartie sur plusieurs partitions après les fractionnements, qui peuvent prendre entre 4 et 6 heures.

    • Répartir la consommation d’unités de requête (RU) et le stockage des données uniformément sur toutes les partitions logiques. Cette diffusion garantit une consommation de RU et une répartition du stockage uniformes sur vos partitions physiques.

      • Si vous choisissez une clé de premier niveau qui semble avoir une cardinalité élevée, comme UserId, mais que dans la pratique, votre charge de travail effectue des opérations sur un seul UserId, vous exécutez alors probablement une partition à chaud, car toutes vos opérations seront limitées à une partition physique, ou à quelques unes seulement.

  • Charges de travail lourdes en lecture : nous vous recommandons de choisir des clés de partition hiérarchique qui apparaissent fréquemment dans vos requêtes.

    • Par exemple, une charge de travail qui exécute fréquemment des requêtes pour filtrer des sessions spécifiques d’utilisateur dans une application multilocataire peut tirer parti des clés de partition hiérarchique TenantId, UserId et SessionId dans cet ordre. Les requêtes peuvent être efficacement acheminées uniquement vers les partitions physiques concernées en incluant la clé de partition dans le prédicat de filtre. Pour plus d’informations sur la sélection des clés de partition pour les charges de travail nécessitant beaucoup de lecture, consultez la vue d’ensemble du partitionnement.

  • Charges de travail lourdes en écriture : nous vous recommandons d’utiliser une valeur de cardinalité élevée pour le premier niveau de votre clé de partition hiérarchique. Une cardinalité élevée signifie que la clé de premier niveau (ainsi que les niveaux suivants) a au moins des milliers de valeurs uniques et plus de valeurs uniques que le nombre de vos partitions physiques.

    • Par exemple, supposons que nous avons une charge de travail qui isole les locataires par clé de partition avec quelques locataires volumineux qui sont plus lourds en écriture que d’autres. Aujourd’hui, Azure Cosmos DB cesse d’ingérer des données sur n’importe quelle valeur de clé de partition qui dépasse 20 Go de données. Dans cette charge de travail, Microsoft et Contoso sont des locataires volumineux et nous prévoyons qu’ils augmentent beaucoup plus rapidement que nos autres locataires. Pour éviter le risque de ne pas pouvoir ingérer des données pour ces locataires, les clés de partition hiérarchique nous permettent de mettre à l’échelle ces locataires au delà de la limite de 20 Go. Nous pouvons ajouter d’autres niveaux tels que UserId et SessionId pour garantir une scalabilité plus élevée entre les locataires.

    • Pour vous assurer que votre charge de travail peut prendre en charge les écritures pour tous les documents avec la même clé de premier niveau, envisagez d’utiliser l’ID d’élément comme clé de deuxième ou troisième niveau.

    • Si votre premier niveau n’a pas une cardinalité élevée et que vous atteignez la limite de partition logique de 20 Go sur votre clé de partition aujourd’hui, nous vous suggérons d’utiliser une clé de partition synthétique au lieu d’une clé de partition hiérarchique.

Exemple de cas d’usage

Imaginons un scénario multilocataire dans lequel vous stockez des informations sur les événements pour les utilisateurs de chaque locataire. Les informations sur les événements peuvent comporter des occurrences d’événement, notamment des événements de connexion, de parcours de visite ou de paiement.

Dans un scénario réel, la taille de certains locataires peut augmenter et compter des milliers d’utilisateurs, tandis que beaucoup de locataires sont plus petits avec quelques utilisateurs seulement. Le partitionnement par /TenantId peut entraîner un dépassement de la limite de stockage de 20 Go d’Azure Cosmos DB sur une seule partition logique. Le partitionnement par /UserId effectue toutes les requêtes sur une partition de locataire croisée. Ces deux approches présentent des inconvénients significatifs.

L’utilisation d’une clé de partition synthétique qui combine TenantId et UserId rend l’application plus complexe. En outre, les requêtes de clé de partition synthétique pour un locataire concernent plusieurs partitions, sauf si tous les utilisateurs sont connus et spécifiés à l’avance.

Si votre charge de travail comporte des locataires avec à peu près les mêmes modèles de charge de travail, une clé de partition hiérarchique peut vous aider. Avec les clés de partition hiérarchique, vous pouvez d’abord partitionner sur TenantId, puis sur UserId. Si vous vous attendez à ce que la combinaison TenantId et UserId produise des partitions qui dépassent 20 Go, vous pouvez même effectuer une partition plus loin vers un autre niveau, tel que SessionId. La profondeur globale ne peut pas dépasser trois niveaux. Quand une partition physique dépasse 50 Go de stockage, Azure Cosmos DB fractionne automatiquement la partition physique afin qu’environ la moitié des données se trouve sur une partition physique et l’autre moitié sur une autre. En fait, le sous-partitionnement signifie qu’une valeur TenantId unique peut dépasser 20 Go de données et que les données TenantId peuvent s’étendre sur plusieurs partitions physiques.

Les requêtes qui spécifient TenantId, ou à la fois TenantId et UserId sont acheminées efficacement vers le sous-ensemble de partitions physiques qui contiennent les données pertinentes. La spécification du chemin de clé de partition sous-partitionnée complet ou de préfixe évite efficacement une requête de distribution ramifiée complète. Par exemple, si le conteneur a 1 000 partitions physiques, mais qu’une valeur TenantId particulière se trouve uniquement sur 5 d’entre elles, la requête est acheminée vers le nombre moins important de partitions physiques pertinentes.

Utilisez l’ID d’élément dans la hiérarchie

Si votre conteneur a une propriété qui présente une large plage de valeurs possibles, cette propriété est probablement un bon choix de clé de partition pour le dernier niveau de votre hiérarchie. L’ID d’élément est un exemple possible de ce type de propriété. La propriété système ID d’élément existe dans chaque élément de votre conteneur. En ajoutant l’ID d’élément comme autre niveau, vous êtes assuré de pouvoir effectuer une mise à l’échelle au-delà de la limite de clé de partition logique de 20 Go. Vous pouvez effectuer une mise à l’échelle au-delà de cette limite pour le premier niveau ou pour le premier et le deuxième niveaux de clés.

Par exemple, vous pouvez avoir un conteneur pour une charge de travail multilocataire partitionnée par TenantId et UserId. S’il est possible qu’une combinaison unique de TenantId et UserId dépasse 20 Go, nous vous recommandons d’effectuer un partitionnement à l’aide de trois niveaux de clés, où la clé de troisième niveau a une cardinalité élevée. Ainsi, une clé de troisième niveau constituée d’un GUID, dont la cardinalité est naturellement élevée, est un bon exemple de ce scénario. Sachant qu’il est peu probable que la combinaison formée par TenantId, UserId et un GUID dépasse 20 Go, la combinaison de TenantId et UserId peut en réalité faire l’objet d’une mise à l’échelle qui dépasse 20 Go.

Pour plus d’informations sur l’utilisation de l’ID d’élément comme clé de partition, consultez la vue d’ensemble du partitionnement.

Bien démarrer

Important

L’utilisation de conteneurs utilisant des clés de partition hiérarchiques est prise en charge uniquement dans les versions suivantes du SDK. Vous devez utiliser un kit SDK pris en charge pour créer des conteneurs avec des clés de partition hiérarchique et effectuer des opérations de création, de lecture, de mise à jour et de suppression (CRUD) ou d’interrogation sur les données. Si vous souhaitez utiliser un kit de développement logiciel (SDK) ou un connecteur qui n’est pas pris en charge actuellement, publiez une demande sur notre forum de la communauté.

Recherchez la dernière préversion de chaque kit SDK pris en charge :

Kit SDK Versions prises en charge Lien du gestionnaire de package
SDK .NET v3 >= 3.33.0 https://www.nuget.org/packages/Microsoft.Azure.Cosmos/3.33.0/
SDK Java v4 >= 4.42.0 https://github.com/Azure/azure-sdk-for-java/blob/main/sdk/cosmos/azure-cosmos/CHANGELOG.md#4420-2023-03-17/
SDK JavaScript v4 4.0.0 https://www.npmjs.com/package/@azure/cosmos/
Kit de développement logiciel (SDK) Python >= 4.6.0 https://pypi.org/project/azure-cosmos/4.6.0/

Créer un conteneur à l’aide de clés de partition hiérarchique

Pour commencer, créez un conteneur à l’aide d’une liste prédéfinie de chemins de clés de sous-partitionnement avec trois niveaux de profondeur maximum.

Vous pouvez créer un conteneur à l’aide de l’une des options suivantes :

  • Portail Azure
  • Kit SDK
  • Modèle Azure Resource Manager
  • Émulateur Azure Cosmos DB

Portail Azure

La façon la plus simple de créer un conteneur et de spécifier des clés de partition hiérarchique consiste à utiliser le portail Azure.

  1. Connectez-vous au portail Azure.

  2. Accédez à la page du compte Azure Cosmos DB for NoSQL existant.

  3. Dans le menu de gauche, sélectionnez Explorateur de données.

    Capture d’écran montrant la page pour un nouveau compte Azure Cosmos DB for NoSQL avec l’option de menu Explorateur de données mise en évidence.

  4. Dans l’Explorateur de données, sélectionnez l’option Nouveau conteneur.

    Capture d’écran de l’option Nouveau conteneur dans l’Explorateur de données.

  5. Dans Nouveau conteneur, pour le champ Clé de partition, entrez /TenantId. Pour les champs restants, entrez une valeur qui correspond à votre scénario.

    Notes

    Nous utilisons /TenantId dans cet exemple. Vous pouvez spécifier n’importe quelle clé pour le premier niveau quand vous implémentez des clés de partition hiérarchique sur vos propres conteneurs.

  6. Sélectionnez deux fois Ajouter une clé de partition hiérarchique.

    Capture d’écran du bouton pour ajouter une nouvelle clé de partition hiérarchique.

  7. Pour les deuxième et troisième niveaux de sous-partitionnement, entrez /UserId et /SessionId, respectivement.

    Capture d’écran d’une liste de trois clés de partition hiérarchiques.

  8. Sélectionnez OK pour créer le conteneur.

Kit SDK

Quand vous créez un conteneur à l’aide du kit SDK, définissez une liste de chemins de clés de sous-partitionnement avec trois niveaux de profondeur maximum. Utilisez la liste des clés de sous-partitionnement lors de la configuration des propriétés du nouveau conteneur.

// 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);

Modèles Microsoft Azure Resource Manager

Le modèle Azure Resource Manager pour un conteneur sous-partitionné est quasiment identique à un conteneur standard. La seule différence principale est la valeur du chemin properties/partitionKey. Pour plus d’informations sur la création d’un modèle Azure Resource Manager pour une ressource Azure Cosmos DB, consultez les informations de référence sur le modèle Azure Resource Manager pour Azure Cosmos DB.

Configurez l’objet partitionKey en utilisant les valeurs du tableau suivant pour créer un conteneur sous-partitionné :

Chemin d’accès Valeur
paths Liste des clés de partition hiérarchiques (trois niveaux de profondeur maximum)
kind MultiHash
version 2

Exemple de définition de clé de partition

Par exemple, supposons que vous disposez d’une clé de partition hiérarchique composée de TenantId>UserId>SessionId. L’objet partitionKey est configuré pour inclure les trois valeurs dans la propriété paths, une valeur kind de MultiHash et une valeur de version de 2.

partitionKey: {
  paths: [
    '/TenantId'
    '/UserId'
    '/SessionId'
  ]
  kind: 'MultiHash'
  version: 2
}

Pour plus d’informations sur l’objet partitionKey, consultez la spécification ContainerPartitionKey.

Émulateur Azure Cosmos DB

Vous pouvez tester la fonctionnalité de sous-partitionnement à l’aide de la dernière version de l’émulateur local pour Azure Cosmos DB. Pour activer le sous-partitionnement sur l’émulateur, démarrez l’émulateur à partir du répertoire d’installation avec l’indicateur /EnablePreview :

.\CosmosDB.Emulator.exe /EnablePreview

Avertissement

Actuellement, l’émulateur ne prend pas en charge toutes les fonctionnalités de clé de partition hiérarchiques comme le portail. Actuellement, l’émulateur ne prend pas en charge :

  • Utilisation de Data Explorer pour créer des conteneurs avec des clés de partition hiérarchiques
  • Utilisation de Data Explorer pour accéder aux éléments et interagir avec eux en utilisant des clés de partition hiérarchiques

Pour plus d’informations, consultez Émulateur Azure Cosmos DB.

Utiliser les SDK pour travailler avec des conteneurs contenant des clés de partition hiérarchique

Quand vous disposez d’un conteneur contenant des clés de partition hiérarchique, utilisez les versions précédemment spécifiées des kits SDK .NET ou Java pour effectuer des opérations et exécuter des requêtes sur ce conteneur.

Ajouter un élément à un conteneur

Il existe deux options pour ajouter un nouvel élément à un conteneur dont les clés de partition hiérarchique sont activées :

  • Extraction automatique
  • Spécifier manuellement le chemin d’accès

Extraction automatique

Si vous transmettez un objet avec la valeur de clé de partition définie, le kit SDK peut extraire automatiquement le chemin complet de clé de partition.

// 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);

Spécifier manuellement le chemin d’accès

La classe PartitionKeyBuilder du kit SDK peut construire une valeur pour un chemin de clé de partition hiérarchique précédemment défini. Utilisez cette classe quand vous ajoutez un nouvel élément à un conteneur dont le sous-partitionnement est activé.

Conseil

À grande échelle, vous pouvez améliorer les performances si vous spécifiez le chemin de clé de partition complet, même si le kit SDK peut extraire le chemin à partir de l’objet.

// 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);

Effectuer une recherche clé/valeur (lecture de point) d’un élément

Les recherches de clé/valeur (lectures de points) sont effectuées de manière similaire à un conteneur qui n’est pas sous-partitionné. Par exemple, supposons que vous disposez d’une clé de partition hiérarchique composée de TenantId>UserId>SessionId. L’identificateur unique de l’élément est un GUID. Il est représenté sous forme de chaîne, qui sert d’identificateur de transaction de document unique. Pour effectuer une lecture de point sur un seul élément, transmettez la propriété id de l’élément et la valeur complète de la clé de partition, y compris les trois composants du chemin.

// 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
);

Exécuter une requête

Le code du kit SDK utilisé pour exécuter une requête sur un conteneur sous-partitionné est identique à l’exécution d’une requête sur un conteneur non sous-partitionné.

Quand la requête spécifie toutes les valeurs des clés de partition dans le filtre WHERE ou dans un préfixe de la hiérarchie de clés, le kit SDK achemine automatiquement la requête vers les partitions physiques correspondantes. Les requêtes qui fournissent uniquement le « milieu » de la hiérarchie sont des requêtes dans plusieurs partitions.

Prenons l’exemple d’une clé de partition hiérarchique composée de TenantId>UserId>SessionId. Les composants du filtre de la requête déterminent s’il s’agit d’une requête à partition unique, d’une requête ciblée dans plusieurs partitions ou d’une requête de distribution ramifiée.

Requête Routage
SELECT * FROM c WHERE c.TenantId = 'Microsoft' AND c.UserId = '00aa00aa-bb11-cc22-dd33-44ee44ee44ee' AND c.SessionId = '0000-11-0000-1111' Acheminée vers la partition logique et physique unique qui contient les données pour les valeurs spécifiées de TenantId, UserId et SessionId.
SELECT * FROM c WHERE c.TenantId = 'Microsoft' AND c.UserId = '00aa00aa-bb11-cc22-dd33-44ee44ee44ee' Acheminé uniquement vers le sous-ensemble de partition(s) logique et physique qui contient les données pour les valeurs spécifiées de TenantId et UserId. Cette requête est une requête ciblée dans plusieurs partitions qui retourne des données pour un utilisateur spécifique dans le locataire.
SELECT * FROM c WHERE c.TenantId = 'Microsoft' Acheminé uniquement vers le sous-ensemble de partition(s) logique et physique qui contient les données pour la valeur spécifiée de TenantId. Cette requête est une requête ciblée dans plusieurs partitions qui retourne des données pour tous les utilisateurs dans un locataire.
SELECT * FROM c WHERE c.UserId = '00aa00aa-bb11-cc22-dd33-44ee44ee44ee' Acheminé vers toutes les partitions physiques, ce qui entraîne une requête de distribution ramifiée dans plusieurs partitions.
SELECT * FROM c WHERE c.SessionId = '0000-11-0000-1111' Acheminé vers toutes les partitions physiques, ce qui entraîne une requête de distribution ramifiée dans plusieurs partitions.

Requête à partition unique sur un conteneur sous-partitionné

Voici un exemple d’exécution d’une requête qui inclut tous les niveaux de sous-partitionnement, ce qui fait de la requête une requête à partition unique.

// 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
    }
}

Requête à plusieurs partitions ciblée sur un conteneur sous-partitionné

Voici un exemple de requête qui inclut un sous-ensemble des niveaux de sous-partitionnement, ce qui fait de cette requête une requête à plusieurs partitions ciblée.

// 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
    }
}

Limitations et problèmes connus

  • Les conteneurs qui utilisent des clés de partition hiérarchique sont pris en charge uniquement dans les SDK .NET v3, Java v4, Python, ainsi que dans la préversion du SDK JavaScript. Vous devez utiliser un kit SDK pris en charge pour créer des conteneurs qui contiennent des clés de partition hiérarchique et effectuer des opérations CRUD ou d’interrogation sur les données. La prise en charge d’autres kits SDK, notamment Python, n’est pas disponible pour le moment.
  • Il existe des limitations avec différents connecteurs Azure Cosmos DB (par exemple, avec Azure Data Factory).
  • Vous pouvez uniquement spécifier des clés de partition hiérarchique jusqu’à trois couches en profondeur.
  • Les clés de partition hiérarchique peuvent actuellement être activées uniquement sur les nouveaux conteneurs. Vous devez définir des chemins de clé de partition au moment de la création du conteneur, et vous ne pouvez pas les modifier ultérieurement. Pour utiliser des partitions hiérarchiques sur des conteneurs existants, créez un conteneur avec les clés de partition hiérarchique définies et déplacez les données à l’aide de travaux de copie de conteneur.
  • Les clés de partition hiérarchique sont actuellement prises en charge uniquement pour les comptes d’API pour NoSQL. Les API pour MongoDB et Cassandra ne sont actuellement pas prises en charge.
  • Les clés de partition hiérarchiques ne sont actuellement pas prises en charge avec la fonctionnalité relative aux utilisateurs et aux autorisations. Vous ne pouvez pas attribuer d’autorisation à un préfixe partiel du chemin de clé de partition hiérarchique. Les autorisations peuvent uniquement être attribuées à l’intégralité du chemin de clé de partition logique. Par exemple, si vous avez partitionné par TenantId - >UserId, vous ne pouvez pas attribuer d’autorisation pour une valeur spécifique de TenantId. Toutefois, vous pouvez attribuer une autorisation pour une clé de partition si vous spécifiez à la fois la valeur de TenantId et « UserId ».

Étapes suivantes