MongoDB
 sql >> Base de données >  >> NoSQL >> MongoDB

Commit et persistance du disque dans un NoSQL (MongoDB)

Je me demande d'où vient ce mème. D'abord, rien garantit vraiment que tout est écrit sur le disque dur réel à cause de toutes les couches de mise en cache, et même les RDBMS traditionnels n'essayent pas d'écrire dans les fichiers tout le temps, sinon ils ne seraient pas si rapides, mais les détails varient considérablement (voir pour exemple vidage adaptatif dans InnoDB ).

Vous ne devez vous préoccuper que de la première couche qui est essentiellement la question lorsque la base de données essaie d'écrire sur le disque. Il y a maintenant la première couche de mise en cache :au lieu d'écrire dans les tables/collections réelles, de nombreuses bases de données (y compris MongoDB) utilisent la journalisation :écrivez dans un fichier d'ajout uniquement qui sera régulièrement fusionné dans les fichiers de données réels. Dans tout ce qui se passe et c'est dans le journal, ça va.

Maintenant, la question est de savoir si vous voulez écrire au journal et comment le faire. Dans MongoDB, vous pouvez contrôler cela en utilisant le write concern , c'est-à-dire que vous pouvez faire attendre votre code d'application jusqu'à ce que MongoDB ait écrit dans le journal pour une écriture spécifique (ou pour toutes les écritures). Dans MongoDB, l'attente de la validation du journal prend au maximum 10 ms avec la configuration par défaut si le journal et les fichiers de données se trouvent sur des périphériques de bloc différents, 33 ms s'ils se trouvent sur le même périphérique de bloc. Le journalCommitInternval peut également être modifié si nécessaire.

J'ai rassemblé quelques détails sur la journalisation de MongoDB dans une autre réponse .

En passant, la durabilité n'a pas vraiment grand-chose à voir avec les transactions. Les transactions assurent l'isolement et la cohérence, par ex. vous pouvez changer plusieurs choses en une seule fois et les lecteurs sont assurés d'obtenir le nouveau ou l'ancien, mais pas un état intermédiaire. En d'autres termes, une base de données sécurisée pour les transactions pourrait être une base de données en mémoire qui n'écrit pas du tout sur le disque.