La durabilité est le « D » dans les propriétés « ACID » (A - Atomicité, C - Cohérence, I - Isolation), popularisées par les systèmes traditionnels de gestion de bases de données relationnelles (RDBMS). La durabilité est la garantie que les données écrites ont été enregistrées et qu'elles survivront en permanence. Les bases de données NoSQL telles que MongoDB offrent aux développeurs un contrôle précis sur la durabilité de leurs appels d'écriture. Cela permet aux développeurs de choisir différents modèles de durabilité, de sécurité et de performance pour différentes classes de données. Cependant, cela oblige également le développeur à discerner et à comprendre les nuances des différentes options de sécurité en écriture. Dans cet article, nous examinerons les différentes options de sécurité en écriture fournies dans le pilote Java.
Dans le jargon MongoDB, cela s'appelle "Write Concern". Les problèmes d'écriture varient de "faibles" à "forts". Les problèmes d'écriture faibles peuvent entraîner un débit plus élevé, mais offrent moins de sécurité des données et les problèmes d'écriture forts sont vice versa.
Le pilote Java vous permet de spécifier vos options de sécurité en écriture à l'aide de plusieurs constructeurs télescopiques. Voici le constructeur avec toutes les options :
WriteConcern(int w, int wtimeout, boolean fsync, boolean j, boolean continueOnError)
Comme vous pouvez le voir, ce constructeur a beaucoup d'options. Afin de faciliter la tâche des développeurs, des "balises" sont fournies pour les valeurs de préoccupation d'écriture courantes - non acquitté, acquitté, journalisé, Fsynced et Replica Acknowledged. Chaque balise correspond à une certaine invocation du constructeur ci-dessus.
Mode MongoDB non reconnu
C'est le mode "tire et oublie". Le pilote MongoDB ne tente pas d'accuser réception des opérations d'écriture. Par exemple, si votre service MongoDB est en panne et que vous utilisez ce mode, toutes les erreurs sont silencieusement ignorées et vos données sont perdues. Évidemment, vous ne devriez utiliser ce mode que pour les données de faible valeur où le débit d'écriture est plus important que la perte d'une certaine quantité de données. Ce mode peut être spécifié comme suit :
new WriteConcern(0) / WriteConcern.UNACKNOWLEDGED
Mode MongoDB reconnu
Il s'agit du mode d'écriture par défaut pour MongoDB. Dans ce mode, le pilote MongoDB tente d'accuser réception des opérations d'écriture sur le serveur, ce qui permet au pilote de détecter les erreurs de réseau, les erreurs de clés en double, etc. Cependant, cela ne garantit pas que les données sont enregistrées sur le disque. Si le serveur MongoDB tombe en panne après avoir reconnu l'écriture, mais avant de la valider sur le disque, les données sont perdues. Ce mode peut être spécifié comme suit :
new WriteConcern(1) / WriteConcern.ACKNOWLEDGED
Mode MongoDB journalisé
Dans ce mode, le serveur MongoDB ne reconnaît l'écriture qu'après avoir validé les données dans le journal. Lorsque vous utilisez ce mode, même si le serveur tombe en panne au redémarrage du serveur, les données sont réappliquées à partir du journal. Évidemment, la journalisation doit être activée pour que cela fonctionne. Tous les systèmes de production doivent avoir la journalisation activée, et vous pouvez en savoir plus à ce sujet dans notre article Devez-vous activer la journalisation MongoDB ?
Dans un scénario de jeu de réplicas, les problèmes d'écriture de journalisation ne s'appliquent qu'au principal. Par défaut, le journal est validé sur le disque toutes les 100 ms. Lorsque vous spécifiez une écriture avec l'option journaled, le journal est validé sur le disque en 30 ms. Ainsi, si vous spécifiez j:true pour chaque écriture, votre débit sera au maximum de 1000/30 =33,3 écritures/sec. Si vous voulez un meilleur débit, vous devrez regrouper vos mises à jour et définir j:true pour la dernière mise à jour du lot. Ce mode peut être spécifié comme suit :
WriteConcern( 1, 0, false, true ) / WriteConcern.JOURNALLED
Mode MongoDB Fsynced
Dans ce mode, le serveur MongoDB reconnaît l'écriture uniquement après que l'écriture a été écrite sur le disque. Ce mode peut être spécifié comme suit :
new WriteConcern(true) / WriteConcern.FSYNCED
Réplication du mode MongoDB reconnu
Les modes de sécurité en écriture précédents ne s'appliquent qu'à un seul serveur. Lorsque vous exécutez des jeux de répliques, vous avez la possibilité de contrôler le nombre de répliques que votre écriture doit être écrite avant qu'elle ne soit considérée comme réussie. Par exemple, avec une préoccupation d'écriture de "w:2", l'écriture doit être écrite sur un primaire et au moins un secondaire avant d'être considérée comme réussie. Cela réduit le débit mais vous offre une meilleure sécurité. Si vous ne connaissez pas le nombre de répliques à l'avance, vous pouvez utiliser la balise WriteConcern.MAJORITY pour vous assurer que les données sont enregistrées dans la majorité des répliques. C'est l'option la plus sûre dans MongoDB. Si vous envisagez d'utiliser cette option, assurez-vous également de définir la valeur "wtimeout" pour indiquer combien de temps la commande doit attendre avant de renvoyer un échec :
new WriteConcern(2)/ REPLICA_ACKNOWLEDGED new Majority()/ WriteConcern.MAJORITY
Les balises suivantes sont obsolètes (ou prévoient de l'être) :ERRORS_IGNORED, NORMAL, SAFE, FSYNC_SAFE, JOURNAL_SAFE, REPLICAS_SAFE. Veuillez utiliser les nouvelles options au lieu de ces options. Comme toujours, si vous avez des commentaires ou des questions, veuillez nous contacter à [email protected].
