Je posterai ceci comme une réponse uniquement pour soutenir la conversation - Tim Mahy , nawroth et CraigTP ont suggéré des bases de données viables. CouchDB serait mon préféré en raison de l'utilisation d' Erlang , mais il en existe d'autres.
Je dirais que ACID ne contredit ni ne nie le concept de NoSQL ... Bien qu'il semble y avoir une tendance suivant l'opinion exprimée par Dove , je dirais que les concepts sont distincts.
NoSQL concerne fondamentalement un schéma clé-valeur simple (par exemple Redis) ou un schéma de style document (paires clé-valeur collectées dans un modèle "document", par exemple MongoDB) comme alternative directe au schéma explicite dans les SGBDR classiques. Cela permet au développeur de traiter les choses asymétrique, alors que les moteurs traditionnels ont imposé la même rigueur dans le modèle de données. La raison pour laquelle cela est si intéressant est que cela fournit une manière différente de gérer le changement et que pour des ensembles de données plus volumineux, cela offre des opportunités intéressantes de gérer les volumes et les performances.
ACID fournit des principes régissant la manière dont les modifications sont appliquées à une base de données. De manière très simplifiée, il déclare (ma propre version):
(A) lorsque vous faites quelque chose pour modifier une base de données, le changement devrait fonctionner ou échouer dans son ensemble
(C) la base de données doit rester cohérente (c'est un sujet assez large)
(I) si d'autres choses se passent en même temps, ils ne devraient pas pouvoir voir les choses à mi-mise à jour
(D) si le système explose (matériel ou logiciel), la base de données doit être en mesure de se reprendre; et s'il dit qu'il a terminé d'appliquer une mise à jour, il doit être certain
La conversation devient un peu plus excitante en ce qui concerne l'idée de propagation et de contraintes . Certains moteurs SGBDR offrent la possibilité d'appliquer des contraintes (par exemple des clés étrangères) qui peuvent avoir des éléments de propagation (à la cascade ). En termes plus simples, une "chose" peut avoir une relation avec une autre "chose" dans la base de données, et si vous changez un attribut de l'un, cela peut nécessiter que l'autre soit changé (mis à jour, supprimé, ... beaucoup d'options). Les bases de données NoSQL , étant principalement (pour le moment) axées sur des volumes de données élevés et un trafic élevé, semblent s'attaquer à l'idée de mises à jour distribuées qui ont lieu dans (du point de vue du consommateur) des délais arbitraires. Il s'agit essentiellement d'une forme spécialisée de réplication gérée viatransaction - donc je dirais que si une base de données distribuée traditionnelle peut prendre en charge ACID, une base de données NoSQL le peut aussi.
Bonne réponse. Vous pouvez avoir à la fois NoSQL + ACID et non-ACID-RDBMS (pensez à MySQL + MyISAM). Je considère généralement NoSQL comme "finalement cohérent". Je vais aussi ajouter le théorème CAP ... :-)
gbn
+1 @gbn pour la mention du théorème CAP. Être plus familier avec les bases de données "nosql" maintenant que je ne l'étais alors n'a fait que renforcer la séparation des concepts. De plus, les bases de données clé-valeur vs doc, car il existe des différences architecturales.
MISE À JOUR (27 juillet 2012): Le lien vers l'article Wikipédia a été mis à jour pour refléter la version de l'article qui était en cours lorsque cette réponse a été publiée. Veuillez noter que l'article actuel de Wikipédia a été largement révisé!
NoSQL est un mouvement promouvant une classe vaguement définie de magasins de données non relationnelles qui rompent avec une longue histoire de bases de données relationnelles et de garanties ACID.
et aussi:
Le nom était une tentative pour décrire l'émergence d'un nombre croissant de magasins de données non relationnels et distribués qui souvent n'essayaient pas de fournir des garanties ACID.
et
Les systèmes NoSQL fournissent souvent des garanties de cohérence faibles telles que la cohérence éventuelle et les transactions limitées à des éléments de données uniques, même si l'on peut imposer des garanties ACID complètes en ajoutant une couche middleware supplémentaire.
Donc, en un mot, je dirais que l'un des principaux avantages d'un magasin de données "NoSQL" est son manque distinct de propriétés ACID . De plus, à mon humble avis, plus on essaie d'implémenter et d'appliquer les propriétés ACID , plus vous vous éloignez de «l'esprit» d'un magasin de données «NoSQL», et plus vous vous rapprochez d'un «vrai» SGBDR (relativement parlant, bien sûr ).
Cependant, tout cela dit, "NoSQL" est un terme très vague et ouvert à des interprétations individuelles, et dépend fortement de votre point de vue puriste. Par exemple, la plupart des systèmes SGBDR modernes ne respectent pas vraiment à tous d' Edgar F. Codd de 12 règles de son modèle de relation !
En adoptant une approche pragmatique, il semblerait que CouchDB d'Apache se rapproche le plus de l'incarnation à la fois de la conformité ACID tout en conservant la mentalité "NoSQL" faiblement couplée et non relationnelle.
+1 Je ne suis pas sûr d'être d'accord avec le fait que l'absence d'ACID soit une caractéristique clé de "NoSQL", mais j'apprécie vraiment votre écriture. En fin de compte, il devrait s'agir d'une solution qui convient.
AJ.
2
J'ai édité (en attente d'examen) pour essayer de rendre encore plus clair. Rien dans les modèles de données NoSQL n'implique que les transactions ACID ne sont pas possibles. Certains systèmes distribués NoSQL n'en ont pas. Certains se passent en fait de toute "couche middleware".
Eric Bloch
2
Cela n'a jamais été correct et a même perdu sa source. Il devrait vraiment être supprimé.
Lennart Regebro
2
Eh bien, de manière plus flagrante, ceci: "en un mot, je dirais que l'un des principaux avantages d'un magasin de données" NoSQL "est son manque flagrant de propriétés ACID." Vous impliquez également que NoSQL et ACID s'excluent mutuellement, ce qui est définitivement incorrect. C'est un bon exemple de cas où un grand nombre de personnes ignorantes votent pour une mauvaise réponse parce que cela semble raisonnable. Le fait que la plupart des bases de données NoSQL ne sont pas compatibles ACID est principalement dû au fait que les personnes qui l'ont implémentée ne savaient pas ce que c'était / pourquoi c'était important / s'en moquaient.
Lennart Regebro
@LennartRegebro - Je n'ai rien dit de tel. La conformité ACID a en effet été évitée par la plupart des bases de données NoSQL actuelles et existantes au profit de la vitesse / performance et de la cohérence éventuelle. Cependant, je n'ai jamais dit que vous ne pouviez pas avoir NoSQL avec la conformité ACID.
Tout d'abord, nous pouvons distinguer deux types de bases de données NoSQL:
Bases de données axées sur les agrégats;
Bases de données orientées graph (par exemple Neo4J).
De par leur conception, la plupart des bases de données orientées Graph sont ACID !
Alors, qu'en est-il des autres types?
Dans les bases de données orientées agrégats, nous pouvons mettre trois sous-types:
Bases de données NoSQL basées sur des documents (par exemple MongoDB, CouchDB);
Bases de données NoSQL clé / valeur (par exemple Redis);
Bases de données NoSQL de la famille de colonnes (par exemple Hibase, Cassandra).
Ce que nous appelons ici un agrégat , c'est ce qu'Eric Evans a défini dans sa conception pilotée par domaine comme une autosuffisance d'entités et d'objets de valeur dans un contexte délimité donné.
Par conséquent, un agrégat est une collection de données avec lesquelles nous interagissons en tant qu'unité. Les agrégats forment les limites des opérations ACID avec la base de données. (Martin Fowler)
Ainsi, au niveau agrégé, nous pouvons dire que la plupart des bases de données NoSQL peuvent être aussi sûres que le SGBDR ACID , avec les paramètres appropriés. De source, si vous réglez votre serveur pour la meilleure vitesse, vous pouvez entrer dans quelque chose de non ACID. Mais la réplication aidera.
Mon point principal est que vous devez utiliser les bases de données NoSQL telles quelles, et non comme une alternative (bon marché) au SGBDR. J'ai vu trop de projets abuser des relations entre documents. Cela ne peut pas être ACIDE. Si vous restez au niveau du document, c'est-à-dire aux limites agrégées, vous n'avez besoin d'aucune transaction. Et vos données seront aussi sûres qu'avec une base de données ACID, même si ce n'est pas vraiment ACID, puisque vous n'avez pas besoin de ces transactions! Si vous avez besoin de transactions et de mettre à jour plusieurs "documents" à la fois, vous n'êtes plus dans le monde NoSQL - utilisez donc un moteur SGBDR à la place!
une mise à jour 2019: à partir de la version 4.0, pour les situations qui nécessitent l'atomicité pour les mises à jour de plusieurs documents ou la cohérence entre les lectures de plusieurs documents, MongoDB fournit des transactions multi-documents pour les jeux de répliques .
Il y a des cas où il y a un grand processus / saga qui gère de nombreux agrégats. Il existe des cas où une commande envoyée à un agrégat peut déclencher des événements qui modifient d'autres agrégats. Dans ces cas, vous avez besoin de magasins de données compatibles ACID.
Tudor
1
@TudorTudor mais dans ce cas, vous enfreignez l'un des principes nosql, puisque vous l'utilisez comme rdbms. Vous avez juste besoin de plus gros agrégats ou de versions des documents (comme dans couchdb). Les bases de données orientées document Nosql sont acides aux limites des documents / agrégats.
Arnaud Bouchez
Aucun de ceux que vous énumérez n'est compatible avec l'acide. Mongo possède juste qu'il n'est pas conforme à l'ACID. CouchDB prétend qu'il est compatible avec l'acide tant que vous ne mettez pas à jour deux documents. Redis n'a qu'un "support partiel pour les transactions". La HBase n'est pas compatible avec l'acide (des développeurs) , pas plus que Cassandra. Cette réponse est en fait tout simplement fausse. Aucune de ces bases de données ne prend en charge ACID, et la plupart d'entre elles le possèdent ouvertement avec une simple recherche Google.
Evan Carroll le
@EvanCarroll Je n'ai jamais écrit que MongoDB est compatible ACID, dans le même sens qu'avec une transaction ACID RDBMS. Aucune transaction n'est disponible. Ce que j'ai écrit, c'est que la plupart des bases de données NoSQL peuvent être aussi sûres que ACID RDBMS, avec les paramètres appropriés . Par exemple, vérifiez l' opérateur MongoDB $ isolated pour une base de données sans cluster partagé. Je n'utiliserais jamais MongoDB pour le processus financier, mais je pourrais faire confiance à son processus d'écriture dans une certaine mesure, pour des opérations de type ACID, si le A pour Atomicity est suffisant. Désolé si ma réponse prête à confusion.
Il a des transactions appropriées, de sorte que vous pouvez mettre à jour plusieurs éléments de données disparates de manière ACID. Ceci est utilisé comme base pour maintenir les index à une couche supérieure.
malheureusement ce n'est pas open source. Mais cela ressemble à une très belle base de données.
Kevin Cox
Pour ajouter à la réponse @ Ken-Tindell, djondb est également NoSQL et implémente les transactions et il est compatible ACID. djondb.com Je suis d'accord que NoSQL est juste un terme pour inventer toutes les bases de données qui ne suivent pas les règles traditionnelles du SGBDR, cela ne signifie pas "se débarrasser des systèmes TX", ou oublier les relations.
Traverser
3
Ma réponse a été rendue sans objet par l'acquisition par Apple de Foundation DB.
Ken Tindell
1
foundationdb est maintenant open sources par Apple
RBanerjee
17
Dans cette question, quelqu'un doit mentionner OrientDB : OrientDB est une base de données NoSQL, l'une des rares, qui supporte entièrement les transactions ACID. ACID n'est pas uniquement destiné au SGBDR car il ne fait pas partie de l'algèbre relationnelle. Il est donc possible d'avoir une base de données NoSQL prenant en charge ACID.
Cette fonctionnalité est celle qui me manque le plus dans MongoDB
ACID et NoSQL sont complètement orthogonaux. L'un n'implique pas l'autre.
J'ai un cahier sur mon bureau, je l'utilise pour prendre des notes sur les choses que j'ai encore à faire. Ce notebook est une base de données NoSQL. Je l'interroge en utilisant une recherche linéaire avec un "cache de page" donc je n'ai pas toujours à rechercher chaque page. Il est également compatible ACID car je m'assure que je n'écris qu'une seule chose à la fois et jamais pendant que je la lis.
NoSQL signifie simplement que ce n'est pas SQL. Beaucoup de gens sont confus et pensent que cela signifie un stockage ultra-rapide hautement évolutif. Ce n'est pas le cas. Cela ne signifie pas stockage clé-valeur ou cohérence éventuelle. Tout ce que cela signifie est "pas SQL", il y a beaucoup de bases de données sur cette planète et la plupart d'entre elles ne sont pas SQL [citation nécessaire] .
Vous pouvez trouver de nombreux exemples dans les autres réponses, donc je n'ai pas besoin de les énumérer ici, mais il existe des bases de données non SQL avec conformité ACID pour diverses opérations, certaines ne sont ACID que pour les écritures d'objet unique tandis que certaines garantissent beaucoup plus. Chaque base de données est différente.
Juste pour être pédant mais cela signifie généralement 'Pas seulement SQL' :-)
shmish111
4
@ shmish111 pas vraiment. Cela signifiait "No SQL" lorsque le terme a été inventé pour la première fois. Le "o" est petit, pas capital après tout. Il y a eu des tentatives plus tard pour recointer le terme en tant que "Not Only SQL" lorsque certains de ces (produits NoSQL) ont commencé à ajouter des interfaces de langage de requête de type SQL.
ypercubeᵀᴹ
11
«NoSQL» n'est pas un terme bien défini. C'est un concept très vague. En tant que tel, il n'est même pas possible de dire ce qui est et ce qui n'est pas un produit "NoSQL". Presque tous les produits typiquement marqués avec l'étiquette ne sont pas des magasins à valeur clé.
Meilleure réponse. Chaque fois que cette guerre de flammes survient, j'aime demander à l'autre partie quelles fonctionnalités déterminantes elles nécessitent explicitement d'une base de données NoSQL et souvent elles chevauchent des fonctionnalités qu'elles peuvent trouver dans un SGBDR - non pas parce qu'un ou plusieurs SGBDR correspondent au thème NoSQL mais simplement parce que leur Les «exigences» des fonctionnalités sont si vagues qu'elles n'annulent pas complètement les fonctionnalités trouvées dans (pas nécessairement toutes) les RDMBS. +1 pour votre compagnon de commentaire!
StartupGuy
8
Oui, MarkLogic Server est une solution NoSQL (base de données de documents que j'aime l'appeler) qui fonctionne avec les transactions ACID
MarkLogic propose des transactions ACID, des transactions multi-documents, des transactions multi-relevés et une prise en charge de XA - le tout à l'échelle du cluster / distribué.
Pour ceux qui cherchent à passer de la bibliothèque "shelve" de python, j'ai trouvé que ZODB était presque sans apparence. Je n'ai pas eu besoin de réécrire toutes mes fonctions - accédez simplement à ZODB en tant que dictionnaire, tout comme shelve, mais c'est un ordre de grandeur plus rapide.
Michael Galaxy
8
En tant que l'un des initiateurs de NoSQL (j'ai été l'un des premiers contributeurs à Apache CouchDB et un conférencier lors du premier événement NoSQL organisé à CBS Interactive / CNET en 2009), je suis ravi de voir de nouveaux algorithmes créer des possibilités qui n'existaient pas auparavant. . Le protocole Calvin offre une nouvelle façon de penser les contraintes physiques comme CAP et PACELC .
Au lieu de la réplication asynchrone active / passive ou de la réplication synchrone active / active, Calvin préserve l'exactitude et la disponibilité pendant les pannes de réplica en utilisant un protocole de type RAFT pour maintenir un journal des transactions. De plus, les transactions sont traitées de manière déterministe au niveau de chaque réplica, ce qui élimine le potentiel de blocage, de sorte qu'un accord est obtenu avec un seul cycle de consensus. Cela le rend rapide même sur les déploiements multi-cloud dans le monde entier.
FaunaDB est la seule implémentation de base de données utilisant le protocole Calvin, ce qui le rend particulièrement adapté aux charges de travail qui nécessitent une intégrité des données de type mainframe avec une évolutivité et une flexibilité NoSQL.
Si vous recherchez un magasin de clés / valeurs compatible ACID, il y a Berkeley DB . Parmi les bases de données de graphes, au moins Neo4j et HyperGraphDB offrent des transactions ACID (HyperGraphDB utilise actuellement Berkeley DB pour le stockage de bas niveau).
[…] Une classe de systèmes modernes de gestion de bases de données relationnelles qui cherchent à fournir les mêmes performances évolutives que les systèmes NoSQL pour les charges de travail en lecture-écriture de traitement des transactions en ligne (OLTP) tout en conservant les garanties ACID d'un système de base de données traditionnel.[1][2][3]
Oui, les transactions ACID multi-documents sont désormais prises en charge dans MongoDB. Voir mongodb.com/transactions pour plus d'informations et des vidéos approfondies sur la façon dont elles ont été mises en œuvre.
Contrairement à la persistance ou à la sérialisation roll-your-own, db4o est sécurisé pour les transactions ACID et permet d'interroger, de répliquer et de modifier le schéma pendant l'exécution
Tarantool est une base de données NoSQL entièrement ACID. Vous pouvez émettre des opérations CRUD ou des procédures stockées, tout sera exécuté en stricte conformité avec une propriété ACID. Vous pouvez également lire à ce sujet ici: http://stable.tarantool.org/doc/mpage/data-and-persistence.html
Aerospike prend-il en charge les transactions ACID à plusieurs clés? AKAIK est limité aux transactions à clé unique.
eonil
1
BergDB est une base de données NoSQL légère et open source conçue dès le départ pour exécuter des transactions ACID. En fait, BergDB est "plus" ACID que la plupart des bases de données SQL en ce sens que la seule façon de changer l'état de la base de données est d'exécuter des transactions ACID avec le niveau d'isolation le plus élevé (terme SQL: "sérialisable"). Il n'y aura jamais de problèmes avec les lectures sales, les lectures non répétables ou les lectures fantômes.
À mon avis, la base de données est toujours très performante; mais ne me faites pas confiance, j'ai créé le logiciel. Essayez-le à la place.
De nombreuses solutions NoSQL modernes ne prennent pas en charge les transactions ACID (mises à jour à plusieurs clés isolées atomiques), mais la plupart d'entre elles prennent en charge des primitives qui vous permettent d'implémenter des transactions au niveau de l'application.
Si un magasin de données prend en charge la linéarisation par clé et comparer et définir (atomicité au niveau du document), il suffit de mettre en œuvre des transactions côté client, de plus, vous avez le choix entre plusieurs options:
Si vous avez besoin d'un niveau d'isolement sérialisable, vous pouvez suivre le même algorithme que Google utilise pour le système Percolator ou Cockroach Labs for CockroachDB . J'ai blogué à ce sujet et créé une visualisation étape par étape , j'espère que cela vous aidera à comprendre l'idée principale derrière l'algorithme.
Si vous vous attendez à un conflit élevé, mais que vous avez le niveau d'isolement Read Committed, jetez un œil aux transactions RAMP de Peter Bailis.
La troisième approche consiste à utiliser des transactions compensatoires également connues sous le nom de modèle de saga. Il a été décrit à la fin des années 80 dans l' article de Sagas mais est devenu plus actuel avec la montée en puissance des systèmes distribués. Veuillez consulter la présentation sur l' application du modèle Saga pour vous inspirer.
La liste des magasins de données adaptés aux transactions côté client comprend Cassandra avec des transactions légères, Riak avec des compartiments cohérents, RethinkDB, ZooKeeper, Etdc, HBase, DynamoDB, MongoDB et autres.
Le créateur de VoltDB a mentionné qu'ils ne se étiquetaient pas comme NoSql mais plutôt comme NewSql (utilisant toujours Sql mais avec une meilleure implémentation que ces RDBM construits dans les années quatre-vingt)
Matt W
0
Bien qu'il ne s'agisse que d' un moteur intégré et non d'un serveur, leveldb a WriteBatch et la possibilité d'activer les écritures synchrones pour fournir un comportement ACID.
Non seulement NoSQL n'est pas conforme à ACID de par sa conception. Le mouvement NoSQL embrasse la BASE (Basically Available, Soft state, Eventual cohérence) prétendument l'opposé d'ACID. Les bases de données NoSQL sont souvent appelées bases de données éventuellement constituées. Pour comprendre les différences, vous devez approfondir le théorème CAP (alias le théorème de Brewer)
Je pense que le pointeur sur le théorème CAP est très pertinent pour cette question!
mxro
2
Certaines bases de données NoSQL ont des transactions ACID.
Eric Bloch
1
Certains prétendent NoSQL être compatible ACID mais quand u percer à l' intérieur , vous découvrez que seulement dans certains cas particuliers qu'ils sont ACIDE si à mon humble avis qu'il n'y a pas « à terme ACID » ils ne sont certainement pas ACID
Ste
1
Vous appliquez fondamentalement le CAP. Au mieux, CAP et ACID sont vaguement liés, mais CAP n'empêche pas un système distribué d'être conforme à l'ACID. CAP décrit les compromis nécessaires d'un système distribué - un système NoSQL qui est fortement cohérent peut ne pas être disponible pendant une partition, mais cela ne l'empêche pas d'être conforme à ACID.
Réponses:
Je posterai ceci comme une réponse uniquement pour soutenir la conversation - Tim Mahy , nawroth et CraigTP ont suggéré des bases de données viables. CouchDB serait mon préféré en raison de l'utilisation d' Erlang , mais il en existe d'autres.
Je dirais que ACID ne contredit ni ne nie le concept de NoSQL ... Bien qu'il semble y avoir une tendance suivant l'opinion exprimée par Dove , je dirais que les concepts sont distincts.
NoSQL concerne fondamentalement un schéma clé-valeur simple (par exemple Redis) ou un schéma de style document (paires clé-valeur collectées dans un modèle "document", par exemple MongoDB) comme alternative directe au schéma explicite dans les SGBDR classiques. Cela permet au développeur de traiter les choses asymétrique, alors que les moteurs traditionnels ont imposé la même rigueur dans le modèle de données. La raison pour laquelle cela est si intéressant est que cela fournit une manière différente de gérer le changement et que pour des ensembles de données plus volumineux, cela offre des opportunités intéressantes de gérer les volumes et les performances.
ACID fournit des principes régissant la manière dont les modifications sont appliquées à une base de données. De manière très simplifiée, il déclare (ma propre version):
La conversation devient un peu plus excitante en ce qui concerne l'idée de propagation et de contraintes . Certains moteurs SGBDR offrent la possibilité d'appliquer des contraintes (par exemple des clés étrangères) qui peuvent avoir des éléments de propagation (à la cascade ). En termes plus simples, une "chose" peut avoir une relation avec une autre "chose" dans la base de données, et si vous changez un attribut de l'un, cela peut nécessiter que l'autre soit changé (mis à jour, supprimé, ... beaucoup d'options). Les bases de données NoSQL , étant principalement (pour le moment) axées sur des volumes de données élevés et un trafic élevé, semblent s'attaquer à l'idée de mises à jour distribuées qui ont lieu dans (du point de vue du consommateur) des délais arbitraires. Il s'agit essentiellement d'une forme spécialisée de réplication gérée viatransaction - donc je dirais que si une base de données distribuée traditionnelle peut prendre en charge ACID, une base de données NoSQL le peut aussi.
Quelques ressources pour en savoir plus:
la source
MISE À JOUR (27 juillet 2012): Le lien vers l'article Wikipédia a été mis à jour pour refléter la version de l'article qui était en cours lorsque cette réponse a été publiée. Veuillez noter que l'article actuel de Wikipédia a été largement révisé!
Eh bien, selon une ancienne version d'un article de Wikipedia sur NoSQL :
et aussi:
et
Donc, en un mot, je dirais que l'un des principaux avantages d'un magasin de données "NoSQL" est son manque distinct de propriétés ACID . De plus, à mon humble avis, plus on essaie d'implémenter et d'appliquer les propriétés ACID , plus vous vous éloignez de «l'esprit» d'un magasin de données «NoSQL», et plus vous vous rapprochez d'un «vrai» SGBDR (relativement parlant, bien sûr ).
Cependant, tout cela dit, "NoSQL" est un terme très vague et ouvert à des interprétations individuelles, et dépend fortement de votre point de vue puriste. Par exemple, la plupart des systèmes SGBDR modernes ne respectent pas vraiment à tous d' Edgar F. Codd de 12 règles de son modèle de relation !
En adoptant une approche pragmatique, il semblerait que CouchDB d'Apache se rapproche le plus de l'incarnation à la fois de la conformité ACID tout en conservant la mentalité "NoSQL" faiblement couplée et non relationnelle.
la source
Veuillez vous assurer de lire l'introduction de Martin Fowler sur les bases de données NoSQL . Et la vidéo correspondante.
Tout d'abord, nous pouvons distinguer deux types de bases de données NoSQL:
De par leur conception, la plupart des bases de données orientées Graph sont ACID !
Alors, qu'en est-il des autres types?
Dans les bases de données orientées agrégats, nous pouvons mettre trois sous-types:
Ce que nous appelons ici un agrégat , c'est ce qu'Eric Evans a défini dans sa conception pilotée par domaine comme une autosuffisance d'entités et d'objets de valeur dans un contexte délimité donné.
Ainsi, au niveau agrégé, nous pouvons dire que la plupart des bases de données NoSQL peuvent être aussi sûres que le SGBDR ACID , avec les paramètres appropriés. De source, si vous réglez votre serveur pour la meilleure vitesse, vous pouvez entrer dans quelque chose de non ACID. Mais la réplication aidera.
Mon point principal est que vous devez utiliser les bases de données NoSQL telles quelles, et non comme une alternative (bon marché) au SGBDR. J'ai vu trop de projets abuser des relations entre documents. Cela ne peut pas être ACIDE. Si vous restez au niveau du document, c'est-à-dire aux limites agrégées, vous n'avez besoin d'aucune transaction. Et vos données seront aussi sûres qu'avec une base de données ACID, même si ce n'est pas vraiment ACID, puisque vous n'avez pas besoin de ces transactions! Si vous avez besoin de transactions et de mettre à jour plusieurs "documents" à la fois, vous n'êtes plus dans le monde NoSQL - utilisez donc un moteur SGBDR à la place!
une mise à jour 2019: à partir de la version 4.0, pour les situations qui nécessitent l'atomicité pour les mises à jour de plusieurs documents ou la cohérence entre les lectures de plusieurs documents, MongoDB fournit des transactions multi-documents pour les jeux de répliques .
la source
FoundationDB est conforme ACID:
http://www.foundationdb.com/
Il a des transactions appropriées, de sorte que vous pouvez mettre à jour plusieurs éléments de données disparates de manière ACID. Ceci est utilisé comme base pour maintenir les index à une couche supérieure.
la source
Dans cette question, quelqu'un doit mentionner OrientDB : OrientDB est une base de données NoSQL, l'une des rares, qui supporte entièrement les transactions ACID. ACID n'est pas uniquement destiné au SGBDR car il ne fait pas partie de l'algèbre relationnelle. Il est donc possible d'avoir une base de données NoSQL prenant en charge ACID.
Cette fonctionnalité est celle qui me manque le plus dans MongoDB
la source
ACID et NoSQL sont complètement orthogonaux. L'un n'implique pas l'autre.
J'ai un cahier sur mon bureau, je l'utilise pour prendre des notes sur les choses que j'ai encore à faire. Ce notebook est une base de données NoSQL. Je l'interroge en utilisant une recherche linéaire avec un "cache de page" donc je n'ai pas toujours à rechercher chaque page. Il est également compatible ACID car je m'assure que je n'écris qu'une seule chose à la fois et jamais pendant que je la lis.
NoSQL signifie simplement que ce n'est pas SQL. Beaucoup de gens sont confus et pensent que cela signifie un stockage ultra-rapide hautement évolutif. Ce n'est pas le cas. Cela ne signifie pas stockage clé-valeur ou cohérence éventuelle. Tout ce que cela signifie est "pas SQL", il y a beaucoup de bases de données sur cette planète et la plupart d'entre elles ne sont pas SQL [citation nécessaire] .
Vous pouvez trouver de nombreux exemples dans les autres réponses, donc je n'ai pas besoin de les énumérer ici, mais il existe des bases de données non SQL avec conformité ACID pour diverses opérations, certaines ne sont ACID que pour les écritures d'objet unique tandis que certaines garantissent beaucoup plus. Chaque base de données est différente.
la source
«NoSQL» n'est pas un terme bien défini. C'est un concept très vague. En tant que tel, il n'est même pas possible de dire ce qui est et ce qui n'est pas un produit "NoSQL". Presque tous les produits typiquement marqués avec l'étiquette ne sont pas des magasins à valeur clé.
la source
Oui, MarkLogic Server est une solution NoSQL (base de données de documents que j'aime l'appeler) qui fonctionne avec les transactions ACID
la source
Le grand-père de NoSQL: ZODB est compatible ACID. http://www.zodb.org/
Cependant, c'est uniquement Python.
la source
En tant que l'un des initiateurs de NoSQL (j'ai été l'un des premiers contributeurs à Apache CouchDB et un conférencier lors du premier événement NoSQL organisé à CBS Interactive / CNET en 2009), je suis ravi de voir de nouveaux algorithmes créer des possibilités qui n'existaient pas auparavant. . Le protocole Calvin offre une nouvelle façon de penser les contraintes physiques comme CAP et PACELC .
Au lieu de la réplication asynchrone active / passive ou de la réplication synchrone active / active, Calvin préserve l'exactitude et la disponibilité pendant les pannes de réplica en utilisant un protocole de type RAFT pour maintenir un journal des transactions. De plus, les transactions sont traitées de manière déterministe au niveau de chaque réplica, ce qui élimine le potentiel de blocage, de sorte qu'un accord est obtenu avec un seul cycle de consensus. Cela le rend rapide même sur les déploiements multi-cloud dans le monde entier.
FaunaDB est la seule implémentation de base de données utilisant le protocole Calvin, ce qui le rend particulièrement adapté aux charges de travail qui nécessitent une intégrité des données de type mainframe avec une évolutivité et une flexibilité NoSQL.
la source
Si vous recherchez un magasin de clés / valeurs compatible ACID, il y a Berkeley DB . Parmi les bases de données de graphes, au moins Neo4j et HyperGraphDB offrent des transactions ACID (HyperGraphDB utilise actuellement Berkeley DB pour le stockage de bas niveau).
la source
NewSQL
Ce concept que les contributeurs de Wikipédia définissent comme suit:
Références
[1]Nancy Lynch et Seth Gilbert, «La conjecture de Brewer et la faisabilité de services Web cohérents, disponibles et tolérants aux partitions» , ACM SIGACT News, Volume 33 Numéro 2 (2002), p. 51-59.[2]"Brewer's CAP Theorem" , julianbrowne.com, récupéré le 2 mars 2010[3]"Théorème du CAP Brewers sur les systèmes distribués" , royans.netla source
MongoDB a annoncé que sa version 4.0 sera compatible ACID pour les transactions multi-documents.
Version 4.2. est censé le supporter dans des configurations fragmentées.
https://www.mongodb.com/blog/post/multi-document-transactions-in-mongodb
la source
FoundationDB a été mentionné et à l'époque ce n'était pas open source. Il a été open source par Apple il y a deux jours: https://www.foundationdb.org/blog/foundationdb-is-open-source/
Je pense qu'il est conforme à l'ACID.
la source
jetez un œil au théorème CAP
EDIT: RavenDB semble être conforme à ACID
la source
Pour ajouter à la liste des alternatives, une autre base de données NoSQL entièrement compatible ACID est GT.M .
la source
Hyperdex Warp http://hyperdex.org/warp/ Warp (fonction ACID) est propriétaire, mais Hyperdex est gratuit.
la source
db4o
http://www.db4o.com/about/productinformation/db4o/
la source
Tarantool est une base de données NoSQL entièrement ACID. Vous pouvez émettre des opérations CRUD ou des procédures stockées, tout sera exécuté en stricte conformité avec une propriété ACID. Vous pouvez également lire à ce sujet ici: http://stable.tarantool.org/doc/mpage/data-and-persistence.html
la source
MarkLogic est également compatible ACID. Je pense que c'est l'un des plus gros joueurs actuellement.
la source
Attendez, c'est fini.
La base de données NoSQL compatible ACID est sortie ----------- Jetez un œil à Citrusleaf
la source
BergDB est une base de données NoSQL légère et open source conçue dès le départ pour exécuter des transactions ACID. En fait, BergDB est "plus" ACID que la plupart des bases de données SQL en ce sens que la seule façon de changer l'état de la base de données est d'exécuter des transactions ACID avec le niveau d'isolation le plus élevé (terme SQL: "sérialisable"). Il n'y aura jamais de problèmes avec les lectures sales, les lectures non répétables ou les lectures fantômes.
À mon avis, la base de données est toujours très performante; mais ne me faites pas confiance, j'ai créé le logiciel. Essayez-le à la place.
la source
De nombreuses solutions NoSQL modernes ne prennent pas en charge les transactions ACID (mises à jour à plusieurs clés isolées atomiques), mais la plupart d'entre elles prennent en charge des primitives qui vous permettent d'implémenter des transactions au niveau de l'application.
Si un magasin de données prend en charge la linéarisation par clé et comparer et définir (atomicité au niveau du document), il suffit de mettre en œuvre des transactions côté client, de plus, vous avez le choix entre plusieurs options:
Si vous avez besoin d'un niveau d'isolement sérialisable, vous pouvez suivre le même algorithme que Google utilise pour le système Percolator ou Cockroach Labs for CockroachDB . J'ai blogué à ce sujet et créé une visualisation étape par étape , j'espère que cela vous aidera à comprendre l'idée principale derrière l'algorithme.
Si vous vous attendez à un conflit élevé, mais que vous avez le niveau d'isolement Read Committed, jetez un œil aux transactions RAMP de Peter Bailis.
La troisième approche consiste à utiliser des transactions compensatoires également connues sous le nom de modèle de saga. Il a été décrit à la fin des années 80 dans l' article de Sagas mais est devenu plus actuel avec la montée en puissance des systèmes distribués. Veuillez consulter la présentation sur l' application du modèle Saga pour vous inspirer.
La liste des magasins de données adaptés aux transactions côté client comprend Cassandra avec des transactions légères, Riak avec des compartiments cohérents, RethinkDB, ZooKeeper, Etdc, HBase, DynamoDB, MongoDB et autres.
la source
YugaByte DB prend en charge un txns distribué conforme ACID ainsi que la compatibilité Redis et CQL API sur la couche de requête.
la source
VoltDB est un entrant qui revendique la conformité ACID, et bien qu'il utilise toujours SQL, ses objectifs sont les mêmes en termes d'évolutivité
la source
Bien qu'il ne s'agisse que d' un moteur intégré et non d'un serveur, leveldb a WriteBatch et la possibilité d'activer les écritures synchrones pour fournir un comportement ACID.
la source
Node levelUP est transactionnel et construit sur leveldb https://github.com/rvagg/node-levelup#batch
la source
Google Cloud Datastore est une base de données NoSQL qui prend en charge les transactions ACID
la source
DynamoDB est une base de données NoSQL et a des transactions ACID .
la source
Non seulement NoSQL n'est pas conforme à ACID de par sa conception. Le mouvement NoSQL embrasse la BASE (Basically Available, Soft state, Eventual cohérence) prétendument l'opposé d'ACID. Les bases de données NoSQL sont souvent appelées bases de données éventuellement constituées. Pour comprendre les différences, vous devez approfondir le théorème CAP (alias le théorème de Brewer)
Visitez http://www.julianbrowne.com/article/viewer/brewers-cap-theorem
la source