database - 哪些应用程序不需要 ACID？

Question

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

Answer 1

其他答案似乎缺失的是，普遍适用的 ACID 替代方案并不是“没有”，而是一种叫做 eventual consistency 的东西。 (有时昵称为 BASE)。

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

如果您将 NoSQL 或 BASE 数据库视为简单的“非 ACID 数据库”，那么当然可以使用 NoSQL 或 BASE 数据库作为 SQL 或 ACID 数据库的不安全替代品。做出明智的决定意味着您了解在应用程序级别必须做什么来弥补粗粒度事务的缺乏并发挥 EC 的优势。一些常见的技术是:

Optimistic concurrency ，它已经用于最小化事务环境中的锁定。

Idempotence操作，这样如果长时间运行的操作中途失败，可以简单地一次又一次地重试，直到成功。

Long-running transaction使用技术 compensating transactions ，在分布式系统中通常称为sagas，其中多个独立的事务通过一些相关标识符进行分组，并且独立地跟踪整个操作的状态。通常这些实际上对 saga 状态本身使用 ACID 语义，但这比两阶段提交轻得多。

事实上，如果您在分布式系统上花费大量时间——即使是那些在每个单独子系统中都具有 ACID 语义的系统——您会发现许多用于管理跨系统操作的相同技术，因为如果没有它们，您只是抹杀了性能(想想 BizTalk 和 BPEL)。

一旦您对它有了一些经验，您就会意识到它实际上很有意义，而且通常比尝试应用 ACID 语义更容易。计算过程只是现实生活过程的模型，现实生活中的过程有时会在中途失败。你订了机票，但突然你不能再去了。你做什么工作？你取消。也许你拿回了你的钱，也许你没有，或者它介于两者之间——这些是你的商业规则。或者，也许您开始预订但心烦意乱或偏离了方向，或者您的电源断电，现在您的 session 已超时。你做什么工作？很简单，你重新开始。

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

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

您可以合理地期望多个用户或进程同时处理相同的数据。

交易出现的顺序极其重要；

您永远不能容忍向用户显示陈旧数据。

不完整的交易会产生重大和/或直接的成本(例如，不平衡的总额会产生严重后果的金融系统)。

另一方面，如果出现以下情况，则不需要 ACID 语义:

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

没有隐含的(业务定义的)事务排序。例如，如果两个客户正在竞争库存中的最后一件商品，那么实际上谁拿到它对您来说并不重要。

用户往往会一次在同一屏幕上停留数秒或数分钟，因此无论如何都会查看陈旧数据(这实际上描述了大多数应用程序)。

您可以简单地放弃不完整的交易；让它们暂时或在某些情况下永久留在数据库中不会产生负面影响。

最重要的是，很少有应用程序在任何地方都真正需要 ACID 语义。然而，许多应用程序会在某个地方需要它们——通常在孤立的口袋里，比如 saga 状态或消息队列。

下次设计新应用程序或功能时，请尝试考虑是否可以将原子/隔离“事务”建模为异步“事件链”，并添加一些额外的状态将它们全部联系起来一起。在某些情况下，答案是否定的，但您可能会对答案是肯定的频率感到惊讶。