Que signifie réellement le fait que MongoDB n'était pas conforme à la norme ACID avant la version 4 ?

Question

Je ne suis pas un expert en bases de données et je n'ai pas de formation informatique formelle, alors soyez indulgent avec moi. Je veux connaître les types de le monde réel les choses négatives qui peuvent se produire si vous utilisez un vieux Version de MongoDB antérieure à v4 qui n'étaient pas ACID compliant. Cela s'applique à toute base de données non conforme à la norme ACID.

Je comprends que MongoDB peut effectuer Opérations atomiques mais qu'ils ne "prennent pas en charge le verrouillage traditionnel et les transactions complexes", principalement pour des raisons de performances. Je comprends également l'importance des transactions de base de données, et l'exemple de votre base de données pour une banque, et vous mettez à jour plusieurs enregistrements qui doivent tous être synchronisés, vous voulez que la transaction revienne à l'état initial s'il y a une panne de courant afin que le crédit soit égal à l'achat, etc.

Mais lorsque je participe à des conversations sur MongoDB, ceux d'entre nous qui ne connaissent pas les détails techniques de la mise en œuvre des bases de données commencent à lancer des affirmations du type :

MongoDB est bien plus rapide que MySQL et Postgres, mais il y a une infime chance, de l'ordre de 1 sur 1 million, qu'il "n'enregistre pas correctement".

La partie "ne sauvegardera pas correctement" fait référence à cette compréhension : S'il y a une coupure de courant au moment où vous écrivez dans MongoDB, il y a une chance pour un enregistrement particulier (disons que vous suivez les pages vues dans des documents avec 10 attributs chacun), que l'un des documents n'ait enregistré que 5 des attributs ce qui signifie qu'au fil du temps, vos compteurs de pages vues seront "légèrement" erronés. Vous ne saurez jamais de combien, vous savez qu'ils seront corrects à 99,999 %, mais pas à 100 %. C'est parce que, à moins que vous n'ayez spécifiquement fait de cet attribut un élément de votre site Web, vous ne pouvez pas le modifier. opération atomique mongodb l'opération n'est pas garantie comme ayant été atomique.

Ma question est donc la suivante : quelle est l'interprétation correcte de quand et pourquoi MongoDB peut ne pas "enregistrer correctement" ? Quelles sont les parties de l'ACID qu'il ne satisfait pas, et dans quelles circonstances, et comment savez-vous quand ces 0,001 % de vos données sont hors service ? Cela ne peut-il pas être corrigé d'une manière ou d'une autre ? Si ce n'est pas le cas, cela semble signifier que vous ne devriez pas stocker des choses telles que votre fichier users dans MongoDB, car un enregistrement pourrait ne pas être sauvegardé. Mais là encore, ce 1/1 000 000 d'utilisateurs pourrait simplement avoir besoin de "réessayer de s'inscrire", non ?

Je cherche juste à obtenir une liste de quand et pourquoi des choses négatives se produisent avec une base de données non conforme ACID comme MongoDB, et idéalement s'il existe une solution standard (comme exécuter un travail en arrière-plan pour nettoyer les données, ou utiliser uniquement SQL pour cela, etc.)

Answer 1

Il n'est pas exact que MongoDB n'est pas conforme à la norme ACID. Au contraire, MongoDB est ACID-compilant. au niveau du document .

Toute mise à jour d'un document unique est

• Atomique : soit il est entièrement achevé, soit il ne l'est pas.
• Cohérent : aucun lecteur ne verra une mise à jour "partiellement appliquée".
• Isolé : là encore, aucun lecteur ne verra une lecture "sale".
• Durable : (avec le souci d'écriture approprié)

Ce que MongoDB n'a pas transactions -- c'est-à-dire des mises à jour de plusieurs documents qui peuvent être annulées et qui sont conformes à la norme ACID.

Notez que vous pouvez construire des transactions par-dessus les mises à jour conformes à la norme ACID d'un seul document, en utilisant les méthodes suivantes en utilisant le commit biphasé .

Answer 2

Une chose que l'on perd avec MongoDB, ce sont les transactions multi-collections (tables). Les modificateurs atomiques de MongoDB ne peuvent fonctionner que sur un seul document.

Si vous devez retirer un article de l'inventaire et l'ajouter à la commande d'un client en même temps, c'est impossible. À moins que ces deux éléments - inventaire et commandes - n'existent dans le même document (ce qui n'est probablement pas le cas).

J'ai rencontré ce même problème dans une application sur laquelle je travaille et j'avais le choix entre deux solutions possibles :

1) Structurez vos documents du mieux que vous pouvez et utilisez les modificateurs atomiques du mieux que vous pouvez et pour le reste, utilisez un processus de fond pour nettoyer les enregistrements qui peuvent être désynchronisés. Par exemple, je retire des articles de l'inventaire et je les ajoute à un tableau reservedInventory du même document en utilisant des modificateurs atomiques.

Cela me permet de toujours savoir que des articles ne sont PAS disponibles dans l'inventaire (parce qu'ils sont réservés par un client). Lorsque le client passe à la caisse, je retire les articles du reservedInventory. Il ne s'agit pas d'une transaction standard et comme le client peut abandonner son panier, j'ai besoin d'un processus d'arrière-plan pour rechercher les paniers abandonnés et remettre les articles réservés dans le stock disponible.

C'est évidemment loin d'être idéal, mais c'est la seule partie d'une grande application où mongodb ne répond pas parfaitement au besoin. De plus, il fonctionne parfaitement jusqu'à présent. Cela peut ne pas être possible pour de nombreux scénarios, mais en raison de la structure de document que j'utilise, cela convient bien.

2) Utiliser une base de données transactionnelle en conjonction avec MongoDB. Il est courant d'utiliser MySQL pour fournir des transactions pour les choses qui en ont absolument besoin tout en laissant MongoDB (ou tout autre NoSQL) faire ce qu'il fait le mieux.

Si ma solution n°1 ne fonctionne pas à long terme, j'étudierai plus avant la possibilité de combiner MongoDB et MySQL, mais pour l'instant, la solution n°1 répond bien à mes besoins.

Answer 3

Une bonne explication est contenue dans "Starbucks n'utilise pas l'engagement biphasé" .

Il ne s'agit pas de bases de données NoSQL, mais il illustre le fait que, parfois, vous pouvez vous permettre de perdre une transaction ou d'avoir votre base de données dans un état incohérent temporairement.

Je ne considère pas qu'il s'agisse d'un problème qui doit être "résolu". La solution consiste à utiliser une base de données relationnelle conforme à la norme ACID. Vous choisissez une alternative NoSQL lorsque son comportement répond aux exigences de votre application.

Answer 4

Je pense que d'autres personnes ont déjà donné de bonnes réponses. Cependant, je voudrais ajouter qu'il existe des bases de données NOSQL ACID (telles que http://ravendb.net/ ). Il ne s'agit donc pas seulement d'une décision entre NOSQL - sans ACID - et Relationnel avec ACID.....

Answer 5

"ne s'enregistre pas correctement" pourrait signifier :

1. Par défaut, MongoDB n'enregistre pas immédiatement vos modifications sur le disque. Il est donc possible que vous disiez à un utilisateur "la mise à jour est réussie", qu'une panne de courant survienne et que la mise à jour soit perdue. MongoDB propose des options permettant de contrôler le niveau de "durabilité" des mises à jour. Il peut attendre que la ou les autres répliques reçoivent cette mise à jour (en mémoire), attendre que l'écriture se produise dans le fichier journal local, etc.

2. Il n'y a pas de mise à jour "atomique" facile de plusieurs collections et même de plusieurs documents dans la même collection. Ce n'est pas un problème dans la plupart des cas car il peut être contourné avec Engagement biphasé ou de restructurer votre schéma de manière à ce que les mises à jour soient effectuées sur un seul document. Voir cette question : Bases de données de documents : Données redondantes, références, etc. (spécifiquement MongoDB)