Conseils de planification de schéma MongoDB

L'une des fonctionnalités les plus annoncées de MongoDB est sa capacité à être "sans schéma". Cela signifie que MongoDB n'impose aucun schéma sur les documents stockés dans une collection. Normalement, MongoDB stocke les documents au format JSON afin que chaque document puisse stocker différents types de schéma/structure. Ceci est avantageux pour les premières étapes du développement, mais dans les étapes ultérieures, vous souhaiterez peut-être appliquer une certaine validation de schéma lors de l'insertion de nouveaux documents pour de meilleures performances et une meilleure évolutivité. En bref, "Schemaless" ne signifie pas que vous n'avez pas besoin de concevoir votre schéma. Dans cet article, je vais discuter de quelques conseils généraux pour planifier votre schéma MongoDB.

Déterminer la meilleure conception de schéma qui convient à votre application peut parfois devenir fastidieux. Voici quelques points que vous pouvez prendre en compte lors de la conception de votre schéma.

Évitez la croissance des documents

Si votre schéma permet de créer des documents dont la taille augmente continuellement, vous devez prendre des mesures pour éviter cela, car cela peut entraîner une dégradation des performances de la base de données et des E/S du disque. Par défaut, MongoDB autorise une taille de 16 Mo par document. Si la taille de votre document augmente de plus de 16 Mo sur une période donnée, c'est le signe d'une mauvaise conception du schéma. Cela peut parfois conduire à l'échec des requêtes. Vous pouvez utiliser des compartiments de documents ou des techniques de pré-allocation de documents pour éviter cette situation. Si votre application doit stocker des documents d'une taille supérieure à 16 Mo, vous pouvez envisager d'utiliser l'API MongoDB GridFS.

Évitez de mettre à jour des documents entiers

Si vous essayez de mettre à jour l'intégralité du document, MongoDB réécrira l'intégralité du document ailleurs dans la mémoire. Cela peut dégrader considérablement les performances d'écriture de votre base de données. Au lieu de mettre à jour l'intégralité du document, vous pouvez utiliser des modificateurs de champ pour mettre à jour uniquement des champs spécifiques dans les documents. Cela déclenchera une mise à jour sur place en mémoire, d'où une amélioration des performances.

Essayez d'éviter les jointures au niveau de l'application

Comme nous le savons tous, MongoDB ne prend pas en charge les jointures au niveau du serveur. Par conséquent, nous devons obtenir toutes les données de la base de données, puis effectuer une jointure au niveau de l'application. Si vous récupérez des données de plusieurs collections et que vous joignez une grande quantité de données, vous devez appeler DB plusieurs fois pour obtenir toutes les données nécessaires. Cela demandera évidemment plus de temps car cela implique le réseau. En tant que solution à ce scénario, si votre application s'appuie fortement sur les jointures, la dénormalisation du schéma est plus logique. Vous pouvez utiliser des documents intégrés pour obtenir toutes les données requises en un seul appel de requête.

Utilisez une indexation appropriée

En faisant des recherches ou des agrégations, on trie souvent les données. Même si vous appliquez le tri à la dernière étape d'un pipeline, vous avez toujours besoin d'un index pour couvrir le tri. Si l'index sur le champ de tri n'est pas disponible, MongoDB est obligé de trier sans index. Il existe une limite de mémoire de 32 Mo de la taille totale de tous les documents impliqués dans l'opération de tri. Si MongoDB atteint cette limite, il peut soit produire une erreur, soit renvoyer un ensemble vide.

Après avoir discuté de l'ajout d'index, il est également important de ne pas ajouter d'index inutiles. Chaque index que vous ajoutez dans la base de données, vous devez mettre à jour tous ces index lors de la mise à jour des documents de la collection. Cela peut dégrader les performances de la base de données. De plus, chaque index occupera également de l'espace et de la mémoire, de sorte que le nombre d'index peut entraîner des problèmes liés au stockage.

Une autre façon d'optimiser l'utilisation d'un index consiste à remplacer le champ _id par défaut. Le seul but de ce champ est de garder un champ unique par document. Si vos données contiennent un horodatage ou un champ d'identification, vous pouvez remplacer le champ _id et enregistrer un index supplémentaire.

Rapport de lecture par rapport à l'écriture

La conception d'un schéma pour n'importe quelle application dépend énormément du fait qu'une application est lourde en lecture ou en écriture. Par exemple, si vous créez un tableau de bord pour afficher des données de séries chronologiques, vous devez concevoir votre schéma de manière à maximiser le débit d'écriture. Si votre application est basée sur le commerce électronique, la plupart des opérations seront des opérations de lecture, car la plupart des utilisateurs parcourront tous les produits et parcourront divers catalogues. Dans de tels cas, vous devez utiliser un schéma dénormalisé pour réduire le nombre d'appels à la base de données pour obtenir des données pertinentes.

Types de données BSON

Assurez-vous de définir correctement les types de données BSON pour tous les champs lors de la conception du schéma. Parce que lorsque vous modifiez le type de données de n'importe quel champ, MongoDB réécrira tout le document dans un nouvel espace mémoire. Par exemple, si vous essayez de stocker (int)0 à la place du champ (float)0.0, MongoDB réécrit l'intégralité du document à une nouvelle adresse en raison d'un changement de type de données BSON.

Conclusion

En un mot, il est sage de concevoir un schéma pour votre base de données Mongo car cela ne fera qu'améliorer les performances de votre application. À partir de la version 3.2, MongoDB a commencé à prendre en charge la validation de document où vous pouvez définir quels champs sont requis pour insérer un nouveau document. À partir de la version 3.6, MongoDB a introduit une manière plus élégante d'appliquer la validation de schéma à l'aide de JSON Schema Validation. À l'aide de cette méthode de validation, vous pouvez appliquer la vérification du type de données ainsi que la vérification des champs requis. Vous pouvez utiliser les approches ci-dessus pour vérifier si tous les documents utilisent le même type de schéma ou non.