Points forts:
- Il est extrêmement important de concevoir le schéma même s'il est facultatif dans MongoDB.
- De même, les index doivent correspondre à votre schéma et à vos modèles d'accès.
- Évitez d'utiliser des objets volumineux et des tableaux volumineux.
- Soyez prudent avec les paramètres MongoDB, en particulier en ce qui concerne la sécurité et la fiabilité.
- MongoDB n'a pas d'optimiseur de requête, vous devez donc être prudent lors de l'exécution des opérations de requête.
Je travaille avec des bases de données depuis très longtemps, mais je n'ai découvert MongoDB que récemment. Il y a quelques choses que j'aimerais savoir avant de commencer. Lorsqu'une personne a déjà de l'expérience dans un certain domaine, elle a des idées préconçues sur ce que sont les bases de données et ce qu'elles font. Dans l'espoir de faciliter la compréhension des autres, voici une liste d'erreurs courantes.
Création d'un serveur MongoDB sans authentification
Malheureusement, MongoDB est installé sans authentification par défaut. Il est normal qu'un poste de travail soit accessible localement. Mais comme MongoDB est un système multi-utilisateurs qui aime utiliser de grandes quantités de mémoire, il est préférable de le placer sur un serveur avec autant de RAM que possible, même si vous n'allez l'utiliser que pour le développement. L'installation sur le serveur via le port par défaut peut être problématique, surtout si du code javascript peut être exécuté dans la requête (par exemple,
$wherecomme idée d' injection ).
Il existe plusieurs méthodes d'authentification, mais la plus simple est de définir un ID utilisateur / mot de passe. Prenez cette idée pendant que vous pensez à l' authentification sophistiquée basée sur LDAP . En termes de sécurité, MongoDB doit être tenu à jour et les journaux doivent toujours être vérifiés pour tout accès non autorisé. Par exemple, j'aime choisir un port différent comme port par défaut.
N'oubliez pas de lier la surface d'attaque à MongoDB
La liste de contrôle de sécurité MongoDB contient de bons conseils pour réduire le risque d'intrusion sur le réseau et de fuite de données. Il est facile de le rejeter et de dire qu'un serveur de développement n'a pas besoin d'un niveau de sécurité élevé. Cependant, les choses ne sont pas si simples et cela s'applique à tous les serveurs MongoDB. En particulier, à moins qu'il n'y ait une raison impérieuse d'utiliser
mapReduce, groupou $ where , vous devez désactiver l'utilisation de code JavaScript arbitraire en écrivant dans le fichier de configuration javascriptEnabled:false. Étant donné que les fichiers de données ne sont pas cryptés dans MongoDB standard, il est logique d'exécuter MongoDB avec un utilisateur dédié qui a un accès complet aux fichiers, avec un accès limité uniquement à lui et la possibilité d'utiliser les propres contrôles d'accès aux fichiers du système d'exploitation.
Erreur de conception du circuit
MongoDB n'utilise pas de schéma. Mais cela ne signifie pas que le circuit n'est pas nécessaire. Si vous souhaitez simplement stocker des documents sans mise en page cohérente, l'enregistrement peut être rapide et facile, mais les récupérer plus tard peut être sacrément difficile .
L'article classique « 6 règles empiriques pour la conception de schémas MongoDB» vaut la peine d'être lu, tandis que des fonctionnalités telles que l' explorateur de schémas de l' outil tiers de Studio 3T valent la peine d'être utilisées pour la validation régulière des schémas.
N'oubliez pas l'ordre de tri
L'oubli de l'ordre de tri peut être la plus frustrante et la plus inutile de toute autre mauvaise configuration. MongoBD utilise le tri binaire par défaut . Mais il est peu probable que cela soit utile à quiconque. Les sortes binaires sensibles à la casse et au stress étaient considérées comme de curieux anachronismes avec des perles, des caftans et des moustaches bouclées dans les années 80 du siècle dernier. Maintenant, leur utilisation est impardonnable. Dans la vraie vie, «moto» est la même chose que «moto». Et «Grande-Bretagne» et «Grande-Bretagne» sont un seul et même endroit. Une lettre minuscule est simplement l'équivalent majuscule d'une lettre majuscule. Et ne me faites pas parler de tri diacritique. Utilisez un classement insensible à la casse lors de la création d'une base de données dans MongoDBqui correspondent à la langue et à la culture des utilisateurs du système . Cela rend la recherche de données de chaîne beaucoup plus facile.
Création de collections avec des documents volumineux
MongoDB est heureux d'héberger des documents volumineux jusqu'à 16 Mo dans des collections, et GridFS est conçu pour les documents volumineux de plus de 16 Mo. Mais simplement parce que de gros documents peuvent y être placés, ce n'est pas une bonne idée de les y conserver. MongoDB fonctionnera mieux si vous enregistrez des documents individuels de plusieurs kilo-octets, en les traitant davantage comme des lignes dans une large table SQL. Les documents volumineux seront une source de problèmes de performances .
Créez des documents avec de grands tableaux
Les documents peuvent contenir des tableaux. Il est préférable que le nombre d'éléments dans le tableau soit éloigné du nombre à quatre chiffres. Si des éléments sont ajoutés fréquemment au tableau, il deviendra trop grand pour le document qui le contient et il devra être déplacé , ce qui signifie que les index devront être mis à jour . Lors de la réindexation d'un document avec un grand tableau, les index seront souvent écrasés, car pour chaque élément il y a une entrée stockant son index. Cette réindexation se produit également lorsqu'un document est inséré ou supprimé.
MongoDB a un soi-disant «facteur de remplissage» qui fournit de l'espace pour que les documents se développent pour minimiser ce problème.
Vous pourriez penser que vous pouvez vous passer de l'indexation des tableaux. Malheureusement, en raison du manque d'index, vous pouvez avoir d'autres problèmes. Étant donné que les documents sont numérisés du début à la fin, il faudra plus de temps pour trouver les éléments à la fin du tableau et la plupart des opérations associées à un tel document seront lentes .
N'oubliez pas l'ordre des étapes de l'agrégation compte
Dans un système de base de données avec un optimiseur de requêtes, les requêtes que vous écrivez sont des explications sur ce que vous voulez obtenir, et non sur la façon de l'obtenir. Ce mécanisme fonctionne par analogie avec la commande dans un restaurant: généralement vous commandez simplement un plat et ne donnez pas d'instructions détaillées au chef.
Dans MongoDB, vous instruisez le cuisinier. Par exemple, vous devez vous assurer que les données passent le
reduceplus tôt possible dans le pipeline à l'aide de $matchet $project, et que le tri n'a lieu qu'après reduce, et que la recherche se déroule exactement dans l'ordre dont vous avez besoin. Avoir un optimiseur de requêtes qui élimine le travail inutile, organise de manière optimale les étapes et sélectionne le type de connexion peut vous gâter. Dans MongoDB, vous avez plus de contrôle au détriment de la commodité.
Des outils commeStudio 3T facilitera la création de requêtes d'agrégation dans MongoDB . L'éditeur d'agrégation vous permet d'appliquer des instructions de pipeline une étape à la fois, ainsi que de valider l'entrée et la sortie à chaque étape pour simplifier le débogage.
Utilisation de l'enregistrement rapide
Ne définissez jamais les paramètres d'écriture MongoDB avec une vitesse élevée mais une fiabilité faible. Ce mode "file-and-forget" semble rapide car la commande revient avant l'écriture. Si le système se bloque avant l'écriture des données sur le disque, il sera perdu et dans un état incohérent. Heureusement, la journalisation de MongoDB 64 bits est activée.
Les moteurs de stockage MMAPv1 et WiredTiger utilisent la journalisation pour éviter cela, bien que WiredTiger puisse récupérer jusqu'au dernier point de contrôle correspondant si la journalisation est désactivée.
La journalisation garantit que la base de données est dans un état cohérent après la récupération et conserve toutes les données jusqu'à ce qu'elles soient enregistrées. La fréquence des entrées est configurée à l'aide du paramètre
commitIntervalMs.
Pour être sûr des enregistrements, assurez-vous que la journalisation est activée dans le fichier de configuration
(storage.journal.enabled)et que la fréquence des enregistrements est adaptée à la quantité d'informations que vous pouvez vous permettre de perdre.
Tri sans index
Lors de la recherche et de l'agrégation, il est souvent nécessaire de trier les données. Espérons que cela se fasse dans l'une des étapes finales, après avoir filtré le résultat afin de réduire la quantité de données triées. Même ainsi, vous avez besoin d'un index pour trier . Vous pouvez utiliser un seul ou plusieurs index.
S'il n'y a pas d'index approprié, MongoDB s'en passera. Il y a une limite de mémoire de 32 Mo sur la taille totale de tous les documents dans une opération de tri , et si MongoDB atteint cette limite, il lèvera une erreur ou renverra un jeu d'enregistrements vide .
Recherche sans prise en charge d'index
Les requêtes de recherche exécutent une fonction similaire à l'opération JOIN dans SQL. Pour de meilleures performances, ils ont besoin de l'index de la valeur de clé utilisée comme clé étrangère. Ce n'est pas évident car l'utilisation n'est pas reflétée dans le
explain(). Ces indices s'ajoutent à l'index écrit explain(), qui à son tour est utilisé par les opérateurs de pipeline $matchet $sort, lorsqu'ils surviennent au début du pipeline. Les index peuvent désormais couvrir n'importe quelle étape du pipeline d'agrégation .
Désactiver l'utilisation de la mise à jour multiple
La méthode est
db.collection.update()utilisée pour modifier une partie d'un document existant ou un document entier, jusqu'à un remplacement complet, selon le paramètre que vous spécifiez update. Il n'est pas si évident qu'il ne traitera pas tous les documents de la collection tant que vous n'aurez pas défini l'option multide mise à jour de tous les documents qui répondent aux critères de requête.
N'oubliez pas l'importance de l'ordre des clés dans la table de hachage
Dans JSON, un objet se compose d'une collection non ordonnée de zéro ou plusieurs paires nom / valeur, où nom est une chaîne et valeur est une chaîne, un nombre, un booléen, zéro, un objet ou un tableau.
Malheureusement, BSON accorde une grande importance à l'ordre lors de la recherche. Dans MongoDB, l'ordre des clés dans les objets en ligne est important , c'est-à-dire
{ firstname: "Phil", surname: "factor" }N'est pas le même que { { surname: "factor", firstname: "Phil" }. Autrement dit, vous devez conserver l'ordre des paires nom / valeur dans les documents si vous voulez être sûr de les trouver.
Ne confondez pas «null» et «indéfini»
La valeur "undefined" n'était jamais valide en JSON selon la norme officielle JSON (ECMA-404, section 5), même si elle est utilisée en JavaScript. De plus, pour BSON, il est obsolète et converti en
$null, ce qui n'est pas toujours une bonne solution. Évitez d'utiliser "indéfini" dans MongoDB .
Utiliser $limit()sans$sort()
Très souvent, lorsque vous développez dans MongoDB, il est utile de voir simplement un échantillon du résultat qui reviendra d'une requête ou d'une agrégation. Il est utile pour cette tâche
$limit(), mais il ne devrait jamais être dans la version finale du code, à moins que vous ne l'utilisiez devant lui $sort. Ce mécanisme est nécessaire car sinon vous ne pouvez pas garantir l'ordre du résultat et vous ne pouvez pas visualiser les données de manière fiable. En haut du résultat, vous obtiendrez différents enregistrements en fonction du tri. Pour fonctionner de manière fiable, les requêtes et les agrégations doivent être déterministes, c'est-à-dire produire les mêmes résultats à chaque fois. Le code, qui est $limit()présent mais pas $sort, ne sera pas déterministe et peut par la suite provoquer des erreurs qu'il sera difficile de localiser.
Conclusion
La seule façon d'être frustré avec MongoDB est de le comparer directement à un autre type de base de données, comme un SGBD, ou de proposer une attente spécifique pour l'utiliser. C'est comme comparer une orange à une fourchette. Les systèmes de bases de données ont des objectifs spécifiques. Il est préférable de simplement comprendre et d'apprécier ces différences par vous-même. Il serait dommage de faire pression sur les développeurs MongoDB à cause du chemin qui les a obligés à suivre le chemin du SGBD. Je souhaite trouver des moyens nouveaux et passionnants de résoudre d'anciens problèmes, tels que garantir l'intégrité des données et créer des systèmes de données résistants aux pannes et aux attaques d'utilisateurs malveillants.
L'implémentation 4.0 de MongoDB de la transactionnalité ACID est un bon exemple de la manière dont les améliorations importantes sont innovées. Les transactions multi-documents et multi-instructions sont désormais atomiques. Il est également devenu possible d'ajuster le temps nécessaire pour acquérir les verrous et terminer les transactions bloquées, ainsi que pour modifier le niveau d'isolement.
