FAQ MongoDBConsultez toutes les FAQ

Cette partie traite de questions courantes de haut niveau au sujet de MongoDB et de son utilisation.

Si vous ne trouvez pas la réponse que vous recherchez, consultez la liste complète des FAQ ou postez votre question dans la liste de diffusion des utilisateurs MongoDB.

MongoDB est un SGBD orienté documents. Pensez à des objets MySQL, mais avec du JSON comme modèle de données, plutôt qu'à des tables de SGBDR. De manière significative, MongoDB ne supporte ni jointures ni transactions. Toutefois, elle dispose d'indices secondaires, un langage expressif d'interrogation, écritures atomiques sur un niveau par document et lectures entièrement cohérentes.

Sur le plan opérationnel, MongoDB dispose de réplication maître-esclave avec basculement automatisé et intégré dans l'échelle horizontale par partitionnement automatisé basé sur la portée.

	MongoDB utilise BSON, un format objet binaire similaire à JSON, mais plus expressif.

Une base de données MongoDB stocke ses données dans des collections, qui sont l'équivalent approximatif de tables SGBDR. Une collection réunit un ou plusieurs documents, ce qui correspond à un enregistrement ou une ligne dans une table de base de données relationnelle, et chaque document a un ou plusieurs champs, ce qui correspond à une colonne dans une table de base de données relationnelle.

Les collections présentent des différences importantes par rapport aux tables de SGBDR. Les documents d'une seule collection peuvent avoir une combinaison et un ensemble unique de champs. Les documents ne doivent pas nécessairement avoir des champs identiques. Vous pouvez ajouter un champ à certains documents dans une collection sans l'ajouter à tous les documents de la collection.

Voir: Correspondance entre les concepts SQL / MongoDB.

MongoDB utilise les schémas dynamiques. Vous pouvez créer des collections sans en définir la structure des documents, à savoir les champs ou les types valeurs de ceux-ci. Vous pouvez modifier la structure des documents simplement en ajoutant de nouveaux champs ou en supprimant ceux qui existent déjà. Les documents d'une collection ne doivent pas nécessairement avoir un ensemble identique de champs.

Dans la pratique, il est fréquent que les documents dans une collection aient une structure très homogène ; cependant, ce n'est pas obligatoire. Les schémas flexibles de MongoDB signifient que la migration et l'augmentation du schéma sont très faciles dans la pratique, et vous aurez rarement, voire jamais, besoin d'écrire des scripts qui exécutent des opérations de type alter table, ce qui simplifie et facilite le développement de logiciels itératifs avec MongoDB.

Voir: Correspondance entre les concepts SQL / MongoDB.

Des pilotes client existent pour tous les langages de programmation les plus populaires et pour nombreux autres. Regardez la liste de pilotes la plus récente pour plus de détails.

Voir aussi : Pilotes et bibliothèques client MongoDB.

Non.

Cependant, MongoDB prend en charge son propre langage ad hoc de requête, très riche.

Voir aussi : Opérateurs.

MongoDB a une conception polyvalente, ce qui la rend appropriée pour un grand nombre de cas d'utilisation. Les exemples incluent des systèmes de gestion de contenu, applications mobiles, jeux, e-commerce, analytique, archivage et écriture des fichiers journal.

Ne pas utiliser MongoDB pour les systèmes qui nécessitent SQL, jointures et transactions multiobjets.

MongoDB ne supporte pas les transactions multidocuments. Cependant, MongoDB fournit des opérations atomiques sur un seul document.

Pour plus de détails sur les garanties du comportement et isolement de MongoDB sous concurrence, voir Concurrence.

Pas nécessairement. Il est certainement possible de faire fonctionner MongoDB sur une machine avec peu de mémoire vive libre.

MongoDB utilise automatiquement toute la mémoire disponible sur la machine comme son cache. Les moniteurs de ressources du système montrent que MongoDB utilise beaucoup de mémoire, mais son usage est dynamique. Si un autre processus a soudainement besoin de la moitié RAM du serveur, MongoDB cédera la mémoire cache à l'autre processus.

Techniquement, le sous-système virtuel de mémoire du système d'exploitation gère la mémoire de MongoDB. Cela signifie que MongoDB va utiliser autant de mémoire libre qu'elle peut, en commutant sur le disque au besoin. Les déploiements avec assez de mémoire disponible en RAM pour les données de travail de l'application permettront d'atteindre les meilleures performances. Voir aussi Diagnostiquer MongoDB pour des réponses aux questions supplémentaires au sujet de MongoDB et l'utilisation de la mémoire.

MongoDB ne possède pas de cache configurable pour le moteur de stockage MMAPv1. MongoDB utilise toute la mémoire libre sur le système automatiquement par le biais de fichiers mappés en mémoire. Les systèmes d'exploitation utilisent la même approche avec leurs caches du système de fichiers.

Pour le moteur de stockage WiredTiger, vous pouvez spécifier la taille maximale du cache que WiredTiger utilisera pour toutes les données.
Voir storage.wiredTiger.engineConfig.cacheSizeGB et --wiredTigerCacheSizeGB.

Non. Dans MongoDB, la représentation d'un document dans la base de données est similaire à sa représentation dans la mémoire de l'application. Cela signifie que la base de données stocke déjà la forme utilisable de données, rendant les données disponibles à la fois pour stockage permanent et dans le cache de l'application. Ainsi, la nécessité d'une couche de mise en cache séparée dans l'application est éliminée.

Cela diffère de bases de données relationnelles, où la mise en cache des données est plus coûteuse. Les bases de données relationnelles doivent transformer les données en représentations d'objets que les applications peuvent lire et doivent stocker les données transformées dans un cache distincte : si cette transformation des données en objets de l'application nécessite des jointures, ce processus augmente la surcharge liée à l'utilisation de la base de données, ce qui augmente à son tour l'importance de la couche de mise en cache.

Oui. MongoDB maintient toutes les données les plus récemment utilisées dans la RAM. Si vous avez créé des index pour vos requêtes et votre ensemble de données de travail tient dans la RAM, MongoDB sert toutes les requêtes à partir de la mémoire.

MongoDB ne met pas en œuvre un cache de requête : MongoDB sert toutes les requêtes directement à partir des indices et/ou des fichiers de données.

Par défaut, les écritures sont écrites physiquement dans les fichiers journal dans le délai de 100 millisecondes. À ce moment, l'écriture est « durable » dans le sens où après un événement pull-plug-from-wall, les données seront toujours recouvrables après un redémarrage dur. Voir commitIntervalMs pour plus d'informations sur la fenêtre de commit du journal.

Alors que le commit du journal est quasi instantané, MongoDB écrit tardivement dans les fichiers de données. Par défaut, MongoDB peut attendre jusqu'à une minute pour écrire des données dans les fichiers de données. Cela n'affectera pas la durabilité, car le journal a suffisamment d'informations pour assurer la récupération après un crash. Pour changer l'intervalle d'écriture dans les fichiers de données, voir syncPeriodSecs.

MongoDB implémentée en C++. Les pilotes et bibliothèques client sont généralement écrits dans leurs langages respectifs, bien que certains pilotes utilisent des extensions C pour de meilleures performances.

Modification dans la version 3.0 : le support commercial n'est plus fourni pour MongoDB sur les plateformes 32 bits (Linux et Windows). Voir soutien des plateformes.

Les versions 32 bits de MongoDB ne supportent pas le moteur de stockage WiredTiger.

Lors de l'exécution d'une version 32 bits de MongoDB, la taille totale de stockage pour le serveur, y compris les données et les index, est de 2 gigaoctets. Pour cette raison, ne déployez pas MongoDB en production sur des machines 32 bits.

Si vous exécutez une version 64 bits de MongoDB, il n'y a pratiquement pas de limites à la taille de stockage. Pour les déploiements de production, les compilations et les systèmes d'exploitation 64 bits sont fortement recommandés.

Voir aussi : Billet de blog : les limitations des versions 32 bits.

	Les versions 32 bits désactivent par défaut la journalisation, car celle-ci limite encore la quantité maximale de données que la base de données peut stocker.