【发布时间】：2011-10-13 12:36:14
【问题描述】：
具体来说，是否存在数据丢失的风险？我正在考虑运行一个密集的事务处理系统，其中不丢失任何东西是至关重要的。有没有在银行事务处理等关键任务应用程序中使用 NoSQL 的示例？
【问题讨论】：
【发布时间】：2011-10-13 12:36:14
【问题描述】：
每个 RDBMS 人员都认为没有 ACID 天会塌下来，这是一个悖论，但大多数 NoSQL 人员很乐意部署和支持最终用户应用程序，而从未想过“我的应用程序使用 ACID 会更好”。
（注意：这个答案类似于我对非常相似的问题的回答：What Applications Don't Need ACID?）
绝大多数 NoSQL 数据库都具有“D”（持久性）属性：意外断电会使您在数据库中明显看到已提交的事务，但需要注意的是，NoSQL 事务在某种意义上是“小”的。所以“否”：典型的 NoSQL 数据库不会丢失数据。
在大多数 NoSQL 数据库中，您可以使用有限版本的原子性和隔离等，但要实现任意复杂的事务需要付出指数级的努力。所以你没有理由不能使用非 ACID 数据库来实现银行系统：大多数 NoSQL 数据库允许你使用微交易，从一个帐户中扣除钱并将其添加到另一个帐户中，有 0% 的机会系统中的总金额在变化。 （但是，作为一个反例，我认为银行应用程序可能不用 Google AppEngine 编写，因为它们的交易只能在一个“复杂对象”中工作，即单个用户的一组银行账户） .
为了在实际示例的上下文中讨论这个问题，我将描述我们的应用程序。我的公司向高中销售软件，主要用于安排时间表，也用于点名、管理教师缺勤/替换、短途旅行和房间预订。我们的软件基于内部开发的称为 Mrjb 的非 ACID 数据库引擎（仅内部可用），该引擎具有 NoSQL 数据库的典型限制。
与最终用户相关的 ACID 和 NoSQL 之间差异的一个示例是，如果 2 个用户尝试在完全相同的时间标记同一个卷，那么最终结果的可能性很小（非常）两个用户提交的数据的组合。 ACID 数据库将保证最终结果要么是一个用户的数据，要么是另一个用户的数据，或者一个用户的更新可能会失败并向用户返回错误消息。
在这种情况下，我认为我们的用户不会关心个别学生的“缺勤”状态是否与一个用户的更新一致或两者兼而有之，尽管如果我们分配的缺勤状态是与两个用户的输入相反。这个例子在实践中不应该发生，如果发生了，那么它就是一个“竞争条件”，对于我们相信哪个用户基本上没有正确的答案。
关于我们的 Mrjb 数据库提出了一个问题，即我们是否能够实现诸如“不得允许 Student 对象在没有相应的 Family 对象的情况下存在”之类的约束。 （“ACID”中的“C”= 一致性）。事实上，我们可以并且确实保持这种约束——微交易的另一个例子。
另一个示例是在上传新版本的周期性学校时间表（通常为 2 周周期）时，该时间表是每日时间表所依据的。我们将很难使这个更新事务原子化或允许其他事务与这个更新隔离执行。所以我们基本上可以选择在这个主要交易发生时“停止世界”，这大约需要 2 秒，或者允许学生打印出包含更新前和更新后数据组合的时间表（有可能发生这种情况的 100 毫秒窗口）。 “停止世界”选项可能是更好的选择，但实际上我们是后者。您可能会争辩说，混合时间表比更新前的时间表更糟糕，但在这两种情况下，我们都需要依靠学校有一个流程来通知学生时间表已更改——学生正在处理过期的时间表无论哪种方式都是一个大问题。
为了记录，我们公司在这里描述：http://edval.com.au，我们的 NoSql 技术在这里描述（描述为一种技术）：http://www.edval.biz/memory-resident-programming-object-databases。
【讨论】：
无需轻率，没有 ACID 意味着您无法保证原子性、一致性、隔离性或持久性。
如果没有原子性，您就无法保证必须同时成功或失败的多个操作都会这样做。例如，如果您的交易要求您一次性借记一个帐户并贷记另一个帐户，那么在没有原子交易的情况下，您要么必须推出自己的解决方案，要么接受您可以从一个帐户中借记，而无需进行相应的信用。
如果没有一致性，则无法保证事务的“副作用”有效 - 在关系数据库中，例如触发触发器或外键关系的级联。因此，如果您的交易需要某种自动递增的唯一标识符，则无法保证您会得到一个。
如果没有隔离，就无法保证两个进程不会同时影响数据。例如，一个进程可能会增加一个字段的值，而另一个进程可能会减少它 - 谁赢了？
如果没有持久性，硬件故障可能会使数据库处于与您预期不同的状态 - 例如，您可能认为更改已写入数据存储，但它在某个内部内存缓冲区中排队，然后消失在稀薄状态如果有电源故障，空气。
也许可以在 NoSQL 上构建一个解决方案，以解决不符合 ACID 的问题，但工作量会很大，而且您几乎肯定不会像编写关系数据库的人那样做得好。 ...
【讨论】：
-
All(?) NoSQL 数据库至少有 'D' - 如果断电，没有人希望事务消失。使用“我”，NoSQL 人不会问“谁赢了？”但是“用户希望谁赢？”如果它们同时发生，用户可能不会有任何期望。对于“A”（原子性），许多 NoSQL 数据库提供了有限形式的交易，这通常会让您借记一个帐户并贷记另一个帐户，它们只是不支持涉及 100 个对象的任意复杂交易。
是的，存在数据丢失的风险，只有傻瓜才会将其用于金融交易。
【讨论】：