我读了一篇关于Cassandra DB的话题。它写道，它对于不需要ACID属性的应用程序有好处。
Is there any application or situation that ACID is not important?
答案 0 :(得分：6)
有许多（大多数？）场景不需要ACID。例如，如果您有一个产品数据库，其中一个表是id - ＆gt;描述和另一个是id - ＆gt; todays_price，还有一个是id - ＆gt; sales_this_week，那么在更新内容时不需要锁定所有表。即使（由于某种原因）三个表中存在一些共同的数据位，根据使用情况，使它们在几秒钟内不同步可能不是问题。也许每月销售仅在月末汇总报告时需要。不符合ACID意味着不一定满足ACID的所有四个属性......在大多数商业案例中，只要事情最终彼此一致，它就足够了。
值得一提的是，影响同一cassandra分区的提交是原子的。如果某些内容确实需要原子级一致，那么您的数据模型应该努力将这些信息放在同一个分区中（例如，在同一个表中）。当我们讨论cassandra上下文中的最终一致性时，我们指的是影响不同分区的事物（可能是同一个表中的不同行），而不是相同的分区。
“交易”的规范示例是来自一个帐户的借方，来自另一个帐户的贷方....这是“重要的”，因为“银行”。实际上，这不是银行的运作方式。这样一个系统需要的是一个明确的交易清单（读取转移）。如果你要为cassandra建模，你可以有一个由（from_account，to_account，amount，time等）组成的转移表。这些记录在原子上是一致的。您的“帐户”表格将从此传输列表中更新。这种反映多久取决于业务。例如，在英国，从劳埃德银行到劳埃德银行的转账几乎是即时的。一些银行间转账可能需要几天时间。对于后者，您的帐户余额通常显示未扣除的待处理转帐金额，而单独的“可用余额”则考虑待处理的转帐。
不同的事物在不同的延迟时间运行，并且在某些情况下ACID，并且所有更新记录的最终直接一致性可能是重要的。但对于很多其他人来说，特别是在处理包含大量数据的分布式系统时，可能不需要数据库级别的ACID。
即使需要“可见一致性”，也可以通过应用程序级别的协调机制，CRDT等来处理它。对于最终用户来说，系统是原子的 - 要么成功，要么不成功，用户得到确认。在内部，系统可能正在更新多个数据库，处理外部服务等，并且只确认什么时候都是桃子。因此，对于表中的不同行，或跨单个数据库中的表，甚至跨多个数据库的ACID，可能不足以实现外部可见的一致性。 Cassandra具有可调整的一致性，您可以使用数据建模，并处理权衡以创建满足业务需求的“足够好”的系统。如果您需要跨表的ACID事务性，那么 - Cassandra将不适合该用例。但是，您可以在cassandra的约束内建模您的业务需求，并使用它来获得它提供的其他可伸缩性优势。