FAQ MongoDBConsultez toutes les FAQ
Nombre d'auteurs : 1, nombre de questions : 331, dernière mise à jour : 18 décembre 2016 Ajouter une question
Cette FAQ a été réalisée à partir de la documentation officielle de Mongodb, des questions fréquemment posées sur les forums NoSQL Developpez.com et de l'expérience personnelle des auteurs.
Nous tenons à souligner que cette FAQ ne garantit en aucun cas que les informations qu'elle propose sont correctes. Les auteurs font leur maximum, mais l'erreur est humaine. Cette FAQ ne prétend pas non plus être complète. Si vous trouvez une erreur, ou que vous souhaitez nous aider en devenant rédacteur, lisez ceci.
Configurez toujours les systèmes pour avoir un espace de swap. Sans swap, votre système peut ne pas être dépendant dans certaines situations avec des contraintes extrêmes de la mémoire, des fuites de mémoire, ou plusieurs programmes utilisant la même mémoire. Pensez à l'espace de swap comme à quelque chose comme une soupape de décharge de vapeur qui permet au système de libérer la pression supplémentaire sans affecter le fonctionnement global du système.
Néanmoins, les systèmes exécutant MongoDB n'ont pas besoin de swap pour les opérations de routine. Les fichiers de base de données sont 
mappés en mémoire et devraient constituer la majorité de l'utilisation de la mémoire de votre MongoDB. Par conséquent, il est peu probable que mongod utilise l'espace de swap en fonctionnement normal. Le système d'exploitation libérera de la mémoire à partir des fichiers mappés en mémoire sans avoir besoin de swap et MongoDB peut écrire des données dans les fichiers de données sans avoir besoin du système de swap.
Le working set est la partie de vos données auxquelles les clients accèdent le plus souvent.
Votre working set doit rester dans la mémoire pour obtenir de bonnes performances. Autrement, beaucoup d'accès disque aléatoires vont se produire, et sauf si vous utilisez SSD, cela peut être très lent.
Un domaine à surveiller particulièrement dans la gestion de la taille de votre working set e les modèles d'accès aux index. Si vous insérez dans les index à des endroits aléatoires (comme ce sera le cas des id qui sont générés au hasard par des hachages), vous allez mettre à jour en permanence tout l'index. Si au contraire, vous êtes capable de créer vos identifiants dans un ordre croissant approximatif (par exemple, le jour concaténé avec un identifiant aléatoire), toutes les mises à jour se produisent du bon côté de l'arbre-b et la taille du working set pour les pages d'index sera beaucoup plus petite.
Cela est très avantageux lorsque les bases de données et leurs tailles virtuelles sont beaucoup plus grandes que la RAM.
La quantité de RAM dont vous avez besoin dépend de plusieurs facteurs, y compris, mais sans s'y limiter :
- la relation entre le stockage dans la base de données et le working set ;
- la stratégie de cache du système d'exploitation pour LRU (Least Recently Used) ;
- l'impact de la journalisation ;
- le nombre ou le taux de défauts de page et d'autres indicateurs du Cloud Manager de MongoDB pour détecter lorsque vous avez besoin de plus de RAM ;
- chaque thread de connexion à la base de données nécessitera jusqu'à 1 Mo de RAM.
MongoDB défère au système d'exploitation lors du chargement des données dans la mémoire à partir du disque. Elle
mappe en mémoire tous ses fichiers de données et repose sur le système d'exploitation pour la mise en cache des données. L'OS expulse généralement de la RAM les données moins récemment utilisées dès qu'il est à court de mémoire. Par exemple, si les clients accèdent aux indices plus fréquemment que les documents, alors les index seront plus susceptibles à rester dans la RAM, mais cela dépend de votre usage particulier.Pour calculer la quantité de RAM dont vous avez besoin, vous devez calculer la taille de votre working set, c'est-à-dire la partie de vos données que les clients utilisent le plus souvent. Cela dépend de vos modèles d'accès, des indices que vous avez et de la taille de vos documents. Parce que MongoDB utilise un modèle thread par connexion, chaque connexion de base de données nécessitera également jusqu'à 1 Mo de RAM, qu'elle soit active ou inactive.
Si les défauts de page sont rares, votre working set reste dans la mémoire vive. Si les taux de défaut augmentent, vous risquez la dégradation des performances. Celle-ci est moins critique avec les disques SSD qu'avec des disques en rotation.
Parce que mongod utilise des fichiers mappés en mémoire, les statistiques de mémoire de top nécessitent une interprétation d'une manière spéciale. Sur une grande base de données, VSIZE (octets virtuels) tend à être la taille de toute la base de données. Si le mongod n'a pas d'autres processus en cours, RSIZE (octets résidents) est la mémoire totale de la machine, car cela inclut le contenu du cache du système de fichiers.
Pour les systèmes Linux, utilisez la commande vmstat pour aider à déterminer comment le système utilise la mémoire. Sur les systèmes OS X utilisez vm_stat.
Proposer une nouvelle réponse sur la FAQ
Ce n'est pas l'endroit pour poser des questions, allez plutôt sur le forum de la rubrique pour ça
Les sources présentées sur cette page sont libres de droits et vous pouvez les utiliser à votre convenance. Par contre, la page de présentation constitue une œuvre intellectuelle protégée par les droits d'auteur. Copyright © 2024 Developpez Developpez LLC. Tous droits réservés Developpez LLC. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents et images sans l'autorisation expresse de Developpez LLC. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.