Unités de requête dans Azure Cosmos DB
S’APPLIQUE À : 
NoSQL MongoDB Cassandra Gremlin Table
Azure Cosmos DB prend en charge de nombreuses API, notamment SQL, MongoDB, Cassandra, Gremlin et Table. Chaque API possède son propre ensemble d’opérations de base de données, qui vont de simples opérations ponctuelles de lecture et d'écriture à des requêtes complexes. Chaque opération de base de données consomme des ressources système en fonction de sa complexité.
Azure Cosmos DB normalise le coût de toutes les opérations de base de données en utilisant des unités de requête (ou RU sous forme abrégée) et mesure le coût en fonction du débit (unités de requête par seconde, RU/s).
Les unités de requête correspondent en quelque sorte à une devise de performances, faisant abstraction des ressources système (UC, IOPS, mémoire, etc.) requises pour effectuer les opérations de base de données prises en charge par Azure Cosmos DB. Que l’opération de base de données soit une opération d’écriture, une lecture de point ou une requête, les coûts sont toujours mesurés en unités de requête. Par exemple, une lecture de point (extraction d’un seul élément par son ID et la valeur de clé de partition) pour un élément de 1-Ko est une unité de requête (ou une RU), peu importe l’API que vous utilisez pour interagir avec votre conteneur Azure Cosmos DB. Vous pouvez modéliser vos coûts de débit en utilisant la Calculatrice de capacité Azure Cosmos DB.
L’image suivante illustre l’idée générale des unités de requête :
Pour gérer et planifier la capacité, Azure Cosmos DB veille à ce que le nombre d’unités de requête d’une opération de base de données spécifique sur un jeu de données spécifique soit déterministe. Vous pouvez examiner l’en-tête de réponse pour suivre le nombre d’unités de requête consommées par une opération de base de données. Une fois que vous avez compris quels facteurs ont un impact sur les frais d’unités de requête et cerné les besoins de débit de l’application, vous pouvez exécuter l’application de la manière la plus rentable possible.
Le type de compte Azure Cosmos DB que vous utilisez détermine la façon dont les unités de requête consommées sont facturées. Il existe trois modes dans lesquels vous pouvez créer un compte :
Mode débit provisionné : dans ce mode, vous attribuez le nombre de RU/s pour votre application, par incréments de 100 RU/s. Pour mettre à l’échelle le débit approvisionné pour votre application, vous pouvez à tout moment augmenter ou diminuer le nombre d’unités de requête par incréments ou décréments de 100 RU. soit programmatiquement soit sur le Portail Azure. Vous êtes facturé sur une base horaire pour le nombre de RU par seconde que vous avez provisionnées. Pour plus d'informations, consultez l'article Débit approvisionné.
Vous pouvez attribuer le débit selon deux niveaux de précision :
- Conteneurs : Pour plus d’informations, consultez Attribuer le débit à un conteneur Azure Cosmos DB.
- Bases de données : Pour plus d’informations, consultez Attribuer le débit à une base de données Azure Cosmos DB.
Mode serverless : dans ce mode, vous n’avez pas besoin d’attribuer un débit lors de la création de ressources dans votre compte Azure Cosmos DB. À la fin de votre période de facturation, vous recevez une facture pour le nombre d’unités de requête consommées par vos opérations de base de données. Pour plus d'informations, consultez l'article Débit Serverless.
Mode de mise à l’échelle automatique : Dans ce mode, vous pouvez mettre à l’échelle automatiquement et instantanément le débit (RU/s) de votre base de données ou de votre conteneur en fonction de son utilisation. Cette opération de mise à l’échelle n’affecte pas la disponibilité, la latence, le débit ou les performances de la charge de travail. Ce mode convient aux charges de travail stratégiques qui présentent des modèles de trafic variables ou imprévisibles et qui nécessitent des contrats SLA sur des performances et une mise à l'échelle élevées. Pour plus d'informations, consultez l'article Débit avec mise à l'échelle automatique.
Considérations relatives aux unités de requête
Pendant que vous estimez le nombre de RU que votre charge de travail consomme, tenez compte des facteurs suivants :
Taille de l’élément : plus la taille d’un élément augmente, plus le nombre d'unités de requête consommées pour le lire ou l’écrire augmente.
Indexation de l’élément : Par défaut, chaque élément est indexé automatiquement. Moins d’unités de requête sont consommées si vous choisissez de ne pas indexer tous les éléments d’un conteneur.
Nombre de propriétés de l’élément : en supposant que l’indexation par défaut concerne toutes les propriétés, le nombre d’unités de requête consommées pour écrire un élément augmente avec le nombre de propriétés de l’élément.
Propriétés indexées : Une stratégie d’indexation sur chaque conteneur détermine quelles propriétés sont indexées par défaut. Pour réduire la consommation d’unités de requête des opérations d’écriture, limitez le nombre de propriétés indexées.
Cohérence des données : les niveaux de cohérence de type fort et obsolescence limitée consomment approximativement deux fois plus d'unités de requête lors des opérations de lecture que les niveaux de cohérence de type flexible.
Type de lectures : les lectures ponctuelles sont plus économiques en RU que les requêtes.
Modèles de requête : la complexité d’une requête a une incidence sur le nombre d’unités de requête consommées pour une opération. Les facteurs qui influent sur le coût des opérations de requête sont les suivants :
- le nombre de résultats de la requête ;
- le nombre de prédicats ;
- la nature des prédicats ;
- le nombre de fonctions définies par l’utilisateur ;
- la taille des données sources ;
- la taille du jeu de résultats.
- Projections
La même requête portant sur les mêmes données coûte toujours le même nombre d’unités de requête en cas d’exécutions répétées.
Utilisation de scripts : comme avec les requêtes, les procédures stockées et les déclencheurs consomment plus ou moins d'unités de requête en fonction de la complexité des opérations effectuées. Lors du développement de l’application, inspectez l’en-tête des frais de requêtes pour mieux comprendre la capacité en unités de requête consommée par opération.
Unités de requête et régions multiples
Si vous attribuez « R » unités de requête sur un conteneur Azure Cosmos DB (ou une base de données), Azure Cosmos DB garantit que « R » unités de requête sont disponibles dans chaque région associée à votre compte Azure Cosmos DB. Vous ne pouvez pas affecter sélectivement des unités de requête à une région spécifique. Les unités de requête approvisionnées pour un conteneur (ou une base de données) Azure Cosmos DB sont approvisionnées pour toutes les régions associées à votre compte Azure Cosmos DB.
En supposant qu’un conteneur Azure Cosmos DB est configuré avec « R » unités de requête et que « N » régions sont associées au compte Azure Cosmos DB, le nombre total d’unités de requête disponibles à l’échelle mondiale sur le conteneur = R x N.
Votre choix de modèle de cohérence affecte également le débit. Vous pouvez approximativement doubler le débit de lecture pour les niveaux de cohérence les plus souples (session, préfixe cohérent et cohérence éventuelle) par rapport à des niveaux de cohérence plus stricts (obsolescence limitée ou cohérence forte).