sql-server - 什么时候 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、金额、时间等)的转账表。这些记录将是原子一致的。您的“帐户”表将从该传输列表中更新。这需要多长时间才能反射(reflect)出来取决于业务。例如，在英国，从劳埃德银行到劳埃德银行的转账几乎是即时的。而一些银行间转账可能需要几天时间。在后者的情况下，您的账户余额通常显示未扣除的待转账金额，而单独的“可用余额”考虑待转账。

不同的事物以不同的延迟运行，在某些情况下是 ACID，因此所有更新记录之间的即时一致性可能很重要。但是对于很多其他人来说，特别是在处理具有大量数据的分布式系统时，可能不需要数据库级别的 ACID。

即使在需要“可见一致性”的地方，它通常也可以通过应用程序级别的协调机制、CRDT 等来处理。对于最终用户来说，系统是原子的——要么成功，要么不成功，并且用户得到确认。在内部，系统可能正在更新多个数据库、处理外部服务等，只有在一切顺利时才确认。因此，表中不同行的 ACID，单个数据库中跨表，甚至多个数据库的 ACID 可能不足以实现外部可见的一致性。 Cassandra 具有可调的一致性，您可以在其中使用数据建模，并进行权衡以制作满足业务需求的“足够好”的系统。但是，如果您需要跨表的 ACID 事务性——Cassandra 不适合该用例。但是，您可以在 cassandra 的约束范围内对您的业务需求进行建模，并使用它来获得它提供的其他可扩展性优势。