当ACID不重要时？

Question

我读了一篇关于Cassandra DB的话题.它写道,这对于不需要ACID属性的应用程序很有用.

Is there any application or situation that ACID is not important?

Answer 1

有许多(大多数？)场景不需要ACID.例如,如果你有一个产品数据库,其中一个表是id - > description而另一个是id - > todays_price,而另一个是id - > sales_this_week,那么更新时不需要锁定所有表.即使(由于某种原因)三个表中存在一些共同的数据位,根据使用情况,使它们在几秒钟内不同步可能不是问题.也许每月销售仅在月末汇总报告时需要.不符合ACID意味着不一定满足ACID的所有四个属性......在大多数商业案例中,只要事情最终彼此一致,它就足够了.

值得一提的是,影响相同cassandra分区的提交是原子的.如果某些内容确实需要原子级一致,那么您的数据模型应该努力将这些信息放在同一个分区中(例如,在同一个表中).当我们讨论cassandra上下文中的最终一致性时,我们指的是影响不同分区的事物(可能是同一个表中的不同行),而不是同一个分区.

"交易"的典型例子是来自一个账户的借方和来自另一个账户的贷方....这是"重要的",因为"银行".实际上,这不是银行的运作方式.这样一个系统需要的是一个明确的交易清单(读取转移).如果你要为cassandra建模,你可以有一个由(from_account,to_account,amount,time等)组成的转移表.这些记录在原子上是一致的.您的"帐户"表格将从此传输列表中更新.这种反映多久取决于业务.例如,在英国,从劳埃德银行到劳埃德银行的转账几乎是即时的.一些银行间转账可能需要几天时间.对于后者,您的帐户余额通常显示未扣除的待处理转帐金额,而单独的"可用余额"则考虑待处理的转帐.

不同的事物在不同的延迟中运行,并且在某些情况下ACID,并且所有更新的记录之间的最终直接一致性可能是重要的.但是对于很多其他人来说,特别是在处理包含大量数据的分布式系统时,可能不需要数据库级别的ACID.

即使需要"可见一致性",也可以通过应用程序级别的协调机制,CRDT等来处理它.对于最终用户来说,系统是原子的 - 要么成功,要么不成功,用户得到确认.在内部,系统可能正在更新多个数据库,处理外部服务等,并且只确认什么时候都是桃子.因此,对于表中的不同行,或跨单个数据库中的表,甚至跨多个数据库的ACID,可能不足以实现外部可见的一致性.Cassandra具有可调整的一致性,您可以使用数据建模,并处理权衡以创建满足业务需求的"足够好"的系统.如果您需要跨表的ACID事务性,那么 - Cassandra将不适合该用例.但是,您可以在cassandra的约束内建模您的业务需求,并使用它来获得它提供的其他可伸缩性优势.