Je ne suis pas un expert en bases de données et je n'ai pas d'expérience en informatique, alors soyez indulgent avec moi. Je veux connaître les types de choses négatives du monde réel qui peuvent se produire si vous utilisez une ancienne version de MongoDB avant la v4 , qui n'était pas conforme à ACID . Cela s'applique à toute base de données non conforme ACID.
Je comprends que MongoDB peut effectuer des opérations atomiques , mais qu'il ne "prend 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 lorsque votre base de données est pour une banque, et que vous mettez à jour plusieurs enregistrements qui doivent tous être synchronisés, vous voulez que la transaction revienne à l'état initial s'il y a un panne de courant, donc le crédit est égal à l'achat, etc.
Mais quand j'entre dans des conversations sur MongoDB, ceux d'entre nous qui ne connaissent pas les détails techniques de la façon dont les bases de données sont réellement implémentées commencent à lancer des déclarations comme:
MongoDB est bien plus rapide que MySQL et Postgres, mais il y a une toute petite chance, comme 1 sur un million, qu'il "ne sauvegarde pas correctement".
Cette partie "ne sauvegardera pas correctement" fait référence à cette compréhension: s'il y a une coupure de courant juste au moment où vous écrivez sur MongoDB, il y a une chance pour un enregistrement particulier (disons que vous suivez les pages vues dans les documents avec 10 attributs chacun), que l'un des documents n'a enregistré que 5 des attributs ... ce qui signifie qu'avec le temps, vos compteurs de pages vues seront "légèrement" éteints. Vous ne saurez jamais de combien, vous savez qu'ils seront corrects à 99,999%, mais pas à 100%. En effet, à moins que vous n'en ayez spécifiquement fait une opération atomique mongodb , l'opération n'est pas garantie d'avoir été atomique.
Donc ma question est, quelle est la bonne interprétation de quand et pourquoi MongoDB peut ne pas "enregistrer correctement"? Quelles parties d'ACID ne satisfont-elles pas, et dans quelles circonstances, et comment savoir quand ces 0,001% de vos données sont désactivées? Cela ne peut-il pas être résolu d'une manière ou d'une autre? Sinon, cela semble signifier que vous ne devriez pas stocker des choses comme votre users
table dans MongoDB, car un enregistrement pourrait ne pas être sauvegardé. Mais là encore, cet utilisateur au 1/1 000 000 pourrait simplement avoir besoin de "réessayer de s'inscrire", non?
Je cherche juste peut-être une liste de quand / pourquoi des choses négatives se produisent avec une base de données non conforme ACID comme MongoDB, et idéalement s'il y a une solution de contournement standard (comme exécuter un travail en arrière-plan pour nettoyer les données, ou utiliser uniquement SQL pour cela, etc.) .
Il n'est en fait pas correct que MongoDB ne soit pas compatible ACID. Au contraire, MongoDB est compilateur ACID au niveau du document .
Toute mise à jour d'un document unique est
Ce que MongoDB n'a pas, ce sont les transactions , c'est-à-dire les mises à jour de plusieurs documents qui peuvent être annulées et sont conformes à ACID.
Notez que vous pouvez créer des transactions en plus des mises à jour conformes à ACID dans un seul document, en utilisant la validation en deux phases .
la source
Une bonne explication est contenue dans "Starbucks n'utilise pas la validation en deux phases" .
Il ne s'agit pas de bases de données NoSQL, mais cela illustre le fait que parfois vous pouvez vous permettre de perdre une transaction ou d'avoir temporairement votre base de données dans un état incohérent.
Je ne considérerais pas que c'est quelque chose qui doit être "corrigé". Le correctif consiste à utiliser une base de données relationnelle compatible ACID. Vous choisissez une alternative NoSQL lorsque son comportement répond aux exigences de votre application.
la source
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 ACID NOSQL (comme http://ravendb.net/ ). Ce n'est donc pas seulement la décision NOSQL - pas d'ACID vs Relationnel avec ACID ....
la source
"ne sauvegarde pas correctement" pourrait signifier:
Par défaut, MongoDB n'enregistre pas immédiatement vos modifications sur le lecteur. Il est donc possible que vous disiez à un utilisateur que "la mise à jour a réussi", qu'une coupure de courant se produit et que la mise à jour est perdue. MongoDB fournit des options pour contrôler le niveau de «durabilité» des mises à jour. Il peut attendre que les autres répliques reçoivent cette mise à jour (en mémoire), attendre que l'écriture se produise dans le fichier journal local, etc.
Il n'y a pas de mises à jour "atomiques" faciles pour plusieurs collections et même 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 la validation en deux phases ou la restructuration de votre schéma afin que les mises à jour soient apportées à un seul document. Voir cette question: Bases de données de documents: données redondantes, références, etc. (MongoDB en particulier)
la source
Depuis MongoDB v4.0, les transactions ACID multi-documents doivent être prises en charge. Grâce à l'isolement des instantanés, les transactions fourniront une vue globalement cohérente des données et appliqueront une exécution tout ou rien pour maintenir l'intégrité des données.
Ils se sentent comme des transactions du monde relationnel, par exemple:
Voir https://www.mongodb.com/blog/post/multi-document-transactions-in-mongodb
la source
Veuillez lire les propriétés ACID pour mieux comprendre.
Vous trouverez également dans la documentation MongoDB une question et une réponse .
A
tomique au niveau du document uniquement. Il ne correspond pas à la définition de l'atome que nous connaissons des systèmes de bases de données relationnelles, en particulier le lien ci-dessus. En ce sens, MongoDB n'est pas conforme au A d'ACID.C
présent par défaut. Cependant, vous pouvez lire à partir de serveurs secondaires dans un jeu de réplicas. Vous ne pouvez avoir une cohérence éventuelle que dans ce cas. Ceci est utile si cela ne vous dérange pas de lire des données légèrement obsolètes.I
solation (encore une fois selon la définition ci-dessus):D
urability - vous pouvez configurer ce comportement avec l'write concern
option, pas sûr cependant. Peut-être que quelqu'un sait mieux.Je crois que des recherches sont en cours pour déplacer NoSQL vers des contraintes ACID ou similaires. C'est un défi car les bases de données NoSQL sont généralement plus rapides et les contraintes ACID peuvent ralentir considérablement les performances.
la source
La seule raison pour laquelle atomic modifie le travail par rapport à une seule collection est que les développeurs de mongodb ont récemment échangé un verrou de base de données avec un verrou en écriture pour l'ensemble de la collection. Décider que l'augmentation de la concurrence ici valait le compromis. Au fond, mongodb est un fichier mappé en mémoire: ils ont délégué la gestion du pool de tampons au sous-système vm de la machine. Parce qu'il est toujours en mémoire, ils peuvent s'en tirer avec des verrous très bien définis: vous effectuerez des opérations en mémoire uniquement tout en le maintenant, ce qui sera extrêmement rapide. Cela diffère considérablement d'un système de base de données traditionnel qui est parfois obligé d'effectuer des E / S tout en maintenant un verrou de page ou un verrou de ligne.
la source
"Dans MongoDB, une opération sur un seul document est atomique" - C'est la chose pour le passé
Dans la nouvelle version de MongoDB 4.0, vous POUVEZ:
Bien qu'il y ait peu de limitations pour les opérations Comment et Quoi peuvent être effectuées.
Vérifiez le Mongo Doc. https://docs.mongodb.com/master/core/transactions/
la source
Vous pouvez implémenter des mises à jour atomiques multi-clés (transaction sérialisable) côté client si votre stockage prend en charge la linéarisation par clé et comparer et définir (ce qui est vrai pour MongoDB). Cette approche est utilisée dans Percolator de Google et dans CockroachDB mais rien ne vous empêche de l'utiliser avec MongoDB.
J'ai créé une visualisation étape par étape de ces transactions. J'espère que cela vous aidera à les comprendre.
Si vous êtes d'accord avec le niveau d'isolement validé en lecture, il est logique de jeter un coup d'œil sur les transactions RAMP par Peter Bailis. Ils peuvent également être implémentés pour MongoDB côté client.
la source