是否有任何符合ACID的NoSQL数据存储？

我纯粹是张贴此作为一个答案，支持对话- 蒂姆·梅伊，nawroth和CraigTP建议可行的数据库。由于使用Erlang，因此首选CouchDB，但还有其他方法。

我想说ACID不会与NoSQL的概念相抵触或否定……尽管dove所表达的观点似乎有趋势，但我认为这些概念是截然不同的。

NoSQL从根本上讲是简单键值（例如Redis）或文档样式模式（“文档”模型（例如MongoDB）中收集的键值对）作为经典RDBMS中显式模式的直接替代。它使开发人员可以不对称地处理事物，而传统引擎则在整个数据模型中强制执行严格的相同性。之所以如此有趣，是因为它提供了一种不同的方式来处理变更，而对于较大的数据集，它提供了处理容量和性能的有趣机会。

ACID提供了管理更改如何应用于数据库的原则。它以一种非常简化的方式声明（我自己的版本）：

• （A）当您做一些更改数据库的操作时，更改应该整体上起作用或失败
• （三）数据库应保持一致（这是一个相当广泛的话题）
• （I）如果其他事物同时发生，则它们应该无法在更新过程中看到事物
• （D）如果系统崩溃（硬件或软件），则数据库需要能够进行自我备份；如果它说已完成应用更新，则需要确定

当谈到传播和约束的想法时，对话变得更加兴奋。一些RDBMS引擎提供了强制执行可能具有传播元素（例如级联）的约束（例如外键）的能力。简单来说，数据库中的一个“事物”可能与另一个“事物”有关系，如果您更改一个属性，则可能需要更改另一个属性（更新，删除等等）。NoSQL数据库（目前）主要集中在高数据量和高流量上，似乎正在解决在（从消费者的角度）任意时间范围内发生的分布式更新的想法。这基本上是一种特殊的复制形式，通过事务 -所以我想说，如果传统的分布式数据库可以支持ACID，那么NoSQL数据库也可以。

一些资源可供进一步阅读：

• 维基百科关于ACID的文章
• 关于传播限制的维基百科
• 关于数据库规范化的维基百科（是的，我喜欢这个网站，好吗？）
• CouchDB上的Apache文档，很好地概述了如何应用ACID
• 集群计算维基百科
• 维基百科（再次...）关于数据库事务

更新（2012年7月27日）： 链接到Wikipedia的文章已更新，以反映发布此答案时最新的文章版本。请注意，当前的Wikipedia文章已被广泛修订！

好吧，根据有关NoSQL的Wikipedia文章的较旧版本：

NoSQL是一种促进松散定义的非关系数据存储类的运动，该类打破了关系数据库和ACID保证的悠久历史。

并且：

该名称是为了描述越来越多的非关系性，分布式数据存储的出现，而这些存储常常不尝试提供ACID保证。

和

NoSQL系统通常会提供弱​​的一致性保证，例如最终的一致性和仅限于单个数据项的事务，即使一个人可以通过添加辅助中间件层来施加完整的ACID保证。

因此，概括地说，我会说的“NoSQL的”数据存储的主要好处之一是它的独特缺乏的ACID属性。此外，恕我直言，尝试实现和实施ACID属性的尝试越多，获得的“ NoSQL”数据存储的“精神” 就越远，获得的“真正的” RDBMS越近（当然，相对而言） ）。

但是，所有这些，“ NoSQL”是一个非常模糊的术语，并且可以接受各种解释，并且在很大程度上取决于您所拥有的纯粹主义者的观点。例如，最现代的RDBMS系统实际上并不坚持所有的埃德加·科德的12条规则他的关系模型！

采取务实的方法，似乎Apache的CouchDB最接近体现了ACID的要求，同时保持了松散耦合的，非关系的“ NoSQL”心态。

请确保您阅读有关NoSQL数据库的Martin Fowler简介。和相应的视频。

首先，我们可以区分两种类型的NoSQL数据库：

1. 面向集合的数据库；
2. 面向图的数据库（例如Neo4J）。

根据设计，大多数面向图的数据库都是ACID！

那么，其他类型呢？

在面向聚合的数据库中，我们可以放入三个子类型：

• 基于文档的NoSQL数据库（例如MongoDB，CouchDB）；
• 键/值NoSQL数据库（例如Redis）；
• 列族NoSQL数据库（例如，Hibase，Cassandra）。

我们在这里称为集合的是Eric Evans在其域驱动设计中定义为给定有限上下文中的实体和值对象的自足。

因此，集合是我们作为一个整体与之交互的数据的集合。聚集形成了数据库ACID操作的边界。（马丁·福勒）

因此，在聚合级别，我们可以说大多数NoSQL数据库只要设置正确就可以像ACID RDBMS一样安全。从本质上讲，如果您以最佳速度调整服务器，则可能会遇到非ACID的情况。但是复制会有所帮助。

我的主要观点是，您必须按原样使用NoSQL数据库，而不是作为RDBMS的（廉价）替代方案。我看到太多项目滥用了文档之间的关系。这不能是ACID。如果您停留在文档级别，即聚合边界，则不需要任何事务。即使您不是真正的ACID，您的数据也将与ACID数据库一样安全，因为您不需要这些交易！如果您需要事务处理并一次更新多个“文档”，那么您就不再在NoSQL世界中了-因此，请使用RDBMS引擎！

2019年的某些更新：从版本4.0开始，对于需要原子性来更新多个文档或读取多个文档之间保持一致性的情况，MongoDB 为副本集提供了多文档事务。

FoundationDB符合ACID：

http://www.foundationdb.com/

它具有适当的事务，因此您可以以ACID方式更新多个不同的数据项。这用作在更高层维护索引的基础。

在此问题中，必须提及OrientDB：OrientDB是NoSQL数据库，是少数几个完全支持ACID事务的数据库之一。ACID不仅用于RDBMS，因为它不是关系代数的一部分。因此，有可能拥有一个支持ACID的NoSQL数据库。

这个功能是我在MongoDB中最想念的功能

ACID和NoSQL是完全正交的。一个并不暗示另一个。

我在桌上有一个笔记本，我用它来记录我仍然要做的事情。该笔记本是NoSQL数据库。我使用带有“页面缓存”的线性搜索来查询它，因此我不必总是搜索每个页面。它也符合ACID，因为我确保一次只能写一件事，而从不会在阅读时写。

NoSQL只是意味着它不是SQL。许多人感到困惑，并认为这意味着高度可扩展的Wild-West-Super-fast-storage。没有。这并不意味着键值存储或最终的一致性。它的意思是“不是SQL”，在这个星球上有很多数据库，其中大多数不是SQL ^{[需要引用]}。

您可以在其他答案中找到许多示例，因此我无需在此处列出它们，但是有些非SQL数据库具有ACID合规性，可用于各种操作，有些仅是针对单个对象写入的ACID，而有些则可以保证更多。每个数据库都是不同的。

“ NoSQL”不是一个明确定义的术语。这是一个非常模糊的概念。这样，甚至不可能说出什么是“ NoSQL”产品以及什么不是“ NoSQL”产品。并非所有通常带有标签的产品都是键值存储。

是的，MarkLogic Server是可用于ACID事务的NoSQL解决方案（我喜欢称之为文档数据库）

NoSQL的祖父：ZODB符合ACID。http://www.zodb.org/

但是，仅Python。

作为NoSQL的发起者之一（我是Apache CouchDB的早期贡献者，并且是2009年在CBS Interactive / CNET举行的第一届NoSQL活动的发言人），我很高兴看到新算法创造了前所未有的可能性。卡尔文（Calvin）协议提供了一种解决物理约束（如CAP和PACELC）的新方法。

代替主动/被动异步复制或主动/主动同步复制，Calvin通过使用类似RAFT的协议来维护事务日志来在副本中断期间保留正确性和可用性。此外，在每个副本上确定性地处理事务，消除了潜在的僵局，因此仅需进行一轮共识即可达成协议。即使在全球范围内的多云环境中，这也可以使其快速运行。

FaunaDB是唯一使用Calvin协议的数据库实现，使其特别适合需要类似大型机的数据完整性以及NoSQL规模和灵活性的工作负载。

如果您正在寻找符合ACID的键/值存储，则可以使用Berkeley DB。在图数据库中，至少Neo4j和HyperGraphDB提供ACID事务（HyperGraphDB目前实际上使用Berkeley DB进行低级存储）。

新SQL

Wikipedia贡献者将此概念定义为：

[…]一类现代的关系数据库管理系统，旨在为在线事务处理（OLTP）读写工作负载提供与NoSQL系统相同的可扩展性能，同时仍保持传统数据库系统的ACID保证。[1][2][3]

参考文献

[1]Nancy Lynch和Seth Gilbert，“布鲁尔的猜想以及一致，可用，可容忍分区的Web服务的可行性”，ACM SIGACT新闻，第33卷，第2期（2002），第1页。51-59。

[2] “酿酒师的CAP定理”，julianbrowne.com，2010年3月2日检索

[3] “分布式系统上的布鲁斯CAP定理”，royans.net

MongoDB宣布其4.0版本将符合ACID的多文档交易。

版本4.2。应该在分片设置下支持它。

https://www.mongodb.com/blog/post/multi-document-transactions-in-mongodb

提到了FoundationDB，当时它不是开源的。两天前，它已由Apple开源：https： //www.foundationdb.org/blog/foundationdb-is-open-source/

我相信它符合ACID标准。

看看CAP定理

编辑：RavenDB似乎符合ACID

为了增加替代品的名单，另一种完全符合ACID的NoSQL数据库是GT.M。

Hyperdex Warp http://hyperdex.org/warp/ Warp（ACID功能）是专有的，但是Hyperdex是免费的。

db4o

与自行开发的持久性或序列化不同，db4o是ACID事务安全的，并允许在运行时进行查询，复制和模式更改

http://www.db4o.com/about/productinformation/db4o/

Tarantool是完全ACID NoSQL数据库。您可以发出CRUD操作或存储过程，所有操作都将严格按照ACID属性运行。您还可以在这里阅读有关内容：http : //stable.tarantool.org/doc/mpage/data-and-persistence.html

MarkLogic也符合ACID。我认为现在是最大的参与者之一。

等待结束。

符合ACID的NoSQL DB出局-----------看柑桔

BergDB是一个轻量级的开源NoSQL数据库，从一开始就设计用于运行ACID事务。实际上，从改变数据库状态的唯一方法是以最高隔离级别（SQL术语：“可序列化”）运行ACID事务的角度来看，BergDB的ACID比大多数SQL数据库“更多” 。脏读，不可重复读或幻像读不会有任何问题。

我认为数据库仍然是高性能的。但是不信任我，我创建了软件。请自己尝试。

许多现代的NoSQL解决方案不支持ACID事务（原子隔离的多键更新），但是其中大多数都支持基元，这些基元允许您在应用程序级别上实现事务。

如果数据存储支持每个键的线性化和比较并设置（文档级原子性），则足以实现客户端事务，因此，您还有更多选择：

1. 如果您需要序列化隔离级别，那么你可以按照同样的算法，谷歌使用的渗滤器系统或蟑螂实验室为CockroachDB。我已经在博客上进行了介绍，并创建了逐步的可视化，希望它可以帮助您理解算法背后的主要思想。

2. 如果您期望争用较高，但是可以选择“读取已提交”隔离级别，那么请看一下Peter Bailis 进行的RAMP事务。

3. 第三种方法是使用补偿交易，也称为“传奇模式”。Sagas论文在80年代后期描述了该方法，但随着分布式系统的兴起，它变得更加实际。请参阅“ 应用传奇模式”演讲以获取灵感。

适用于客户端事务的数据存储列表包括具有轻量级事务的Cassandra，具有一致存储桶的Riak，RethinkDB，ZooKeeper，Etdc，HBase，DynamoDB，MongoDB等。

YugaByte DB在查询层上支持兼容ACID的分布式txns以及Redis和CQL API兼容性。

VoltDB是一家声称符合ACID标准的企业，尽管它仍使用SQL，但在可扩展性方面的目标是相同的

虽然它只是一个嵌入式引擎而不是服务器，但leveldb具有WriteBatch并具有打开同步写入以提供ACID行为的功能。

节点levelUP是事务性的，并基于leveldb https://github.com/rvagg/node-levelup#batch构建

Google Cloud Datastore是NoSQL数据库，支持ACID事务

DynamoDB是NoSQL数据库，具有ACID事务。

不仅NoSQL在设计上不符合ACID。NoSQL运动包含了与ACID相反的BASE（基本可用，软状态，最终一致性）。NoSQL数据库通常称为最终构造数据库。要了解差异，您应该深入了解CAP定理（又称Brewer定理）

访问http://www.julianbrowne.com/article/viewer/brewers-cap-theorem