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