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:
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 :
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.
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é.
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 .
FoundationDB est conforme ACID:
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.
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.
«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é.
Oui, MarkLogic Server est une solution NoSQL (base de données de documents que j'aime l'appeler) qui fonctionne avec les transactions ACID
Le grand-père de NoSQL: ZODB est compatible ACID. http://www.zodb.org/
Cependant, c'est uniquement Python.
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).
Ce concept que les contributeurs de Wikipédia définissent comme suit:
[…] 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]
[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.net
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
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.
Pour ajouter à la liste des alternatives, une autre base de données NoSQL entièrement compatible ACID est GT.M .
Hyperdex Warp http://hyperdex.org/warp/ Warp (fonction ACID) est propriétaire, mais Hyperdex est gratuit.
db4o
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
MarkLogic est également compatible ACID. Je pense que c'est l'un des plus gros joueurs actuellement.
Attendez, c'est fini.
La base de données NoSQL compatible ACID est sortie ----------- Jetez un œil à Citrusleaf
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.
YugaByte DB prend en charge un txns distribué conforme ACID ainsi que la compatibilité Redis et CQL API sur la couche de requête.
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é
Node levelUP est transactionnel et construit sur leveldb https://github.com/rvagg/node-levelup#batch
DynamoDB est une base de données NoSQL et a des transactions 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)
Visitez http://www.julianbrowne.com/article/viewer/brewers-cap-theorem