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

Posted 2023-02-16

【中文标题】是否有任何符合 ACID 的 NoSQL 数据存储？

【英文标题】：Is there any NoSQL data store that is ACID compliant?

【发布时间】：2011-02-06 04:15:33

【问题描述】：

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

【问题讨论】：

实际上有符合酸要求的 FoundationDB。现在苹果抓住了它

wiredtiger.com 和 sophia.systems

【参考方案1】：

我将这个作为答案发布纯粹是为了支持对话 - Tim Mahy 、 nawroth 和 CraigTP 建议了可行的数据库。由于使用了Erlang，CouchDB 是我的首选，但还有其他的。

我想说 ACID 并不矛盾或否定 NoSQL 的概念......虽然似乎有一种趋势遵循dove 表达的观点，我认为这些概念是不同的。

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

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

(A) 当您对数据库进行更改时，更改应该作为一个整体起作用或失败 (C) 数据库应该保持一致（这是一个相当广泛的话题） (I) 如果其他事情同时发生，他们应该无法在更新中看到事情 (D) 如果系统崩溃（硬件或软件），数据库需要能够自行恢复；如果它说它已完成应用更新，则需要确定

当谈到propagation and constraints 的想法时，谈话变得更加激动人心。一些 RDBMS 引擎提供了强制执行约束（例如外键）的能力，这些约束可能具有传播元素（la cascade）。简单来说，一个“事物”可能与数据库中的另一个“事物”有关系，如果您更改一个“事物”的属性，则可能需要更改另一个（更新、删除、...很多选项）。 NoSQL 数据库主要（目前）专注于高数据量和高流量，似乎正在解决在（从消费者的角度）任意时间范围内发生的分布式更新的想法。这基本上是通过transaction 管理的replication 的一种特殊形式——所以我想说，如果传统的分布式数据库可以支持ACID，那么NoSQL 数据库也可以。

一些进一步阅读的资源：

Wikipedia article on ACID Wikipedia on propagation constraints Wikipedia (yeah, I like the site, ok?) on database normalization Apache documentation on CouchDB with a good overview of how it applies ACID Wikipedia on集群计算 Wikipedia (again...) on database transactions

【讨论】：

好答案。你可以同时拥有 NoSQL+ACID 和非 ACID-RDBMS（想想 mysql + MyISAM）。我通常将 NoSQL 视为“最终一致”。我也会提出 CAP 定理... :-)

+1 @gbn 用于提及 CAP 定理。现在比我更熟悉“nosql”数据库只会加强概念的分离。此外，键值对与文档数据库，因为存在架构差异。

-1 提到 CAP 定理，我们应该烧掉它。请阅读https://martin.kleppmann.com/2015/05/11/please-stop-calling-databases-cp-or-ap.html

【参考方案2】：

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

好吧，根据Wikipedia article on NoSQL的旧版本：

NoSQL 是一项促进 定义松散的类 破坏的非关系数据存储 有着悠久的关系历史 数据库和 ACID 保证。

还有：

这个名字是为了描述 越来越多的出现 非关系型分布式数据 经常不尝试的商店 提供 ACID 保证。

和

NoSQL 系统通常提供弱 一致性保证，例如 最终一致性和事务 仅限于单个数据项，甚至 虽然可以强加全酸 通过添加补充保证 中间件层。

所以，简而言之，我想说“NoSQL”数据存储的主要好处之一是它独特的缺乏 ACID 属性。此外，恕我直言，尝试实施和执行ACID 属性的人越多，您获得的“NoSQL”数据存储的“精神”越远，您获得的“真实”RDBMS 越接近（相对当然是说）。

然而，话虽如此，“NoSQL”是一个非常模糊的术语，并且可以接受个人解释，并且在很大程度上取决于您拥有多少纯粹主义观点。例如，大多数现代 RDBMS 系统实际上并不遵守Edgar F. Codd 的12 rules 的relation model 的所有！

采用务实的方法，Apache 的 CouchDB 似乎最接近体现 ACID 合规性，同时保留松散耦合、非关系的“NoSQL”心态。

【讨论】：

+1 我不确定我是否同意缺乏 ACID 是“NoSQL”的一个关键特征，但我非常感谢您的文章。最终，它应该是一个合适的解决方案。

我进行了编辑（待审核），以试图使其更加清晰。 NoSQL 数据模型并没有暗示 ACID 事务是不可能的。一些 NoSQL 分布式系统没有它们。有些实际上没有任何“中间件层”。

这从来都不是正确的，甚至失去了它的来源。真的应该删掉。

嗯，最明显的是：“简而言之，我想说“NoSQL”数据存储的主要好处之一是它明显缺乏 ACID 属性。您还暗示 NoSQL 和 ACID 在某种程度上是互斥的，这绝对是不正确的。这是一个很好的例子，说明当大量无知的人赞成一个错误的答案时，因为这听起来很合理。大多数 NoSQL 数据库不符合 ACID 主要是因为实施它的人不知道它是什么/为什么重要/不关心。

@LennartRegebro - 我没有暗示任何这样的事情。大多数当前现有的 NoSQL 数据库确实避开了 ACID 合规性，以支持速度/性能和最终一致性。不过，我从来没有说过你不能拥有符合 ACID 的 NoSQL。

【参考方案3】：

请确保you read the Martin Fowler introduction about NoSQL databases。以及对应的视频。

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

面向聚合的数据库； 面向图形的数据库（例如 Neo4J）。

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

那么，其他类型呢？

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

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

这里我们称之为聚合，Eric Evans 在其Domain-Driven Design 中将其定义为在给定的有界上下文中自给自足的实体和值对象。

因此，聚合是我们收集的数据的集合 作为一个单元进行交互。聚合形成 ACID 的边界 与数据库的操作。 （马丁·福勒）

因此，在聚合级别，我们可以说大多数 NoSQL 数据库可以像 ACID RDBMS 一样安全，只要设置适当。当然，如果您将服务器调整为最佳速度，您可能会遇到非 ACID 的问题。但复制会有所帮助。

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

2019 年的一些更新：从 4.0 版开始，对于需要原子性来更新多个文档或读取多个文档之间的一致性的情况，MongoDB 提供了multi-document transactions for replica sets。

【讨论】：

我写了一个blog article about this question。

在某些情况下，有一个处理许多聚合的大进程/传奇。在某些情况下，发送到聚合的命令可能会触发一些更改其他聚合的事件。在这些情况下，您需要符合 ACID 的数据存储。

@TudorTudor 但在这种情况下，您违反了 nosql 原则之一，因为您将其用作 rdbms。您只需要更大的文档聚合或版本控制（如在 couchdb 中）。 Nosql 面向文档的数据库在文档/聚合边界上是酸的。

您列出的所有产品都不符合酸要求。 Mongo 只是不符合 ACID 标准。只要您不更新两个文档，CouchDB 就会假装它是酸兼容的。 Redis 只有“部分支持事务”。 HBase is straight up not acid compliant (from the devs)，Cassandra 也不是。这个答案实际上是错误的。这些数据库都不支持 ACID，并且大多数都通过简单的谷歌搜索公开拥有它。

我猜blog.synopse.info?post/2014/02/28/Are-NoSQL-databases-ACID 现在是正确的链接。 @veritas

【参考方案4】：

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

这个特性是我在MongoDB中最怀念的一个

【讨论】：

大部分开源github.com/orientechnologies/orientdb，但也有闭源企业功能

【参考方案5】：

FoundationDB 符合 ACID：

http://www.foundationdb.com/

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

【讨论】：

不幸的是它不是开源的。但它看起来确实是一个非常不错的数据库。

加上@Ken-Tindell 的答案，djondb 也是 NoSQL 并实现事务并且它符合 ACID。 djondb.com 我同意 NoSQL 只是一个术语，它是对所有不遵循 RDBMS 传统规则的数据库的一个术语，它并不意味着“摆脱 TX 系统”，或者忘记关系。

Apple 收购 Foundation DB 使我的回答变得毫无意义。

foundationdb 现在由 Apple 开源

【参考方案6】：

ACID 和 NoSQL 是完全正交的。一个并不意味着另一个。

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

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

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

【讨论】：

只是为了迂腐，但它通常意味着“不仅仅是 SQL”:-)

@shmish111 不是真的。最初创造该术语时，它的意思是“无 SQL”。 “o”很小，毕竟不是大写。当其中一些（NoSQL 产品）开始添加类似 SQL 的查询语言接口时，后来有人尝试将该术语重新定义为“不仅仅是 SQL”。

【参考方案7】：

“NoSQL”不是一个定义明确的术语。这是一个非常模糊的概念。因此，甚至无法说什么是“NoSQL”产品，什么不是“NoSQL”产品。并非几乎所有带有典型标签的产品都是键值存储。

【讨论】：

最佳答案。每当这场激烈的战争爆发时，我想问对方他们明确要求 NoSQL 数据库有哪些定义特性，并且通常它与他们在 RDBMS 中可以找到的特性重叠——不是因为一个或多个 RDBMS 适合 NoSQL 主题，而仅仅是因为它们的功能“要求”非常模糊，以至于它们不能完全否定（不一定）RDMBS 中的功能。为您的评论伙伴 +1！

【参考方案8】：

作为 NoSQL 的创始人之一（我是 Apache CouchDB 的早期贡献者，并于 2009 年在 CBS Interactive / CNET 举办的the first NoSQL event 上发表演讲）我很高兴看到新算法创造了以前没有的可能性之前存在。 The Calvin protocol 提供了一种考虑物理约束的新方法，例如 CAP 和 PACELC。

Calvin 通过使用RAFT-like protocol 维护事务日志，而不是主动/被动异步复制或主动/主动同步复制，在副本中断期间保持正确性和可用性。此外，transactions are processed deterministically 在每个副本上，消除了死锁的可能性，因此只需一轮共识即可达成一致。这使得它即使在全球多云部署中也能快速运行。

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

【参考方案9】：

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

【讨论】：

MarkLogic 具有 ACID 事务、多文档事务、多语句事务，并支持 XA - 所有集群范围/分布式。

【参考方案10】：

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

但是，它仅适用于 Python。

【讨论】：

对于那些希望从 python 的“搁置”库过渡的人，我发现 ZODB 几乎是无懈可击的。我不需要重新编写所有函数 - 只需像 shelve 一样将 ZODB 作为字典访问，但​​速度要快一个数量级。

【参考方案11】：

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

【参考方案12】：

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

我相信它符合 ACID。

【参考方案13】：

新SQL

这个概念Wikipedia contributors定义为：

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

参考文献

[1] Nancy Lynch 和 Seth Gilbert，“Brewer's conjecture and the feasibility of consistent, available, partition-tolerant web services”，ACM SIGACT 新闻，第 33 卷第 2 期（2002 年），第 2 页。 51-59。

[2]"Brewer's CAP Theorem"，julianbrowne.com，2010 年 3 月 2 日检索

[3]"Brewers CAP theorem on distributed systems", royans.net

【参考方案14】：

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

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

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

【讨论】：

是的，MongoDB 现在支持多文档 ACID 事务。请参阅mongodb.com/transactions 了解更多信息和深入了解其实施方式的视频。

【参考方案15】：

看看 CAP 定理

编辑：RavenDB 似乎符合 ACID

【参考方案16】：

要添加到替代列表中，另一个完全符合 ACID 的 NoSQL 数据库是 GT.M。

【参考方案17】：

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

【参考方案18】：

db4o

不同于滚动你自己的持久性或 序列化，db4o 是 ACID 交易安全并允许 查询、复制和模式 运行时的变化

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

【参考方案19】：

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

在我看来，数据库仍然是高性能的；但不要相信我，我创建了这个软件。自己试试吧。

【参考方案20】：

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

【参考方案21】：

MarkLogic 也符合 ACID。我认为是现在最大的玩家之一。

【参考方案22】：

等待结束。

符合 ACID 的 NoSQL DB 已发布 ------------ 看看 citrusleaf

【讨论】：

Aerospike 支持多键 ACID 交易吗？ AKAIK 仅限于单键交易。

【参考方案23】：

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

如果数据存储支持每个键的线性化和比较和设置（文档级原子性），那么实现客户端事务就足够了，而且您还有多个选项可供选择：

如果您需要 Serializable 隔离级别，那么您可以遵循 Google 用于 Percolator 系统或 Cockroach Labs 用于 CockroachDB 的相同算法。我已经写了博客并创建了一个step-by-step visualization，希望它能帮助你理解算法背后的主要思想。

如果您预计会出现高争用，但您可以设置已提交读隔离级别，那么请查看 Peter Bailis 的 RAMP transactions。

第三种方法是使用补偿事务，也称为 saga 模式。它在 80 年代后期的 Sagas 论文中有所描述，但随着分布式系统的兴起而变得更加实际。请参阅Applying the Saga Pattern 谈话以获取灵感。

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

【参考方案24】：

YugaByte DB 支持ACID Compliant distributed txns 以及查询层上的 Redis 和 CQL API 兼容性。

【参考方案25】：

Google Cloud Datastore is a NoSQL database that supports ACID transactions

【参考方案26】：

DynamoDB 是一个 NoSQL 数据库，拥有 ACID transactions。

【参考方案27】：

VoltDB 是声称符合 ACID 的参赛者，虽然它仍然使用 SQL，但其目标在可扩展性方面是相同的

【讨论】：

VoltDB 的创建者提到他们并没有将自己标记为 NoSql，而是更像 NewSql（仍然使用 Sql，但比 80 年代构建的那些 RDBM 实现更好）

【参考方案28】：

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

【参考方案29】：

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

【参考方案30】：

如果你加入足够多的纯净水并成功地掷硬币，任何东西都会变成酸性的。或者基本的。

说一个数据库符合 ACID 意味着四个具体的事情。并且在定义系统（限制范围）时，我们可以任意淡化含义，以便结果符合 ACID。

A——如果您的 NoSQL 数据库一次只允许一个记录操作，并且记录要么执行要么不执行，那么

这是原子操作

。 C——如果您允许的唯一约束很简单，例如对照已知架构检查 JSON 架构，那么

这是一致的

。 I——如果只支持仅追加事务（并且不允许架构更改），那么任何事物都不可能依赖于其他事物，

这是独立的

。 D——如果你在晚上关闭所有机器并同步磁盘，那么事务将在其中或它们不会，

这是持久的

。