MONGDB Transactions and atomic operations

First, in principle, MONGDB has no concept of business.

A transaction has an acid concept, such as atomicity, in which a transaction either succeeds or fails altogether.

For example, considering a transfer business, a transfer from a 100 to B will be divided into two steps:

A = A-100;

b = b + 100;

In Mongdb, if a = A-100 is executed, it will be put into effect directly, there is no concept of rollback segment, so if B = B + 100 at this time, if there is a problem, you cannot rollback the operation of the previous step a. So, Mongdb is not atomic.

Then say consistency, simple to read consistency, MONGDB can not guarantee. Mongdb in order to ensure that the data read is not rolled back (as opposed to Oracle, is uncommitted data, guaranteed no dirty read), has been a great effort to implement in the latest version 3.4, and is based on the MONGDB query is a single collection on the basis of. Not to mention to ensure that the data read if the query starts at that point in time data.

This is not to say that mongdb is more clumsy than Oracle, because the MONGDB architecture gives us the advantage of being able to scale horizontally, losing the functionality of the transaction.

In fact, in mongdb, it is possible to achieve atomicity for a single statement.

The single statement here, for Mongdb, is the update and delete operations for a single collection. For example, if you batch update 100 data, there is a problem in 99th, can be rolled back. But this is not a transaction, this is the basic function of an UPDATE statement, if you execute an UPDATE statement, you are not sure if you can all succeed, then the database how to use it.

MONGDB Transactions and atomic operations