Interroger un conteneur Azure Cosmos DB

  • Article

S’APPLIQUE À : NoSQL

Cet article explique comment interroger un conteneur (collection, graphe ou table) dans Azure Cosmos DB. En particulier, il aborde la façon dont les requêtes de partition et sur plusieurs partitions fonctionnent dans Azure Cosmos DB.

Requête dans une partition

Quand vous interrogez des données de conteneurs, si un filtre de clé de partition est spécifié dans la requête, Azure Cosmos DB optimise la requête automatiquement. Il route la requête vers les partitions physiques qui correspondent aux valeurs de clé de partition spécifiées dans le filtre.

Par exemple, considérez la requête ci-dessous avec un filtre d’égalité sur DeviceId. Si nous exécutons cette requête sur un conteneur partitionné sur DeviceId, cette requête filtre sur une seule partition physique.

SELECT * FROM c WHERE c.DeviceId = 'XMS-0001'

Comme dans l’exemple précédent, cette requête filtre également sur une partition unique. L’ajout du filtre sur Location ne modifie pas la requête suivante :

SELECT * FROM c WHERE c.DeviceId = 'XMS-0001' AND c.Location = 'Seattle'

Voici une requête qui comporte un filtre de plage sur la clé de partition et qui n’est pas limitée à une seule partition physique. Pour être une requête dans une partition, la requête doit avoir un filtre d’égalité qui comprend la clé de partition :

SELECT * FROM c WHERE c.DeviceId > 'XMS-0001'

Requête dans plusieurs partitions

La requête suivante n’a pas de filtre sur la clé de partition (DeviceId). Par conséquent, elle doit se distribuer sur toutes les partitions physiques où elle est exécutée sur l’index de chaque partition :

SELECT * FROM c WHERE c.Location = 'Seattle`

Chaque partition physique a son propre index. Par conséquent, lorsque vous exécutez une requête sur plusieurs partitions sur un conteneur, vous exécutez de fait une requête par partition physique. Azure Cosmos DB regroupe automatiquement les résultats sur différentes partitions physiques.

Les index de différentes partitions physiques sont indépendants les uns des autres. Il n’y a pas d’index global dans Azure Cosmos DB.

Requête dans plusieurs partitions parallèles

Les kits SDK Azure Cosmos DB 1.9.0 (et versions ultérieures) prennent en charge les options d’exécution de requêtes parallèles. Les requêtes dans plusieurs partitions parallèles vous permettent d’exécuter des requêtes dans plusieurs partitions avec une faible latence.

Vous pouvez gérer l’exécution de requêtes parallèles en réglant les paramètres suivants :

  • MaxConcurrency : définit le nombre maximal de connexions réseau simultanées aux partitions du conteneur. Si vous affectez la valeur -1 à cette propriété, le kit SDK gère le degré de parallélisme. Si MaxConcurrency est défini sur 0, il existe une seule connexion réseau aux partitions du conteneur.

  • MaxBufferedItemCount : limite la latence des requêtes par rapport à l’utilisation de la mémoire côté client. Si cette option est omise ou si elle a la valeur -1, le kit SDK gère le nombre d’éléments mis en mémoire tampon durant l’exécution de requêtes parallèles.

En raison de la capacité d’Azure Cosmos DB à paralléliser les requêtes entre les partitions, la latence des requêtes est généralement correctement mise à l’échelle lorsque le système ajoute des partitions physiques. Toutefois, les frais de RU augmentent considérablement avec le nombre total de partitions physiques.

Lorsque vous exécutez une requête sur plusieurs partitions, vous effectuez essentiellement une requête distincte par partition physique individuelle. Même si les requêtes sur plusieurs partitions utilisent l’index quand celui-ci est disponible, elles ne sont pas aussi efficaces que les requêtes exécutées au sein d’une partition.

Exemple utile

Voici une analogie pour mieux comprendre les requêtes sur plusieurs partitions :

Imaginez que vous êtes un livreur qui doit remettre des paquets à différents complexes d’appartements. Chaque complexe d’appartements a une liste sur place qui contient tous les numéros d’unité des résidents. Nous pouvons comparer chaque complexe d’appartements à une partition physique et chaque liste à l’index de la partition physique.

Nous pouvons comparer les requêtes dans la partition et les requêtes sur plusieurs partitions à l’aide de l’exemple suivant :

Requête dans une partition (exemple)

Si le livreur connaît le bon complexe d’appartements (la bonne partition physique), il peut immédiatement se rediriger vers le bon bâtiment. Le livreur peut vérifier la liste des numéros d’unité des résidents (l’index) du complexe d’appartements et livrer rapidement les paquets correspondants. Dans ce cas, le livreur ne perd pas de temps ou d’efforts à conduire jusqu’à un complexe d’appartements pour vérifier si des destinataires de paquets habitent ici.

Requête dans plusieurs partitions (distribution ramifiée)

Si le livreur ne connaît pas le bon complexe d’appartements (la bonne partition physique), il devra aller jusqu’à chaque complexe d’appartements unique et vérifier la liste avec tous les numéros d’unité des résidents (l’index). Une fois que le conducteur arrive à chaque complexe d’appartements, il peut toujours utiliser la liste des adresses de chaque résident. Toutefois, il doit vérifier la liste de chaque complexe d’appartements, que des destinataires de paquets s’y trouvent ou non. Cet exemple présente comment les requêtes sur plusieurs partitions fonctionnent. Même si elles peuvent utiliser l’index (ce qui signifie qu’elles n’ont pas besoin d’aller frapper à chaque porte), elles doivent vérifier séparément l’index pour chaque partition physique.

Requête sur plusieurs partitions (limitée à quelques partitions physiques uniquement)

Si le livreur sait que tous les destinataires de paquets vivent dans un certain nombre de complexes d’appartements, il n’a pas besoin de conduire jusqu’à chaque complexe. Même si conduire jusqu’à quelques complexes nécessitera toujours plus de travail que la visite d’un seul bâtiment, le livreur économisera ainsi beaucoup de temps et d’efforts. Si une requête a la clé de partition dans son filtre avec le mot clé IN, elle ne vérifie que les index de la partition physique appropriée pour les données.

Évitez les requêtes entre les partitions

Pour la plupart des conteneurs, il est inévitable d’avoir des requêtes entre partitions, ce qui est correct. Presque toutes les opérations de requête sont prises en charge sur plusieurs partitions, aussi bien pour les clés de partition logique que les partitions physiques. Azure Cosmos DB offre également de nombreuses optimisations dans le moteur de requête et les kits de développement logiciel clients pour paralléliser l’exécution des requêtes sur les partitions physiques.

Pour la plupart des scénarios de lecture intensive, nous vous recommandons de sélectionner la propriété la plus courante dans vos filtres de requête. Vous devez également vous assurer que votre clé de partition adhère aux autres meilleures pratiques de sélection de clé de partition.

Il n’est généralement important d’éviter les requêtes sur plusieurs partitions qu’avec les conteneurs volumineux. Vous êtes facturé un minimum d’environ 2,5 RU chaque fois que vous vérifiez l’index d’une partition physique pour obtenir des résultats, même si aucun élément de la partition physique ne correspond au filtre de la requête. Par conséquent, si vous n’avez qu’une ou un petit nombre de partitions physiques, les requêtes sur plusieurs partitions ne consomment pas beaucoup plus de RU que les requêtes dans une seule partition.

Le nombre de partitions physiques est lié à la quantité de RU configurées. Chaque partition physique autorise jusqu’à 10 000 RU configurées et peut stocker jusqu’à 50 Go de données. Azure Cosmos DB gère automatiquement les partitions physiques. Le nombre de partitions physiques dans votre conteneur dépend de votre débit configuré et du stockage consommé.

Vous devez essayer d’éviter les requêtes sur plusieurs partitions si votre charge de travail répond aux critères suivants :

  • Vous envisagez de configurer plus de 30 000 RU
  • Vous envisagez de stocker plus de 100 Go de données

Étapes suivantes

Consultez les articles suivants pour en savoir plus sur le partitionnement dans Azure Cosmos DB :