Partager via

Informations de référence sur les limites et quotas du service Azure DocumentDB

Ce document décrit les limites matérielles et réversibles actuelles pour les clusters et les opérations Azure DocumentDB. Découvrez les limites d’exécution des requêtes, les contraintes d’indexation, les configurations de cluster et les limites d’authentification qui vous aident à planifier et à optimiser efficacement vos déploiements Azure DocumentDB.

Limitations de requête et d’exécution

Les limites suivantes s’appliquent aux opérations de requête et à l’exécution de commandes dans les clusters Azure DocumentDB.

Limitations de l’exécution de MongoDB

  • Durée de vie maximale des transactions : 30 secondes.

  • Durée de vie du curseur : 10 minutes. Remarque : Une erreur cursorNotFound risque de se produire si le curseur dépasse sa durée de vie.

  • Limite d’exécution de requête par défaut : 120 secondes. Cette limite peut être remplacée pour chaque requête en utilisant maxTimeMS dans le pilote MongoDB respectif.

Example

db.collection.find({ field: "value" }).maxTimeMS(5000)

Taille maximale de requête MongoDB

  • La taille maximale de la mémoire pour les requêtes MongoDB dépend du niveau. Par exemple, pour M80, la limite de taille de mémoire des requêtes est d’environ 150 MiB.

  • Dans les clusters partitionnés, si une requête extrait des données des nœuds, la limite de cette taille de données est de 1 Go.

Limitations de l’indexation

Azure DocumentDB applique différentes limites d’indexation pour garantir une utilisation optimale des performances et des ressources entre différents types d’index et opérations.

Limitations générales de l’indexation

  • Nombre maximal de champs d’index composés : 32.

  • Taille maximale de la valeur de champ _id : 2 Ko.

  • Taille maximale du chemin d’index : 256B.

  • Valeur maximale par défaut : 64.

    • Configurable jusqu’à : 300 index par collection.

  • Le tri est effectué en mémoire et n’atteint pas l’index.

  • Niveau maximal d’imbrication des objets/tableaux incorporés dans les définitions d’index : 6.

  • Une seule construction d'index peut être en cours sur la même collection.

  • Le nombre de builds d’index simultanées sur différentes collections est configurable (par défaut : 2).

  • Utilisez la commande currentOp pour afficher la progression des builds d’index de longue durée.

  • Les builds d’index uniques sont effectuées au premier plan et bloquent les écritures dans la collection.

limitations de l'indexation par caractères génériques

  • Pour les index génériques, si le champ indexé est un tableau de tableaux, l’ensemble du tableau incorporé est pris comme valeur au lieu de parcourir son contenu.

Limitations de l’indexation géospatiale

  • Aucune prise en charge de BigPolygons.

  • Les index composites ne prennent pas en charge les index géospatiaux.

  • La requête $geoWithin ne prend pas en charge les polygones avec des trous.

  • Le champ key est obligatoire à l’étape d’agrégation $geoNear.

  • Les index sont recommandés, mais pas obligatoires pour $near, les opérateurs de requête $nearSphere et l’étape d’agrégation $geoNear.

Limitations de l’index de texte

  • Un seul index de texte peut être défini sur une collection.

  • Prennent en charge les recherches de texte simples uniquement ; les fonctionnalités de recherche avancées, telles que les recherches d’expressions régulières, ne sont pas prises en charge.

  • hint() n’est pas pris en charge en association avec une requête utilisant une expression $text.

  • Les opérations de tri ne peuvent utiliser le classement de l’index texte.

  • La tokenisation pour le chinois, le japonais et le coréen n’est pas prise en charge.

  • La tokenisation insensible à la casse n'est pas prise en charge.

Limitations de recherche vectorielle

  • Vecteurs d’indexation jusqu’à 16 000 dimensions en taille (avec quantisation de produit)

  • L’indexation ne s’applique qu’à un seul vecteur par tracé.

  • Un seul index peut être créé par tracé vectoriel.

  • HNSW et DiskANN sont disponibles sur les niveaux de cluster M30 et supérieurs.

Limitations du cluster et des shards

Azure DocumentDB impose des limites spécifiques à la configuration du cluster, au partitionnement physique et à la gestion des regroupements pour garantir des performances et une allocation de ressources optimales.

Niveau de cluster

  • Maximum : M200 / 64 vCores / 256-Gio RAM par partition physique.

Partitions physiques

  • Maximum : 10.

Limitations de collection

  • Collections par cluster : 1 000

  • Taille de collection non partitionnée : 32 Tio

Régions secondaires

  • Maximum : une région secondaire.

Limitations du niveau gratuit

Les limitations suivantes peuvent être remplacées en passant à un niveau payant

  • Stockage maximal : 32 Gio.

  • Sauvegarde/restauration non prise en charge (disponible dans M25+)

  • Haute disponibilité non prise en charge (disponible dans M30+)

  • Les index vectoriels HNSW (Hierarchical navigable small world) ne sont pas pris en charge (disponibles dans M40+)

  • Journalisation des diagnostics non prise en charge (disponible uniquement dans les niveaux payants)

  • Microsoft Entra ID non pris en charge

  • Aucun contrat de niveau de service fourni (nécessite l’activation de la haute disponibilité)

  • Les clusters du niveau Gratuit sont mis en pause après 60 jours d’inactivité, quand il n’y a aucune connexion au cluster.

  • La transition d’un compte de niveau payant à un compte de niveau gratuit n’est pas prise en charge.

Limites de niveau

Les niveaux de service M10, M20 et M25 présentent les limitations suivantes :

  • Ne prend en charge qu'un seul fragment physique (nœud).

  • Conçue pour les cas dusage Dev/Test, la Haute Disponibilité en région nest pas prise en charge.

  • Les tailles de stockage prises en charge incluent 32 Gio, 64 Gio et 128 Gio.

  • Une fois le cluster mis à l’échelle vers le niveau M30 ou supérieur, le cluster ne peut pas être ramené au niveau de calcul M10, M20 ou M25.

Limitations du chiffrement des données clés gérées par le client

Voici les limitations actuelles pour la configuration de la clé gérée par le client (CMK) dans Azure DocumentDB :

Limites de réplication et de haute disponibilité locale

Azure DocumentDB fournit des fonctionnalités de réplication et de haute disponibilité intégrées avec des limitations spécifiques pour garantir la cohérence et les performances des données dans différents scénarios de déploiement.

Réplication entre régions et au sein d'une même région

  • Les configurations suivantes sont identiques sur le cluster principal et le cluster réplica et ne peuvent pas être modifiées sur le cluster réplica :

    • Stockage et nombre de partitions physiques

    • Comptes d'utilisateurs

  • Les fonctionnalités suivantes ne sont pas disponibles sur les clusters de réplication :

    • Restauration à un point dans le temps

    • Haute disponibilité (HA) dans la région

  • La réplication n’est pas disponible sur les clusters avec calcul Burstable ou niveau Gratuit.

Authentification et contrôle d’accès (contrôle d’accès en fonction du rôle)

Azure DocumentDB applique des limites d’authentification et de contrôle d’accès pour maintenir la sécurité et gérer l’allocation des ressources entre les comptes d’utilisateur et les rôles.

  • Vous pouvez créer jusqu’à 100 utilisateurs/rôles par cluster.

Authentification par Microsoft Entra ID

La fonctionnalité d’authentification Microsoft Entra ID présente les limitations actuelles suivantes :

  • Cette fonctionnalité ne prend pas en charge les groupes d’ID Microsoft Entra.

  • Lorsque la méthode d’authentification DocumentDB native est désactivée, MongoDB Shell n’est pas pris en charge dans le démarrage rapide du portail Azure.

Utilisateurs secondaires DocumentDB natifs

La fonctionnalité utilisateurs secondaires natives présente les limitations suivantes :

  • La Updateuser commande prend désormais uniquement en charge les mises à jour de mot de passe et ne peut pas modifier d’autres champs d’objet.

  • La Roleinfo commande n’est pas prise en charge. Vous pouvez également utiliser usersInfo.

  • L’attribution de rôles à des bases de données ou collections spécifiques n’est pas prise en charge, seul le niveau de cluster est pris en charge.

Limitations diverses

Azure DocumentDB a des limites plus opérationnelles et spécifiques aux fonctionnalités qui s’appliquent à différents aspects de la gestion et des fonctionnalités du cluster.

Utilisation de l’interpréteur de commandes Mongo du portail

  • L’interpréteur de commandes Mongo du portail peut être utilisé pendant 120 minutes dans une fenêtre de 24 heures.

Taille et profondeur du document

  • Taille maximale du document BSON (Binary JavaScript Object Notation) : 16 Mo par document.

  • Aucune limite de profondeur d’imbrication maximale fixe n’est appliquée.

    • Les structures de documents profondément imbriquées peuvent affecter les performances de requête et de lecture, augmenter la surcharge de traitement et réduire la facilité de maintenance.

Limites de lot

  • Les deux types d’opérations par lots (écriture et en masse) sont pris en charge.

    • Un lot fait référence à une seule requête au serveur.

  • Nombre maximal d’écritures par opération par lot : 25 000 écritures.

  • Les opérations par lots dépassant 25 000 écritures échouent.

  • Aucune limite quant au nombre total d’opérations de traitement par lots.

Contenu connexe

  • Last updated on