Accueil / Articles / Cosmos DB : maîtriser les coûts

› Article

Cosmos DB : maîtriser les coûts liés aux RU/s.

Sur Azure Cosmos DB, la facture dépend surtout du débit, mesuré en unités de requête par seconde (RU/s). Une mauvaise clé de partition ou une requête coûteuse se paie chaque mois. Voici les leviers à examiner.


Comprendre l'unité de requête

Une unité de requête (RU) est une mesure normalisée du coût d'une opération : processeur, mémoire et entrées-sorties réunis. À titre d'ordre de grandeur, la lecture d'un petit document de 1 Ko, par son identifiant et sa clé de partition, coûte environ 1 RU. Une requête qui parcourt plusieurs partitions peut coûter bien davantage. Le coût réel de chaque opération est renvoyé par le service : c'est la première chose à mesurer.

Ce que l'on paie

  • le débit : provisionné (manuel ou autoscale) ou à l'usage en mode serverless ;
  • le stockage des données et des index ;
  • les sauvegardes, selon le mode choisi ;
  • chaque région de réplication supplémentaire, qui multiplie le débit facturé.

Les tarifs évoluent : le calculateur de prix Azure reste la référence pour chiffrer un scénario.

Les leviers, par ordre d'efficacité

  • 1. La clé de partition : elle doit répartir uniformément la charge et permettre de cibler une seule partition dans les requêtes fréquentes. Une partition « chaude » force à surdimensionner le débit pour tout le conteneur.
  • 2. Les lectures ponctuelles : lire par identifiant et clé de partition coûte bien moins qu'une requête qui cherche le même document.
  • 3. Le modèle de données : regrouper dans un même document ce qui se lit ensemble évite plusieurs requêtes. À l'inverse, des documents trop volumineux alourdissent chaque lecture et chaque écriture.
  • 4. La politique d'indexation : par défaut, tous les chemins sont indexés. Exclure ceux qui ne servent jamais aux filtres réduit le coût des écritures et le stockage.
  • 5. Les requêtes : filtrer sur la clé de partition, projeter seulement les champs utiles plutôt que tout le document, paginer, et prévoir des index composites pour les tris.
  • 6. Le niveau de cohérence : les niveaux les plus stricts consomment plus d'unités de requête en lecture. On choisit le plus faible compatible avec le besoin métier.
  • 7. La durée de vie (TTL) : supprimer automatiquement les données périmées réduit le stockage et les index.
  • 8. Le mode de débit : manuel pour une charge stable, autoscale pour une charge variable (le débit évolue entre 10 % et 100 % du maximum fixé, à un tarif unitaire plus élevé), serverless pour un usage faible ou intermittent.
  • 9. Les réservations : un engagement d'un ou trois ans réduit le prix du débit pour les charges stables. À faire après avoir dimensionné, pas avant.

Les erreurs 429 : ne pas réagir à l'aveugle

Quand le débit est dépassé, le service renvoie une erreur 429 et demande de réessayer. Quelques erreurs occasionnelles, absorbées par les nouvelles tentatives du SDK, sont acceptables. Si elles sont fréquentes, il faut d'abord chercher la requête coûteuse ou la partition chaude, avant d'augmenter le débit, car cela augmente directement la facture sans traiter la cause.

Méthode de revue

  • Relever le coût en RU des 10 requêtes les plus fréquentes et des 10 plus coûteuses.
  • Vérifier la répartition de la charge entre les partitions.
  • Revoir la politique d'indexation et le modèle de documents.
  • Choisir le mode de débit d'après la courbe de charge réelle.
  • Mettre en place des alertes de coût et de consommation.

À retenir

  • Mesurer le coût en RU de chaque opération importante.
  • La clé de partition conditionne la répartition de la charge et donc le coût.
  • Préférer les lectures ponctuelles aux requêtes, et indexer seulement ce qui sert.
  • Corriger la cause d'abord, ensuite seulement ajuster le débit et réserver.

Un besoin à cadrer ?

Un premier échange suffit à définir le périmètre, le moteur concerné et la suite.

Demander un devis