How Data Integrity (ACID) handle by MongoDB ?

717 views
Skip to first unread message

ora pdba

unread,
Oct 20, 2016, 4:13:35 AM10/20/16
to mongodb-user
Atomic transaction Any data writing shall complete only when all parts of the data are all written. No partial writes shall be kept.
Transaction isolation Data that is being written inside a transaction shall be kept invisible from other connections until the transaction is completed.
Schema consistency repect Constraints set in the storage backend such as mandatory fields, relations and others shall be respected at any time prior commiting the transaction.
Data written in the database is durable Once data is written in the database, software failure cannot make the data disappear. 

ora pdba

unread,
Nov 9, 2016, 5:10:00 AM11/9/16
to mongodb-user
Friends please reply..

herve AGASSE

unread,
Nov 9, 2016, 5:49:44 AM11/9/16
to mongodb-user

Lungang Fang

unread,
Nov 9, 2016, 3:53:57 PM11/9/16
to mongodb-user

Hi,

You may want to check out MongoDB CRUD Concepts, especially section Atomicity and Transactions and section Read Isolation, Consistency, and Recency.

Atomic transaction: Any data writing shall complete only when all parts of the data are all written. No partial writes shall be kept.

In MongoDB, a write operation is atomic on the level of a single document, even if the operation modifies multiple embedded documents within a single document. See Model Data for Atomic Operations for an example data model that provides atomic updates for a single document. Since a single document can contain multiple embedded documents, single-document atomicity is sufficient for many practical use cases. For cases where a sequence of write operations must operate as if in a single transaction, you can implement a two-phase commit in your application. For more information on two-phase commit and rollback, see Perform Two Phase Commits for more information.

Transaction isolation: Data that is being written inside a transaction shall be kept invisible from other connections until the transaction is completed.

As Read Isolation, Consistency, and Recency points out, if a write is updating multiple fields in the document, a reader will never see the document with only some of the fields updated. However, when a single write operation modifies multiple documents, a reader may see only some of those documents updated unless $isolated is used. Even though two-phase commit ensures data consistency, it is possible for applications to return intermediate data during the two-phase commit or rollback.

Please note that $isolated is not the same as “isolation” as understood in traditional RDBMS (see https://docs.mongodb.com/manual/reference/operator/update/isolated/#behavior). Another thing worth noting is $isolation essentially locks out readers, and may interfere with concurrency. It also doesn’t work with sharded collections.

Schema consistency repect: Constraints set in the storage backend such as mandatory fields, relations and others shall be respected at any time prior commiting the transaction.

Data in MongoDB has a flexible schema. Unlike SQL databases, where you must determine and declare a table’s schema before inserting data, MongoDB’s collections do not enforce document structure. This flexibility facilitates the mapping of documents to an entity or an object. Each document can match the data fields of the represented entity, even if the data has substantial variation. In practice, however, the documents in a collection share a similar structure. Starting from release 3.2, MongoDB provides document validation which allows you to validate documents during updates and insertions.

Data written in the database is durable Once data is written in the database, software failure cannot make the data disappear.

Unless In-Memory Storage Engine is used, the database is written to disk from time to time. Journaling allows MongoDB to recover information that occurred after last checkpoint. If you are running replica sets, then you will have to figure out an appropriate write concern. If data durability is your primary concern, write concern “majority” ensures every write operation is propagated to the majority of the replica set members. This way, even if the primary failed, you are assured that all data written into database is intact and available once a secondary is elected as new primary. On the other hand, many people opt for write concern {w: 1} despite the potential rollback. It is in fact a trade-off between latency and durability.

Regards,
Lungang

Reply all
Reply to author
Forward
0 new messages