Limites de service dans Azure Cosmos DB for MongoDB sur vCore
Ce document décrit les limites strictes et souples actuelles d’Azure Cosmos DB for MongoDB sur vCore. La plupart de ces limitations sont temporaires et évolueront à mesure que le service continue de s’améliorer. Si l’une de ces limites est un problème pour votre organisation, contactez notre équipe pour obtenir de l’aide.
Limites de requête et d’exécution
Limites d’exécution 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. Cela peut être remplacé sur la base d’une requête en utilisant
maxTimeMS
dans le pilote MongoDB respectif.
Exemple :
db.collection.find({ field: "value" }).maxTimeMS(5000)
Taille maximale des requêtes MongoDB
- La taille maximale de la mémoire pour les requêtes MongoDB dépend du niveau. Par exemple, pour M80, la taille limite de la mémoire des requêtes est d’environ 150 Mio.
- 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.
Limites d’indexation
Limites de l’indexation générale
- 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 build d’index unique 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.
Limites de l’indexation générique
- 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.
Limites 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
.
Limites des index 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 segmentation du texte en unités lexicales pour le chinois, le japonais et le coréen n’est pas encore prise en charge.
- La segmentation du texte en unités lexicales non sensible à la casse n’est pas encore prise en charge.
Limites de la recherche vectorielle
- Indexation de vecteurs d’une taille maximale de 2 000 dimensions.
- L’indexation ne s’applique qu’à un seul vecteur par tracé.
- Un seul index peut être créé par tracé vectoriel.
HNSW
etDiskANN
sont disponibles sur les niveaux de cluster M40 et versions ultérieures.
Limites des clusters et des partitions
Niveau de cluster
- Maximum : M200 / 64 vCores / 256 Gio RAM par partition physique. Contactez notre équipe pour les niveaux supérieurs.
Partitions physiques
- Maximum : 10. Contactez notre équipe pour plus de partitions.
Limites de collection
- Collections par cluster : 1 000
- Taille de collection non partitionnée : 4 Tio
Contactez notre équipe pour obtenir le support des valeurs plus élevées.
Régions secondaires
- Maximum : 1 région secondaire. Contactez notre équipe pour d’autres régions.
Limites 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+)
- Index vectoriels HNSW non pris en charge (disponible dans M40+)
- Journalisation des diagnostics non prise en charge (disponible dans M40+)
- 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.
Limites de la réplication et de la haute disponibilité (HA)
Réplication interrégion
- Les configurations suivantes sont identiques sur les clusters principaux et réplicas et ne peuvent pas être modifiées sur le cluster réplica :
- Stockage et nombre de partitions
- Comptes d'utilisateurs
- Les fonctionnalités suivantes ne sont pas disponibles sur les clusters de réplicas :
- Restauration à un instant donné
- Haute disponibilité (HA)
- La réplication interrégionale n’est pas disponible avec les clusters de niveau Calcul burstable ou Gratuit.
Limites diverses
Utilisation de Portal Mongo Shell
- Portal Mongo Shell peut être utilisé pendant 120 minutes dans une fenêtre de 24 heures.
Étapes suivantes
- Commencez par créer un cluster.
- Passez en revue les options de migration de MongoDB vers Azure Cosmos DB for MongoDB vCore.