抱歉这个无知的问题,但什么样的应用程序不需要符合 ACID 的数据库服务器?我有一个 SQL Server 背景,ACID 一直“在那里”,现在研究其他 DBMS 让我思考。我能想到的大多数应用程序都需要原子性或隔离性。谢谢!
5 回答
其他答案似乎缺少的是 ACID 的普遍适用替代方案不是“无”,而是称为最终一致性(有时昵称为 BASE)。
当人们说他们需要 ACID 语义时,通常他们真正的意思是,至少从领域/业务需求的角度来看,仅仅是数据完整性。他们希望确保数据不会丢失或损坏。许多 NoSQL 数据库仍然提供这种保证,它们只是以不同的方式并根据自己的条件提供。
如果您将 NoSQL 或 BASE 数据库简单地视为“非 ACID 数据库”,那么当然可以使用 NoSQL 或 BASE 数据库作为 SQL 或 ACID 数据库的不安全替代品。做出明智的决定意味着您了解在应用程序级别必须做什么来弥补粗粒度事务的不足并发挥 EC 的优势。一些常见的技术是:
Optimistic concurrency,它已被用于最小化事务环境中的锁定。
操作的幂等性,如果一个长时间运行的操作中途失败,它可以简单地一次又一次地重试,直到它成功。
使用补偿事务的长时间运行事务技术,在分布式系统中通常称为sagas,其中多个独立事务按一些相关标识符分组,并且独立跟踪整个操作的状态。通常这些实际上对 saga 状态本身使用 ACID 语义,但这比两阶段提交要轻得多。
事实上,如果你花很多时间在分布式系统上工作——即使是那些在每个单独的子系统中都具有ACID 语义的系统——你会发现许多用于管理跨系统操作的相同技术,因为没有它们你只是抹杀性能(想想 BizTalk 和 BPEL)。
一旦您对它有了一些经验,您就会意识到它实际上很有意义,并且通常比尝试应用 ACID 语义更容易。计算过程只是现实生活过程的模型,现实生活中的过程有时会在中途失败。你订了机票,但突然你不能再去了。你做什么工作?你取消。也许你能拿回你的钱,也许你没有,或者可能介于两者之间——这些是你的商业规则。或者,也许您开始预订但分心或走神,或者您的电源中断,现在您的会话超时。你做什么工作?很简单,你重新开始。
为了真正正面解决这个问题,我会这样回答:
在以下情况下需要 ACID 语义:
您可以合理地期望多个用户或进程同时处理相同的数据。
交易出现的顺序极其重要;
您永远不能容忍向用户显示陈旧数据。
不完整的交易会产生重大和/或直接的成本(例如,不平衡的总额可能会产生严重后果的金融系统)。
另一方面,如果出现以下情况,则不需要ACID 语义:
用户只倾向于对自己的私有数据执行更新,或者根本不执行更新(只是追加)。
没有隐式的(业务定义的)事务排序。例如,如果两个客户正在竞争库存中的最后一件商品,那么谁真正得到它对你来说并不重要。
用户往往会一次在同一屏幕上停留几秒钟或几分钟,因此无论如何都会查看过时的数据(这实际上描述了大多数应用程序)。
您可以简单地放弃不完整的交易;让他们暂时或在某些情况下永久地坐在数据库中没有负面影响。
底线是很少有应用程序真正需要 ACID 语义无处不在。然而,许多应用程序会在某个地方需要它们——通常是在孤立的口袋里,比如 saga 状态或消息队列。
下次您设计新的应用程序或功能时,请尝试考虑是否可以将原子/隔离的“事务”建模为异步“事件链”,并带有一些额外的状态以将它们全部联系起来一起。在某些情况下,答案是否定的,但您可能会惊讶于答案是肯定的频率。
这是一个悖论,每个 RDBMS 人员都认为没有 ACID 天会塌下来,但大多数 NoSQL 人员很乐意部署和支持最终用户应用程序,而从未想过“我的应用程序使用 ACID 会更好”。与 Marc B 的回答相反,NoSQL 数据库不是更新随机丢失或数据随机损坏的数据库。关键区别在于,在 NoSQL 数据库中,您可以使用有限版本的原子性和隔离等,但实现任意复杂度的事务需要付出指数级的努力。
没有理由不能使用非 ACID 数据库实现银行系统。大多数 NoSQL 数据库允许您使用微交易,从一个账户中扣除资金并将其添加到另一个账户,系统中总金额发生变化的可能性为 0%。
为了在实际示例的上下文中讨论这个问题,我将描述我们的应用程序。我的公司向高中销售软件,主要用于安排时间表,也用于点名、管理教师缺勤/替换、短途旅行和房间预订。我们的软件基于内部开发的称为 Mrjb 的非 ACID 数据库引擎(仅内部可用),它具有 NoSQL 数据库的典型限制。
与最终用户相关的 ACID 和 NoSQL 之间差异的一个示例是,如果 2 个用户试图在完全相同的时间标记同一个卷,那么最终结果将是数据组合的(非常)小概率由两个用户提交。ACID 数据库将保证最终结果要么是一个用户的数据,要么是另一个用户的数据,或者一个用户的更新可能会失败并向用户返回错误消息。
在这种情况下,我认为我们的用户不会关心个别学生的“缺勤”状态是否与一个用户的更新一致或两者兼而有之,尽管他们会担心我们分配的缺勤状态是否与两者相反用户的输入。这个例子在实践中不应该出现,如果出现了,那么它就是一个“竞争条件”,对于我们相信哪个用户,基本上没有正确的答案。
关于我们的 Mrjb 数据库提出了一个问题,即我们是否能够实现诸如“必须不允许 Student 对象在没有相应的 Family 对象的情况下存在”之类的约束。(“ACID”中的“C”= 一致性)。事实上,我们可以并且确实保持这种约束——微交易的另一个例子。
另一个示例是上传新版本的周期性学校时间表(通常为 2 周周期),这是每日时间表所依据的。我们将很难使这个更新事务原子化或允许其他事务与这个更新隔离执行。所以我们基本上可以选择在这个主要交易发生时“停止世界”,这大约需要 2 秒,或者允许学生打印出包含更新前和更新后数据组合的时间表(有可能发生这种情况的 100 毫秒窗口)。“停止世界”选项可能是更好的选择,但实际上我们是后者。您可能会争辩说,混合时间表比更新前的时间表更糟糕,但是在这两种情况下,我们都需要依靠学校有一个流程来通知学生时间表已经改变——即使是一个一致的时间表,一个学生在一个过期的时间表上工作也是一个大问题。另请注意,学生通常会在线查看他们的时间表,在这种情况下问题会大大减少。
我还为http://brainresource.com编写了一个“基于文件系统的 Blob 数据库” ,用于存储他们的大脑扫描。这是一个重要的数据库,并且没有 ACID 属性,尽管他们确实使用 RDBMS 来存储有关其主题的其他数据。
作为记录,我们公司在这里描述:http: //edval.com.au ,我们的 NoSql 技术在这里描述(描述为一种技术): http ://www.edval.biz/memory-resident-programming-object -数据库 。有人担心这篇文章是垃圾邮件,给我们公司带来了麻烦,但我认为(a)所提出的问题不能仅用理论上的术语来回答——你需要一些现实世界的例子,以及(b)扣留任何关于产品或数据库技术的识别信息都是不合适的。
您为 ACID 语义付出了性能代价。如果您管理大量数据并且可以接受偶尔的不一致(即您没有转移资金),非 ACID 解决方案(例如大多数 NoSQL 解决方案)可能更可取。
http://www.schoonerinfotech.com/solutions/general/what_is_nosql
Facebook 是早期做出这种权衡的几家知名公司之一。事实上,他们将Cassandra编写为更适合其数据需求的数据存储,而 Cassandra 明确不支持 ACID 语义。
任何基于 NoSQL 类型数据库的东西都会牺牲 ACID 合规性以换取某些东西,通常是速度。
Twitter、Facebook、Reddit、Digg 等……都部分不含酸