MongoDB
 sql >> Base de données >  >> NoSQL >> MongoDB

Quoi de neuf dans MongoDB 4.2

Les mises à jour de la base de données s'accompagnent de fonctionnalités améliorées pour les performances, la sécurité et de nouvelles fonctionnalités intégrées. Il est toujours conseillé de tester une nouvelle version avant de la déployer en production, juste pour s'assurer qu'elle répond à vos besoins et qu'il n'y a aucune possibilité de plantage.

Considérant de nombreux produits, ceux qui précèdent les premières versions mineures d'une nouvelle version majeure ont les correctifs les plus importants. Par exemple, je préférerais avoir la version 4.2.1 de MongoDB en production quelques jours après la sortie que je ne le ferais pour la version 4.2.0.

Dans ce blog, nous allons discuter de ce qui a été inclus et des améliorations apportées à MongoDB version 4.2

Quoi de neuf dans MongoDB 4.2

  1. Transactions distribuées
  2. Index génériques
  3. Lectures et écritures réessayables
  4. Chiffrement automatique au niveau du champ côté client.
  5. Langage de requête amélioré pour les mises à jour expressives
  6. Vues matérialisées à la demande
  7. Opérations de maintenance modernes

Transactions distribuées

Les transactions sont des fonctionnalités importantes de la base de données qui garantissent la cohérence et l'intégrité des données, en particulier celles qui garantissent les procédures ACID. MongoDB version 4.2 prend désormais en charge les transactions multidocuments sur des ensembles de répliques et un cluster fragmenté via l'approche des transactions distribuées. La même syntaxe d'utilisation des transactions a été conservée que la version 4.0 précédente.

Cependant, les spécifications du pilote client ont un peu changé, donc si l'on a l'intention d'utiliser des transactions dans MongoDB 4.2, vous devez mettre à niveau les pilotes vers des versions compatibles avec les serveurs 4.2.

Cette version ne limite pas la taille d'une transaction en termes d'utilisation de la mémoire mais dépend uniquement de la taille de votre matériel et de la capacité de gestion du matériel.

La réaffectation globale des paramètres régionaux du cluster est désormais possible avec la version 4.2. C'est-à-dire que, pour une implémentation de partitionnement de zone géographique, si un utilisateur résidant dans la région A se déplace vers la région B, en modifiant la valeur de son champ de localisation, les données peuvent être automatiquement déplacées de la région A vers B via une transaction.

Le système de sharding permet désormais de changer une clé de shard contrairement à la version précédente. Littéralement, lorsqu'une clé de partition est modifiée, cela équivaut à déplacer le document vers une autre partition. Dans cette version, MongoDB encapsule cette mise à jour et si le document doit être déplacé d'un fragment à un autre, la mise à jour sera exécutée dans une transaction en arrière-plan.

L'utilisation de transactions n'est pas une approche recommandée car elles dégradent les performances de la base de données, en particulier si elles se produisent plusieurs fois. Au cours d'une période de transaction, il existe une fenêtre étirée pour les opérations susceptibles de provoquer des conflits lors de l'écriture d'un document affecté. Dans la mesure où une transaction peut être réessayée, il peut y avoir une mise à jour apportée au document avant cette nouvelle tentative, et chaque fois que la nouvelle tentative se produit, elle peut traiter l'ancienne version du document plutôt que la dernière. Les tentatives entraînent évidemment plus de coûts de traitement en plus d'augmenter le temps d'arrêt de l'application grâce à une latence croissante.

Une bonne pratique concernant l'utilisation des transactions inclut :

  1. Évitez d'utiliser des requêtes non indexées dans une transaction pour vous assurer que l'opération ne sera pas lente.
  2. Votre transaction doit impliquer quelques documents.

Avec le format de schéma dynamique MongoDB et la fonctionnalité d'intégration, vous pouvez choisir de mettre tous les champs dans la même collection pour éviter d'avoir à utiliser la transaction comme première mesure.

Index génériques

Les index génériques ont été introduits dans MongoDB version 4.2 pour améliorer les requêtes sur des champs arbitraires ou des champs dont les noms ne sont pas connus à l'avance, en indexant l'intégralité du document ou du sous-document. Ils ne sont pas destinés à remplacer les index basés sur la charge de travail mais convient de travailler avec des données impliquant un motif polymorphe. Un modèle polymorphe est l'endroit où tous les documents d'une collection sont similaires mais n'ont pas une structure identique. Des modèles de données polymorphes peuvent être générés à partir d'applications impliquant des catalogues de produits ou des données sociales. Vous trouverez ci-dessous un exemple de données de collecte polymorphes

{

Sport: ‘Chess’,

playerName: ‘John Mah’,

Career_earning: {amount: NumberDecimal(“3000”), currency: “EUR”},

gamesPlayed:25,

career_titles:10

},

{

Sport: Tennis,

playerName: ‘Semenya Jones,

Career_earning: {amount: NumberDecimal(“34545”), currency: “USD”},

Event: {

name:”Olympics”,

career_titles:10,

career_tournaments:14

}

En indexant l'intégralité du document à l'aide d'index génériques, vous pouvez effectuer une requête en utilisant n'importe quel champ arbitraire comme index.

Pour créer un index Wildcard

$db.collection.createIndex({“fieldA.$**”: 1})

Si le champ sélectionné est un document imbriqué ou un tableau, l'index Wildcard revient dans le document et stocke la valeur de tous les champs du document ou du tableau.

Lectures et écritures réessayables

Normalement, une base de données peut subir des pannes transitoires fréquentes du réseau qui peuvent entraîner l'inexécution partielle ou totale d'une requête. Ces erreurs de réseau peuvent ne pas être si graves et offrent donc une chance de réessayer ces requêtes une fois reconnectées. À partir de MongoDB 4.2, la configuration des nouvelles tentatives est activée par défaut. Les pilotes MongoDB peuvent réessayer les lectures et écritures ayant échoué pour certaines transactions chaque fois qu'ils rencontrent des erreurs réseau mineures ou plutôt lorsqu'ils sont incapables de trouver un primaire sain dans le cluster/réplica partitionné. Cependant, si vous ne voulez pas les écritures réessayables, vous pouvez les désactiver explicitement dans vos configurations, mais je ne trouve pas de raison impérieuse de les désactiver.

Cette fonctionnalité permet de s'assurer qu'en cas de modification de l'infrastructure MongoDB, le code de l'application ne sera pas affecté. En ce qui concerne un exemple expliqué par Eliot Horowitz, le co-fondateur de MongoDB, pour une page Web qui effectue 20 opérations de base de données différentes, au lieu de recharger le tout ou d'avoir à envelopper la page Web entière dans une sorte de boucle, le pilote sous les couvertures peut simplement décider de réessayer l'opération. Chaque fois qu'une écriture échoue, elle réessayera automatiquement et aura un contrat avec le serveur pour garantir que chaque écriture ne se produise qu'une seule fois.

Les écritures réessayables n'effectuent qu'une seule tentative, ce qui permet de résoudre les élections d'ensembles de réplicas et les erreurs de réseau transitoires, mais pas les erreurs de réseau persistantes.

Les écritures réessayables ne traitent pas les instances où la période de basculement dépasse la valeur serverSelectionTimoutMs dans les configurations de paramètre.

Avec cette version de MongoDB, on peut mettre à jour les valeurs de clé de partition de document (sauf si la clé de partition est le champ _id immuable) en émettant des opérations findAndModify/update sur un seul document soit dans une transaction, soit comme une écriture réessayable .

MongoDB version 4.2 peut désormais réessayer une opération d'upsert sur un seul document (c'est-à-dire upsert :vrai et multi :faux) qui peut avoir échoué en raison d'une erreur de clé en double si l'opération répond à ces conditions de clé :

  1. La collection cible contient un index unique qui a créé l'erreur de clé en double.
  2. L'opération de mise à jour ne modifiera aucun des champs du prédicat de requête.
  3. La condition de correspondance de mise à jour est soit un prédicat d'égalité unique {champ :"valeur"}, soit un ET logique de prédicats d'égalité {filed :"valeur", champ0 :"valeur0"}
  4. L'ensemble de champs dans le modèle de clé d'index unique correspond à l'ensemble de champs dans le prédicat de requête de mise à jour.

Chiffrement automatique au niveau du champ côté client

MongoDB version 4.2 est livré avec le chiffrement automatique au niveau du champ côté client (CSFLE), une fonctionnalité qui permet aux développeurs de chiffrer de manière sélective les champs individuels d'un document côté client avant qu'il ne soit envoyé au serveur. Les données cryptées sont ainsi gardées privées des fournisseurs hébergeant la base de données et de tout utilisateur pouvant avoir un accès direct à la base de données.

Seules les applications ayant accès aux clés de chiffrement correctes peuvent déchiffrer et lire les données protégées. Si la clé de chiffrement est supprimée, toutes les données chiffrées seront rendues illisibles.

Remarque :cette fonctionnalité n'est disponible qu'avec MongoDB Enterprise uniquement.

Langage de requête amélioré pour les mises à jour expressives

MongoDB version 4.2 fournit un langage de requête plus riche que ses prédécesseurs. Il prend désormais en charge les agrégations et les opérations de cas d'utilisation modernes telles que les recherches géolocalisées, la recherche de graphiques et la recherche de texte. Il a intégré un moteur de recherche tiers qui accélère les recherches étant donné que le moteur de recherche s'exécute sur un processus/serveur différent. Cela améliore généralement les performances de la base de données contrairement à si toutes les recherches étaient effectuées sur le processus mongod, ce qui rendrait plutôt la latence de fonctionnement de la base de données volatile chaque fois que le moteur de recherche réindexe.

Avec cette version, vous pouvez désormais gérer des tableaux, faire des sommes et d'autres opérations mathématiques directement via une instruction de mise à jour.

Vues matérialisées à la demande

Le framework de pipeline d'agrégation de données dans MongoDB est une fonctionnalité intéressante avec différentes étapes de transformation d'un document à un état souhaité. La version 4.2 de MongoDB introduit une nouvelle étape $merge qui, pour moi, je dirai que cela m'a fait gagner du temps à travailler avec la sortie finale qui devait être stockée dans une collection. Initialement, l'étape $out permet de créer une nouvelle collection basée sur l'agrégation et de remplir la collection avec les résultats obtenus. Si la collection existe déjà, elle écraserait la collection avec les nouveaux résultats contrairement à l'étape $merge qui incorpore uniquement les résultats du pipeline dans une sortie existante plutôt que de remplacer entièrement la collection. La régénération d'une collection entière à chaque fois avec l'étape $out consomme beaucoup de CPU et d'E/S, ce qui peut dégrader les performances de la base de données. Le contenu de sortie sera donc mis à jour en temps opportun, permettant aux utilisateurs de créer des vues matérialisées à la demande

Opérations de maintenance modernes

Les développeurs peuvent désormais bénéficier d'une excellente expérience opérationnelle avec MongoDB version 4.2 avec des fonctionnalités intégrées qui améliorent la haute disponibilité, la stratégie de sauvegarde gérée dans le cloud, améliorent la puissance de surveillance et les systèmes d'alerte. MongoDB Atlas et MongoDB Ops Manager sont les plates-formes fournissant ces fonctionnalités. Ce dernier a été étiqueté comme le meilleur pour exécuter MongoDB en entreprise. Il a également été intégré à l'opérateur Kubernetes pour les utilisateurs sur site qui migrent vers le cloud privé. Cette interface permet de contrôler directement Ops Manager.

Certaines modifications internes ont été apportées à la version 4.2 de MongoDB, notamment :

  1. Liste des curseurs ouverts.
  2. Suppression du moteur de stockage MMAPv1.
  3. Amélioration de la réparation du fichier de données WiredTiger.
  4. Les champs de diagnostic peuvent désormais avoir queryHash
  5. Le fil de fractionnement automatique pour les nœuds mongos a été supprimé.

Conclusion

MongoDB version 4.2 est livré avec quelques améliorations en matière de sécurité et de performances de base de données. Il a inclus un chiffrement automatique au niveau du champ côté client qui garantit que les données sont protégées du point de vue du client. Plus de fonctionnalités comme un moteur de recherche tiers et l'inclusion de l'étape $merge dans le cadre d'agrégation améliorent les performances de la base de données. Avant de mettre cette version en production, veuillez vous assurer que tous vos besoins sont entièrement pris en compte.