MongoDB 8,0 apporte des améliorations significatives en matière de performances et introduit de nouvelles capacités dans les domaines de la gestion de la mémoire, de la réplication, du sharding, de l'agrégation et de la sécurité. Cette rubrique résume les principaux changements pour vous aider à évaluer la mise à niveau et comprendre leur impact sur vos applications.
Pour le journal des modifications complet en amont, consultez les notes de version de MongoDB 8,0.
Advanced TCMalloc
MongoDB 8,0 remplace l'allocateur de mémoire précédent par une version avancée de TCMalloc qui réduit la fragmentation de la mémoire et maintient les performances sous forte charge. Deux changements majeurs sont à l'origine de cette amélioration :
Mise en cache par CPU : Advanced TCMalloc utilise un cache par cœur de CPU au lieu d'un cache par thread, ce qui réduit la fragmentation de la mémoire et permet à la base de données de gérer des charges de travail concurrentes plus élevées.
Libération de mémoire en arrière-plan : Un thread d'arrière-plan tente de libérer la mémoire inutilisée vers le système d'exploitation chaque seconde.
Le paramètre tcmallocReleaseRate contrôle le taux de libération en octets/s. Avant MongoDB 8,0, ce paramètre acceptait une plage vague de 1–10. Dans ApsaraDB for MongoDB, la valeur par défaut est 10485760 (10 Mo). Même lorsqu'il est défini sur 0, l'allocateur libère toujours une partie de la mémoire. Ajustez cette valeur en fonction des exigences de votre charge de travail.
Performances de réplication
Changement de comportement de la préoccupation d'écriture « Majority »
À partir de MongoDB 8,0, lorsque writeConcern est défini sur majority, MongoDB accuse réception de l'écriture après que l'entrée oplog a été écrite sur la majorité des membres du replica set, sans attendre que ces membres appliquent la modification. Cela améliore le débit d'écriture en mode majority.
Impact potentiel : Si votre application lit depuis un nœud secondaire immédiatement après avoir reçu un accusé de réception d'écriture majority, la requête peut renvoyer des résultats qui n'incluent pas les modifications de cette écriture.
Écriture et application parallèles de l'oplog
Les nœuds secondaires écrivent et appliquent désormais les lots oplog en parallèle :
Un thread Writer lit les nouvelles entrées oplog depuis le nœud primaire et les écrit dans l'oplog local.
Un thread Applier applique de manière asynchrone ces modifications à la base de données locale.
Cela améliore le débit de réplication sur les nœuds secondaires. Les métriques serverStatus associées sont désormais rapportées sous la forme metrics.repl.buffer.write et metrics.repl.buffer.apply.
Performances de resharding
La commande reshardCollection est considérablement plus rapide dans MongoDB 8,0. La nouvelle option forceRedistribution vous permet de resharder une collection en utilisant sa clé de shard existante et de redistribuer les données vers de nouveaux shards. Cette opération s'achève plus rapidement que la migration d'un chunk vers une plage spécifique. Combinez forceRedistribution avec l'option zones pour migrer les données vers une zone spécifique.
db.adminCommand({
reshardCollection: "db.coll",
key: { shard_key: "hashed" },
forceRedistribution: true
})
La création d'index pendant le resharding peut entraîner l'échec silencieux des builds d'index, sans messages d'erreur explicites. Terminez toutes les créations d'index avant de démarrer le resharding, ou évitez de créer des index pendant que le resharding est en cours.
Pendant la phase de rattrapage incrémentiel de l'oplog, le shard source bloque les écritures sur la collection uniquement lorsque le temps restant estimé est inférieur à deux secondes, puis attend que le shard de destination termine le rattrapage. Si votre cas d'utilisation peut tolérer une fenêtre de blocage plus longue — par exemple, pendant une fenêtre de maintenance — exécutez la commande commitReshardCollection pour bloquer les écritures immédiatement et accélérer l'achèvement du resharding.
Pour plus d'informations, consultez Processus de reshardingSharding et Sharder une collection.
Sharding
En plus des améliorations de resharding mentionnées ci-dessus, MongoDB 8,0 inclut les changements suivants liés au sharding :
Sharding haché par défaut : Le sharding haché crée 1 chunk par shard par défaut (contre 2 chunks avant MongoDB 8,0).
dbHashsur les shards : La commandedbHashpeut désormais s'exécuter sur des shards individuels.Clés de shard partielles dans les requêtes : Les commandes
findAndModifyetdeleteOneacceptent des clés de shard partielles comme prédicats de requête.updateOneavec upsert : Lors de l'utilisation deupdateOneavecupsert: truesur une collection shardée, tous les champs de la clé de shard peuvent être omis du prédicat de requête.unshardCollection: Supprime le sharding d'une collection existante et déplace tous les documents vers un shard spécifique, ou vers le shard contenant le moins de données.moveCollection: Déplace une collection non shardée vers un shard spécifique, indépendamment du shard primaire. Les collections de séries temporelles et les collections Queryable Encryption ne peuvent pas être déplacées. Les opérations d'écriture sont bloquées pendant environ 2 secondes durant le déplacement.
Les commandes et fonctions d'assistance mongosh suivantes sont désormais disponibles :
| Commande | Fonction d'assistance mongosh | Description |
|---|---|---|
moveCollection |
sh.moveCollection() |
Déplace une collection non shardée vers un shard spécifique. |
unshardCollection |
sh.unshardCollection() |
Supprime le sharding d'une collection et déplace toutes les données vers un shard spécifique. |
abortMoveCollection |
sh.abortMoveCollection() |
Annule une opération moveCollection en cours. |
abortUnshardCollection |
sh.abortUnshardCollection() |
Annule une opération unshardCollection en cours. |
| Aucune | sh.shardAndDistributeCollection() |
Sharde une collection et redistribue immédiatement les données avec une clé de shard existante. Équivalent à l'exécution de shardCollection suivie de reshardCollection. |
Journalisation
Le champ workingMillis est ajouté aux journaux de requêtes lentes. Il indique le temps que MongoDB a réellement passé à traiter l'opération, ce qui est utile pour identifier les véritables goulets d'étranglement de performance.
Contrairement à durationMillis — qui reflète la latence totale de l'opération, y compris l'attente de verrou ou la limitation du trafic — workingMillis exclut ces temps d'attente externes. Utilisez workingMillis lorsque vous souhaitez mesurer le temps de traitement réel indépendamment de la contention de file d'attente ou de verrou.
Agrégation
Conversion BinData
L'opérateur $convert prend désormais en charge les conversions suivantes :
Chaîne vers BinData
BinData vers chaîne
L'expression $toUUID fournit un raccourci pour convertir les valeurs de chaîne en UUID.
$queryStats
L'étape d'agrégation $queryStats renvoie des statistiques pour les requêtes enregistrées. Dans MongoDB 8,0, elle suit et rapporte également les métriques dans les change streams de manière plus efficace.
Sécurité de la base de données
Queryable Encryption : requêtes de plage
Queryable Encryption prend désormais en charge les requêtes de plage sur les champs chiffrés en utilisant $lt, $lte, $gt et $gte.
File d'attente d'entrée
MongoDB 8,0 introduit une file d'attente d'entrée (ingressAdmissionControllerTicketPoolSize) pour les requêtes réseau entrantes. Les opérations reçues depuis le réseau entrent dans cette file d'attente avant d'être admises dans la base de données.
La file d'attente est illimitée par défaut. Définissez une taille maximale de file d'attente pour limiter le nombre de requêtes en attente et empêcher une mise en file d'attente illimitée lors des pics de trafic.
Autres optimisations
Formes de requête et paramètres de requête
MongoDB 8,0 introduit un nouveau concept de forme de requête. La forme de requête précédente est désormais appelée forme de requête du cache de plan. Utilisez les paramètres de requête (et non les filtres d'index) pour influencer la sélection du plan de requête — planCacheSetFilter pour définir des filtres d'index n'est plus pris en charge dans MongoDB 8,0.
Trois commandes gèrent les paramètres de requête :
setQuerySettings: Spécifiez des indices d'index ou définissez une politiquerejectpour une forme de requête spécifique afin de bloquer son exécution.removeQuerySettings: Supprimez les paramètres de requête pour une forme de requête.$querySettings: Consultez les paramètres de requête actuels.
Temps d'optimisation du plan de requête
La sortie de explain() inclut désormais queryPlanner.optimizationTimeMillis, qui indique le temps passé à l'optimisation du plan de requête en millisecondes.
Délai d'expiration par défaut des opérations de lecture
Le nouveau paramètre defaultMaxTimeMS définit une limite de temps par défaut (en millisecondes) pour les opérations de lecture. Il s'applique à find, aggregate (à l'exclusion des étapes $merge et $out), count, distinct et dbHash. Si le client spécifie maxTimeMS sur une opération individuelle, cette valeur est prioritaire.
Commande bulkWrite
La nouvelle commande bulkWrite exécute plusieurs opérations d'insertion, de mise à jour et de suppression sur plusieurs collections en une seule requête.
Modifications supplémentaires
Tri
updateOne:updateOneprend désormais en charge l'optionsort.Index TTL sur les collections capped : Les index TTL peuvent désormais être créés sur les collections capped.
Regroupement oplog des insertions en masse : Les insertions en masse non transactionnelles sont désormais écrites sous la forme d'une seule entrée oplog au lieu d'entrées séparées. Tous les documents insérés partagent le même
clusterTimedans les événements change stream. Cela améliore les performances des insertions en masse et réduit le retard de réplication dû à la relecture de plusieurs oplogs sur les nœuds secondaires.Opérations DDL concurrentes : Différentes collections dans la même base de données peuvent désormais subir des opérations DDL simultanément.
Modifications de l'appartenance aux shards pendant les opérations DDL : L'ajout ou la suppression de shards d'un cluster shardé est bloqué tant que des opérations DDL (telles que
reshardCollection) sont en cours. Terminez les opérations DDL avant de modifier l'appartenance aux shards.
Améliorations de la création d'index
MongoDB 8,0 améliore le rapport d'erreurs et la résilience pour les créations d'index :
| Aspect | MongoDB 8,0 | Avant MongoDB 8,0 |
|---|---|---|
| Rapport d'erreurs | Les erreurs détectées pendant la phase d'analyse de la collection (sauf les erreurs de clé en double) sont renvoyées immédiatement et la création d'index s'arrête. | Les erreurs détectées pendant l'analyse de la collection ne sont renvoyées qu'à la phase de validation à la fin de la création d'index, ce qui allonge le temps de diagnostic. |
| Résilience des nœuds secondaires | En cas d'erreur de création d'index, les nœuds secondaires peuvent demander au primaire d'arrêter la création d'index et ne plantent pas. (Si un secondaire a déjà voté pour valider, il ne peut pas s'arrêter et plantera — comportement cohérent avec MongoDB 7.0.) | Les erreurs de création d'index peuvent provoquer le plantage des nœuds secondaires. |
| Gestion de l'espace disque | Si l'espace disque disponible tombe en dessous de indexBuildMinAvailableDiskSpaceMB, la création d'index s'arrête automatiquement. (Ne s'arrête pas si le membre a déjà voté pour valider.) |
La création d'index s'arrête également en cas d'espace disque insuffisant. |