ApsaraDB for MongoDB:Overview of new features in MongoDB 7.0

Nouveautés en bref

Chiffrement interrogeable

Le chiffrement interrogeable, qui était en préversion dans MongoDB 6.0, est désormais généralement disponible dans MongoDB 7,0.

Pour plus de détails sur l'implémentation, consultez la section Chiffrement interrogeableChiffrement interrogeable.

Vérification de la cohérence des métadonnées de shard

Les incohérences de métadonnées entre les shards peuvent provoquer des erreurs de routage subtiles, difficiles à diagnostiquer après coup. La commande checkMetadataConsistency, ajoutée dans MongoDB 7,0, permet de détecter proactivement ces incohérences avant qu'elles n'affectent le trafic de production.

Exécutez la commande au niveau de la base de données :

// Check metadata consistency for the current database
db.runCommand({
  checkMetadataConsistency: 1,
  checkIndexes: true
})

Utilisez également les assistants mongosh pour effectuer des vérifications à différentes échelles :

// Check the current database
db.checkMetadataConsistency()

// Check a specific collection
db.collection.checkMetadataConsistency()

// Check all databases in the sharded cluster
sh.checkMetadataConsistency()

Intégrez cette vérification à vos opérations et votre maintenance (O&M) habituelles afin de détecter rapidement les incohérences. Pour la référence complète de la commande, consultez checkMetadataConsistency.

Analyse de la clé de shard (analyzeShardKey)

Le choix d'une mauvaise clé de shard entraîne des points chauds, une distribution inégale des données et une dégradation des performances des requêtes, autant de problèmes coûteux à résoudre une fois la collection shardée. La commande analyzeShardKey évalue une clé de shard candidate par rapport à des exemples de requêtes réelles, ce qui vous permet de prendre une décision éclairée avant de vous engager.

db.adminCommand({
  analyzeShardKey: "<db>.<collection>",
  key: <shardKey>,
  keyCharacteristics: <bool>,
  readWriteDistribution: <bool>,
  sampleRate: <double>,
  sampleSize: <int>
})

La commande ne bloque ni les lectures ni les écritures sur la collection. Afin de minimiser l'impact sur les charges de travail de production, utilisez-la avec la préférence de lecture secondary ou secondaryPreferred. Sur un cluster shardé, mongos définit automatiquement la préférence de lecture sur secondaryPreferred.

Pour configurer l'échantillonnage des requêtes avant d'exécuter l'analyse, consultez configureQueryAnalyzer. Pour la référence complète de la commande, voir analyzeShardKey.

AutoMerger

Au fil de l'évolution d'un cluster shardé, via la migration des données, les suppressions de plages et les écritures continues, le nombre de chunks peut dépasser les besoins, entraînant une distribution inégale des données et un ralentissement du balancer. Introduit dans MongoDB 7,0, AutoMerger remédie à cette situation en fusionnant automatiquement les chunks lorsque la distribution des données ou des index est déséquilibrée, lorsqu'il y a trop de chunks ou pendant la migration des données.

AutoMerger est activé par défaut dans MongoDB 7,0. La commande configureCollectionBalancing, introduite dans les versions antérieures de MongoDB pour configurer les paramètres du balancer pour une collection shardée, prend également en charge AutoMerger :

db.adminCommand({
  configureCollectionBalancing: "<db>.<collection>",
  chunkSize: <num>,
  defragmentCollection: <bool>,
  enableAutoMerger: <bool>
})

Pour déclencher manuellement la fusion de tous les chunks fusionnables sur un shard spécifique, exécutez :

db.adminCommand({ mergeAllChunksOnShard: "db.coll", shard: "Shard0" })

Optimisations du sharding

Outre AutoMerger, MongoDB 7,0 inclut les modifications suivantes relatives au sharding :

• Paramètre rangeDeleterHighPriority : Contrôle si la suppression des documents orphelins est prioritaire par rapport aux opérations de suppression métier. La valeur par défaut est false, ce qui signifie que les opérations métier sont prioritaires.

• Suppression de operationsBlockedByRefresh : Le document operationsBlockedByRefresh a été supprimé de serverStatus. Les compteurs s'incrémentaient sur les nœuds mongos pour chaque opération utilisant les informations de routage de collection, même en l'absence d'actualisation du cache du catalogue, ce qui rendait les métriques trompeuses.

• Métriques de resharding : De nouvelles métriques de surveillance pour les opérations de resharding ont été ajoutées.

• Commande addShard : L'option maxSize n'est plus prise en charge.

• Validation de la taille des chunks : Lorsque vous ajustez la taille des chunks dans la collection config.settings, MongoDB valide désormais que la valeur se situe dans la plage prise en charge, soit de 1 à 1 024.

• Mises à jour de la politique du balancer (depuis MongoDB 6.0.3) : Le balancer distribue désormais les données en fonction du volume de données plutôt que du nombre de chunks. Le partitionnement est effectué par plage au lieu d'être effectué par chunk, et le fractionnement automatique ne se produit que lors de la migration des données entre les shards.

Sécurité

• Prise en charge de KMIP : Les versions V1.0 et V1.1 du protocole Key Management Interoperability Protocol (KMIP) sont désormais prises en charge pour la gestion externe des clés.

• OpenSSL : OpenSSL 3.0 et OpenSSL FIPS sont désormais pris en charge.

Agrégation

MongoDB 7,0 ajoute six nouveaux opérateurs d'agrégation.

db.sales.aggregate([
  {
    $group: {
      _id: "$category",
      medianRevenue: { $median: { input: "$revenue", method: "approximate" } },
      p90Revenue: { $percentile: { input: "$revenue", p: [0.90], method: "approximate" } }
    }
  }
])

Collections de séries temporelles

• Restrictions DELETE assouplies : La commande DELETE peut désormais être utilisée sur les collections de séries temporelles sans la plupart des restrictions applicables dans les versions antérieures. La seule restriction restante est que DELETE ne peut pas être utilisé dans une transaction multi-documents.

• Prise en charge de COMPACT : La commande COMPACT fonctionne désormais avec les collections de séries temporelles.

Autres modifications

• Champs du journal des requêtes lentes : De nouveaux champs, dont catalogCacheIndexLookupDurationMillis, ont été ajoutés aux entrées du journal des requêtes lentes. Consultez la section Journalisation des opérations lentes.

• Concurrence automatique du moteur de stockage : La concurrence des transactions pour le moteur de stockage WiredTiger est désormais ajustée automatiquement. La valeur par défaut avant l'ajustement automatique est de 128 tickets. Voir Transactions concurrentes du moteur de stockage (tickets de lecture et d'écriture).

• Métriques d'échantillonnage des requêtes dans currentOp : Les champs liés à l'échantillonnage des requêtes sont désormais inclus dans la sortie currentOp. Consultez les métriques currentOp.

• Index génériques composites : MongoDB 7,0 prend en charge les index génériques composites, qui combinent un champ générique avec un ou plusieurs champs standard. Voir Index génériques composites.

• Opérateur $changeStreamSplitLargeEvent : Fractionne les événements de change stream qui dépassent la limite de 16 Mo pour les documents BSON en plusieurs événements plus petits. Voir Événements de change stream volumineux.

• Améliorations du moteur d'exécution SBE (Slot-Based Execution) : Le moteur d'exécution de requêtes SBE a été optimisé pour améliorer les performances des requêtes.

• Métriques de migration des chunks : De nouvelles statistiques de sharding pour les migrations de chunks ont été ajoutées. Voir Nouvelles statistiques de sharding pour les migrations de chunks.

• Variable système USER_ROLES : Renvoie les rôles attribués à l'utilisateur actuel.

• Nouveaux paramètres globaux : Des paramètres pour analyzeShardKey, balancer et queryAnalyzers ont été ajoutés.

• Modifications de la sortie serverStatus : Des champs supplémentaires ont été ajoutés à la sortie serverStatus. Voir Modification de la sortie serverStatus.