14 choses que j'aurais aimé savoir avant de commencer avec MongoDB

La traduction de l'article a été préparée à la veille du début du cours "Bases de données non relationnelles".

14 choses que j'aurais aimé savoir avant de commencer avec MongoDB

Faits saillants:

  • Il est extrêmement important de développer un 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 de grands tableaux.
  • Soyez prudent avec les paramètres de MongoDB, notamment en matière de sécurité et de fiabilité.
  • MongoDB ne dispose pas d'optimiseur de requêtes, vous devez donc être prudent lorsque vous effectuez 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 certaines choses que j'aurais aimé savoir avant de commencer à travailler avec. 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, je présente une liste d'erreurs courantes.

Création d'un serveur MongoDB sans authentification

Malheureusement, MongoDB est installé par défaut sans authentification. Pour un poste de travail accessible localement, cette pratique est normale. Mais comme MongoDB est un système multi-utilisateurs qui aime utiliser de grandes quantités de mémoire, il serait préférable de le placer sur un serveur avec autant de RAM que possible, même si vous ne l'utilisez 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, $where comme une idée pour injections).

Il existe plusieurs méthodes d'authentification, mais la plus simple consiste à définir un identifiant/mot de passe utilisateur. Utilisez cette idée pendant que vous réfléchissez à une authentification sophistiquée basée sur LDAP. En matière de sécurité, MongoDB doit être constamment mis à jour et les journaux doivent toujours être vérifiés pour détecter tout accès non autorisé. Par exemple, j'aime sélectionner un port différent comme port par défaut.

N'oubliez pas de lier la surface d'attaque à MongoDB

Liste de contrôle de sécurité MongoDB contient de bons conseils pour réduire les risques d’intrusion sur le réseau et de fuite de données. Il est facile de passer outre et de dire qu'un serveur de développement n'a pas besoin d'un niveau de sécurité élevé. Cependant, ce n'est pas si simple et cela s'applique à tous les serveurs MongoDB. En particulier, s'il n'existe aucune raison impérieuse d'utiliser mapReduce, group ou $où, vous devez désactiver l'utilisation de code arbitraire en JavaScript en écrivant dans le fichier de configuration javascriptEnabled:false. Étant donné que les fichiers de données ne sont pas chiffrés dans MongoDB standard, il est logique d'exécuter MongoDB avec Utilisateur dédié, qui a un accès complet aux fichiers, avec un accès limité uniquement à ceux-ci et la possibilité d'utiliser les propres contrôles d'accès aux fichiers du système d'exploitation.

Erreur lors du développement du circuit

MongoDB n'utilise pas de schéma. Mais cela ne veut pas dire que ce programme n’est pas nécessaire. Si vous souhaitez simplement stocker des documents sans modèle cohérent, leur sauvegarde peut être rapide et facile, mais leur récupération ultérieure peut s'avérer difficile. sacrément difficile.

Article classique "6 règles empiriques pour la conception de schémas MongoDB" Cela vaut la peine d'être lu, et des fonctionnalités comme Explorateur de schéma dans l'outil tiers Studio 3T, il vaut la peine de l'utiliser pour des contrôles réguliers des circuits.

N'oubliez pas l'ordre de tri

Oublier l’ordre de tri peut provoquer plus de frustration et faire perdre plus de temps que toute autre configuration incorrecte. Par défaut, MongoBD utilise tri binaire. Mais il est peu probable que cela soit utile à qui que ce soit. Dans les années 80 du siècle dernier, les types binaires sensibles à la casse et à l'accent étaient considérés comme de curieux anachronismes, au même titre que les perles, les caftans et les moustaches frisées. Désormais, leur utilisation est impardonnable. Dans la vraie vie, « moto » est la même chose que « moto ». Et « Grande-Bretagne » et « Grande-Bretagne » sont le même endroit. Une lettre minuscule est simplement l’équivalent majuscule d’une lettre majuscule. Et ne me lancez pas dans le tri des signes diacritiques. Lors de la création d'une base de données dans MongoDB, utilisez un classement insensible aux accents et S'inscrire, qui correspondent à la langue et culture des utilisateurs du système. Cela rendra la recherche dans les données de chaîne beaucoup plus facile.

Créez des collections avec des documents volumineux

MongoDB est heureux d'héberger des documents volumineux jusqu'à 16 Mo dans des collections, et GrilleFS Conçu pour les documents volumineux de plus de 16 Mo. Mais simplement parce que des documents volumineux peuvent y être placés, les stocker là-bas n’est pas une bonne idée. MongoDB fonctionnera mieux si vous stockez des documents individuels d'une taille de quelques kilo-octets, en les traitant davantage comme des lignes dans une large table SQL. Les documents volumineux seront une source de problèmes avec productivité.

Création de 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 loin d'être un nombre à quatre chiffres. Si des éléments sont ajoutés fréquemment à un tableau, celui-ci deviendra trop grand pour le document qui le contient et devra être déplacer, ce qui veut dire qu'il faudra mettre également à jour les index. Lors de la réindexation d'un document avec un grand tableau, les index seront souvent écrasés, car il existe un record, qui stocke son index. Cette réindexation se produit également lorsqu'un document est inséré ou supprimé.

MongoDB a quelque chose qui s'appelle "facteur de remplissage", ce qui permet aux documents de croître afin de minimiser ce problème.
Vous pourriez penser que vous pouvez vous passer de l’indexation des tableaux. Malheureusement, le manque d'index peut vous causer d'autres problèmes. Étant donné que les documents sont numérisés du début à la fin, la recherche des éléments à la fin du tableau prendra plus de temps et la plupart des opérations associées à un tel document seront ralentir.

N'oubliez pas que l'ordre des étapes dans une agrégation compte

Dans un système de base de données doté d'un optimiseur de requêtes, les requêtes que vous écrivez sont des explications sur ce que vous souhaitez obtenir, et non sur la manière de l'obtenir. Ce mécanisme fonctionne par analogie avec la commande dans un restaurant : généralement, vous commandez simplement un plat, et vous ne donnez pas d'instructions détaillées au cuisinier.

Dans MongoDB, vous instruisez le cuisinier. Par exemple, vous devez vous assurer que les données transitent par reduce le plus tôt possible dans le pipeline en utilisant $match и $project, et le tri n'a lieu qu'après reduce, et que la recherche s'effectue exactement dans l'ordre souhaité. Avoir un optimiseur de requêtes qui élimine le travail inutile, séquence les étapes de manière optimale et sélectionne les types de jointure peut vous gâter. Avec MongoDB, vous avez plus de contrôle au détriment de la commodité.

Des outils comme Atelier 3T simplifiera la construction de requêtes d'agrégation dans MongoDB. La fonctionnalité Éditeur d'agrégation vous permet d'appliquer les instructions de pipeline une étape à la fois et d'inspecter les données d'entrée et de sortie à chaque étape pour faciliter le débogage.

Utiliser l'enregistrement rapide

Ne définissez jamais les options d'écriture de MongoDB pour avoir une vitesse élevée mais une faible fiabilité. Ce mode "archiver et oublier" semble rapide car la commande est renvoyée avant l'écriture. Si le système tombe en panne avant que les données ne soient écrites sur le disque, elles seront perdues et se retrouveront dans un état incohérent. Heureusement, MongoDB 64 bits a la journalisation activée.

Les moteurs de stockage MMAPv1 et WiredTiger utilisent la journalisation pour empêcher cela, bien que WiredTiger puisse récupérer jusqu'au dernier fichier cohérent. point de contrôle, 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 écrites dans le journal. La fréquence des enregistrements est configurée à l'aide du paramètre commitIntervalMs.

Pour être sûr des entrées, assurez-vous que la journalisation est activée dans le fichier de configuration (storage.journal.enabled), et la fréquence des enregistrements correspond à 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 soit fait lors de l'une des étapes finales, après avoir filtré le résultat afin de réduire la quantité de données à trier. Et même dans ce cas, pour trier il vous faudra index. Vous pouvez utiliser un index simple ou composé.

S'il n'y a pas d'index approprié, MongoDB s'en passera. Il existe une limite de mémoire de 32 Mo pour la taille totale de tous les documents dans opérations de tri, et si MongoDB atteint cette limite, alors il générera une erreur ou retournera jeu d'enregistrements vide.

Recherche sans support d'index

Les requêtes de recherche exécutent une fonction similaire à l'opération JOIN dans SQL. Pour fonctionner au mieux, ils ont besoin de l’index de la valeur de la clé utilisée comme clé étrangère. Ce n'est pas évident car l'usage ne se reflète pas dans explain(). Ces indices s'ajoutent à l'indice inscrit dans explain(), qui est à son tour utilisé par les exploitants de pipelines $match и $sort, lorsqu'ils se rencontrent au début du pipeline. Les index peuvent désormais couvrir n'importe quelle étape pipeline d'agrégation.

Désactiver l'utilisation des mises à jour multiples

méthode db.collection.update() utilisé pour modifier une partie d'un document existant ou l'ensemble du document, jusqu'à un remplacement complet, selon le paramètre que vous spécifiez update. Ce qui n'est pas si évident, c'est qu'il ne traitera pas tous les documents de la collection à moins que vous ne définissiez l'option multi mettre à jour tous les documents qui répondent aux critères de la demande.

N'oubliez pas l'importance de l'ordre des clés dans une table de hachage

En JSON, un objet consiste en une collection non ordonnée de taille zéro ou de plusieurs paires nom/valeur, où nom est une chaîne et valeur est une chaîne, un nombre, un booléen, une valeur nulle, un objet ou un tableau.

Malheureusement, BSON accorde beaucoup d'importance à l'ordre lors de la recherche. Dans MongoDB, l'ordre des clés dans les objets intégrés questionsC.-à- { firstname: "Phil", surname: "factor" } - ce n'est pas la même chose que { { surname: "factor", firstname: "Phil" }. Autrement dit, vous devez stocker l’ordre des paires nom/valeur dans vos documents si vous voulez être sûr de les retrouver.

Ne pas confondre "Nul" и "indéfini"

Valeur "indéfini" n'a jamais été valide en JSON, selon norme officielle JSON (ECMA-404 Section 5), même s'il est utilisé en JavaScript. De plus, pour BSON il est obsolète et est converti en $null, ce qui n'est pas toujours une bonne solution. Évitez d'utiliser "indéfini" dans MongoDB.

l'utilisation de $limit() sans $sort()

Très souvent, lorsque vous développez dans MongoDB, il est utile de simplement voir un échantillon du résultat qui sera renvoyé par une requête ou une agrégation. Pour cette tâche, vous aurez besoin $limit(), mais il ne devrait jamais figurer dans le code final, sauf si vous l'utilisez auparavant $sort. Cette mécanique est nécessaire car sinon vous ne pourrez pas garantir l’ordre du résultat et vous ne pourrez pas visualiser les données de manière fiable. En haut du résultat, vous obtiendrez différentes entrées 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 qu'elles sont exécutées. Code qui contient $limit(), mais non $sort, ne sera pas déterministe et pourra par la suite provoquer des erreurs difficiles à traquer.

Conclusion

La seule manière d'être déçu par MongoDB est de le comparer directement à un autre type de base de données, comme un SGBD, ou d'en venir à l'utiliser en fonction de certaines attentes. C'est comme comparer une orange à une fourchette. Les systèmes de bases de données répondent à des objectifs spécifiques. Il est préférable de simplement comprendre et apprécier ces différences par vous-même. Il serait dommage de faire pression sur les développeurs de MongoDB sur une voie qui les obligerait à emprunter la voie du SGBD. Je souhaite découvrir des moyens nouveaux et intéressants 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ésilients aux pannes et aux attaques malveillantes.

L'introduction par MongoDB de la transactionnalité ACID dans la version 4.0 est un bon exemple d'introduction d'améliorations importantes de manière innovante. Les transactions multidocuments et multi-relevés sont désormais atomiques. Il est également possible d'ajuster le temps nécessaire pour acquérir les verrous et mettre fin aux transactions bloquées, ainsi que modifier le niveau d'isolement.

14 choses que j'aurais aimé savoir avant de commencer avec MongoDB

Lire la suite:

Source: habr.com

Ajouter un commentaire