database - 非 ACID 数据库合规性对现实世界有哪些影响？

Question

具体来说，是否存在数据丢失的风险？我正在考虑运行一个密集的事务处理系统，其中不丢失任何东西是至关重要的。有没有在银行交易处理等关键任务应用程序中使用 NoSQL 的示例？

Answer 1

It's a paradox that every RDBMS guy thinks the sky would fall without ACID, but most NoSQL guys happily deploy and support end-user applications without ever thinking "my application would be better with ACID".

(Note: this answer is similar to what I gave to the very similar question: What Applications Don't Need ACID? )

The vast majority of NoSQL databases have the 'D' (durability) property: an unexpected loss of power will leave you with committed transactions being evident in the database, with the caveat that NoSQL transactions are 'small' in some sense. So "No": a typical NoSQL db does not lose data.

In most NoSQL databases you get to use limited versions of atomicity & isolation etc., but it takes an exponential amount of effort to implement transactions of arbitrary complexity. So there is no reason why you can't implement a bank system using a non-ACID database: most NoSQL databases would let you use micro-transactions which deduct money from one account and add it to another, with a 0% chance of the total amount of money in the system changing. (However, as a counter-example, I believe a banking application could not be written in Google AppEngine because their transactions only work within one 'complex object' which would be a single user's set of bank accounts).

In order to discuss this question in the context of real-world examples, I'll describe our application. My company sells software to high schools, primarily for timetabling but also roll-call, managing teacher absences/replacements, excursions and room bookings. Our software is based on an in-house developed non-ACID database engine called Mrjb (only available internally) which has limitations which are typical of NoSQL databases.

An example of the difference between ACID and NoSQL as relevant to the end user is that if 2 users try to mark the same roll at exactly the same time, there is a (very) small chance that the final result will be a combination of data submitted by both users. An ACID database would guarantee that the final result is either one user's data or the other's, or possibly that one user's update will fail and return an error-message to the user.

In this case I don't think our users would care about whether the individual students' "absence" statuses are all consistent with one user's update or a mixture of both, although they would be concerned if we assigned absence statuses which are contrary to both users' inputs. This example should not occur in practice, and if it does then it's a "race condition" where there's essentially no right answer about which user we believe.

A question was raised in relation to our Mrjb database about whether we're able to implement constraints such as "must not allow a Student object to exist without a corresponding Family object". (The 'C' in 'ACID' = Consistency). In fact we can and do maintain this constraint - another example of a micro-transaction.

Another example is when uploading a new version of the cyclical school timetable (typically a 2-week cycle) upon which the daily timetable is based. We would be hard pressed to make this update transaction atomic or to allow other transactions to execute in isolation from this update. So we basically have a choice to either "stop the world" while this major transaction occurs, which takes about 2 seconds, or allow the possibility that a student prints off a timetable containing a combination of pre-update and post-update data (there's probably a 100ms window in which this could occur). The "stop the world" option is probably the better option, but in fact we do the latter. You could argue that a mixed timetable is worse than a pre-update timetable, but in both cases we need to rely on the school having a process to notify students that the timetable has changed - a student working off an out-of-date timetable is a big problem either way.

For the record, our company is described here: http://edval.com.au and our NoSql technology is described here (described as a technique): http://www.edval.biz/memory-resident-programming-object-databases .

Answer 2

无需轻率，没有 ACID 意味着您无法保证原子性、一致性、隔离性或持久性。

如果没有原子性，您将无法保证必须同时成功或失败的多个操作都会这样做。例如，如果您的交易要求您一次性借记一个帐户并贷记另一个帐户，那么在没有原子交易的情况下，您要么必须推出自己的解决方案，要么接受您可以借记一个帐户，而无需进行相应的信用。

如果没有一致性，就不能保证事务的“副作用”起作用——在关系数据库中，例如触发触发器或外键关系的级联。因此，如果您的交易需要某种自动递增的唯一标识符，则无法保证您会得到一个。

没有隔离，就无法保证两个进程不会同时影响数据。例如，一个进程可能会增加一个字段的值，而另一个进程可能会减少它——谁赢了？

如果没有持久性，硬件故障可能会使数据库处于与您预期不同的状态 - 例如，您可能认为更改已写入数据存储，但它在某个内部内存缓冲区中排队，如果有电源故障。

可能可以在 NoSQL 上构建一个解决方案，该解决方案可以在没有 ACID 合规性的情况下工作，但是工作量会很大，而且你几乎肯定不会像编写关系数据库的人那样做得好......

Answer 3

是的，存在数据丢失的风险，只有傻瓜才会将其用于金融交易。