什么应用程序不需要ACID？

Question

对于这个无知的问题很抱歉,但是什么样的应用程序不需要符合ACID标准的数据库服务器？我有一个SQL Server背景,其中ACID一直"在那里",现在研究其他DBMS让我思考.我能想到的大多数应用都需要原子性或隔离性.谢谢!

Answer 1

这是一个悖论,每个RDBMS人都认为天空会在没有ACID的情况下崩溃,但是大多数NoSQL人都乐于部署和支持最终用户应用程序,而没有想到"我的应用程序会更好用ACID".与Marc B的回答相反,NoSQL数据库不是随机丢失更新或数据随机损坏的数据库.关键的区别在于,在NoSQL数据库中,您可以使用有限版本的原子性和隔离等,但实现任意复杂度的事务需要花费指数.

您无法使用非ACID数据库实施银行系统.大多数NoSQL数据库都允许您使用微交易从一个帐户中扣除资金并将其添加到另一个帐户,系统总金额的可能性变化为0%.

为了在现实世界的例子中讨论这个问题,我将描述我们的应用程序.我的公司向高中销售软件,主要用于时间表,还有唱名,管理教师缺勤/替换,短途旅行和预订房间.我们的软件基于内部开发的名为Mrjb的非ACID数据库引擎(仅在内部提供),该引擎具有NoSQL数据库的典型限制.

与最终用户相关的ACID和NoSQL之间的区别的一个例子是,如果2个用户试图在同一时间标记相同的滚动,则最终结果将是(非常)很小的可能性是数据的组合由两个用户提交.ACID数据库将保证最终结果是一个用户的数据或另一个用户的数据,或者可能一个用户的更新将失败并向用户返回错误消息.

在这种情况下,我不认为我们的用户会关心个别学生的"缺席"状态是否与一个用户的更新或两者的混合一致,尽管他们会担心如果我们分配了与两者相反的缺勤状态用户的输入.这个例子不应该在实践中出现,如果确实如此,那么它就是一个"竞争条件",对于我们认为哪个用户基本上没有正确答案.

与我们的Mrjb数据库有关的问题是,我们是否能够实现约束,例如"在没有相应的Family对象的情况下,不得允许Student对象存在".('ACID'中的'C'=一致性).事实上,我们可以并且确实维持这种约束 - 微交易的另一个例子.

另一个例子是上传每日时间表所依据的新版本的周期性学校时间表(通常为2周周期).我们很难将此更新事务设为原子或允许其他事务独立于此更新执行.所以我们基本上可以选择在这个主要交易发生时"停止世界",这需要大约2秒钟,或者允许学生打印出包含更新前和更新后数据组合的时间表(这里有)可能是一个100毫秒的窗口,可能会发生这种情况)."停止世界"选项可能是更好的选择,但实际上我们做的是后者.您可能会认为混合时间表比更新前的时间表更糟糕,但在这两种情况下,我们都需要依靠学校的流程来通知学生时间表已经改变 - 学生正在处理过时的时间表即使这是一个一致的时间表,也是一个大问题.另请注意,学生通常会在线查看他们的时间表,在这种情况下,问题会大大减少.

我还为http://brainresource.com写了一个"基于文件系统的Blob数据库" 来存储他们的脑部扫描.这是一个重要的数据库,虽然它们确实使用RDBMS来获取有关其主题的其他数据,但它没有ACID属性.

为了记录,我们公司在这里描述:http: //edval.com.au和我们的NoSql技术在这里描述(描述为一种技术):http://www.edval.biz/memory-resident-programming-object - 数据库 .有人担心这个帖子是垃圾邮件,给我们的公司带来了插件,但我认为(a)所提出的问题不能仅仅用理论术语来回答 - 你需要一些现实世界的例子,以及(b)预扣任何有关产品或数据库技术的识别信息都不合适.

Answer 2

其他答案似乎缺失的是ACID的普遍适用的替代方案并非"没有",它被称为最终一致性(有时被称为BASE).

当人们说他们需要ACID语义时,通常他们的真正含义,至少从域/业务需求的角度来看,只是数据完整性.他们希望确保数据不会丢失或损坏.许多NoSQL数据库仍然提供这种保证,它们只是以不同的方式并按照自己的条件提供.

如果您将NoSQL或BASE数据库简单地视为"非ACID数据库",那么使用NoSQL或BASE数据库作为SQL或ACID数据库的不安全替代方案当然是可能的.做出明智的决策意味着您了解在应用程序级别必须做些什么来弥补粗粒度交易的缺乏并发挥EC的优势.一些常见的技术是:

• 乐观并发,已用于最小化事务环境中的锁定.

• 操作的幂等性,如果长时间运行的操作在中途失败,可以一次又一次地重试,直到成功为止.

• 使用补偿事务的长期事务处理技术,通常在分布式系统中称为sagas,其中多个独立事务按一些相关标识符分组,并且独立地跟踪整个操作的状态.通常这些实际上对于saga状态本身使用ACID语义,但是它比两阶段提交更轻量级.

就事实而言,如果你花多少时间工作在分布式系统-即使是那些与 ACID语义可在每个单独的子系统-你会发现很多的用于管理跨系统的操作中,这些相同的技术,因为没有他们,你只是抹杀性能(想想BizTalk和BPEL).

一旦你有了一些经验,你会发现它实际上很有意义,并且通常比尝试应用ACID语义更容易.计算过程只是现实生活过程的模型,现实过程有时会在中游失败.你预订了一个航班,但突然你不能再去了.你是做什么？你取消了.也许你收回你的钱,也许你没有,或者可能是介于两者之间的东西 - 这些都是你的商业规则.或者也许你已经开始预订但是分心或偏离或者你的力量消失了,现在你的会话已经超时了.你是做什么？很简单,你重新开始吧.

为了真正正面地解决这个问题,我会这样回答:

在以下情况下您需要ACID语义:

• 你可以合理地期望有多个用户或在工作过程中相同的数据在同一时间.

• 交易出现的顺序非常重要;

• 您不能容忍向用户显示陈旧数据.

• 不完整交易存在重大和/或直接成本(例如,不平衡总额可能产生严重后果的金融系统).

另一方面,如果符合以下条件,则不需要ACID语义:

• 用户只倾向于对自己的私有数据执行更新,或者根本不执行更新(只是追加).

• 事务没有隐式(业务定义)排序.例如,如果两个客户竞争库存的最后一个项目,那么实际获得它的人并不重要.

• 用户将倾向于同时在同一屏幕上持续数秒或数分钟,因此无论如何都要查看陈旧数据(这实际上描述了大多数应用程序).

• 您可以简单地放弃未完成的交易; 让他们暂时或在某些情况下永久地坐在数据库中不会产生负面影响.

底线是很少数的应用程序真正需要的ACID语义随处可见.然而,许多应用程序都需要他们的地方 -通常在隔离的口袋一样的传奇状态或消息队列.

下次你设计一个新的应用程序或功能时,试着考虑一下是否有可能将原子/隔离的"事务"建模为一个异步的"事件链",并带有一些额外的状态来将它们全部联系起来一起.在某些情况下,答案是没有,但你可能是在回答如何往往是惊讶肯定.

Answer 3

任何基于 NoSQL 类型的数据库都会牺牲 ACID 合规性来换取某些东西，通常是速度。

Twitter、Facebook、Reddit、Digg 等...全部都是部分非酸基的