atomicity Guarantee: All write operations in MongoDB is atomic on the level of a single document.
Bulk Write, bulkwrite syntax: multiple CUD operations for the same collection. MySQL-like transactions are not supported. No rollback.
The default is executed sequentially, and an error returns an action that was not performed.
You can specify unordered batches, MONGO execute in parallel, and errors do not terminate execution.
Bulkwrite () supports the following write Operations:insertoneupdateoneupdatemanyreplaceonedeleteonedeletemany
Persistence:
Writes synchronous and asynchronous patterns. The balance between persistence and performance is achieved through parameter adjustment.
W<value>J<boolean>wtimeout<number}
W:majority: The write request has been propagated to most nodes, (including the master node) for confirmation. Whether the log has persisted see parameter J
J:true W Specifies the number of nodes or most node logs are persisted before confirming.
Read and write patterns are closely related. Write log persistence or not image-to-read consistency.
When the J:false, the log is not persisted to the hard disk, only in memory, so at this time failover may appear inconsistent reading.
Read:
Readpreference
Control which node from the replication set to read data, this feature can be easily read-write separation, the nearest reading and other strategies. Default Primiry.
readConcern 用来控制读一致性,用户可以在性能和一致性之间取舍
the readconcern
option is available For the following operations:
-
-
find
command
-
Aggregate
command and The Db.collection.aggregate ()
method
-
distinct
command
-
count
command
-
parallelcollectionscan
command
-
geonear
command
-
geosearch
command
To simplify the discussion, the following discussion is based on W:majority,j:true,readpreference:primiry
Common scenario: Traverse the cursor returned by find.
-
- Local defaults to always read the latest data, indicating that the client can see data that has not yet been persisted. In a clustered environment, it is possible that only Primiry completes the write, not the majority node. At this point primiry failover will roll back the data after the launch. (Read uncommitted will appear.) )
- Majority returns data that has been successfully written by a majority of nodes. Note that most of the confirmation write successes may not be up to date (since the newest may only Primiry succeeded, rather than most successes). (Isolate concurrent UNCOMMITTED writes)
- Linearizable, returns data that has been confirmed by a majority of the nodes to be successful and modified before this read (all concurrent writes are quarantined).
- MySQL provides multi-statement package transaction Syntax (BEGIN,COMMIT) transactions that are parallel, provide consistency through isolation levels, and provide row locks to ensure that resources are not being modified concurrently.
- REDIS provides multi-statement packaging transaction Syntax (MULTI,EXEC) transactions that are executed serially, are not concurrently modified, do not provide locks, but are guaranteed to terminate the current transaction execution by the watch mechanism before the transaction executes. In addition, there is no concurrent modification because of the isolation bounds of the serial transaction.
- MONGO has no multi-statement transaction syntax. Another single update involves multiple documents and non-atomic execution. When find involves multiple documents, the
readConcern进行并发修改隔离。
bulk syntax may be partially successful by not supporting multi-table multi-row transactions that are common in MySQL, or single-table multi-line transactions, and can only use compensation mechanisms to achieve eventual consistency.
- MONGO when multiple documents are involved with the update, the
$isolated可以保证update多文档不会有并发访问。但是不提供回滚。(不支持分片集群。)
- MONGO's two-phase commits provides transaction- like semantics.
- MONGO recommends using unique indexes and versioning to control concurrency. This is also common in MySQL.
A simple comparison of the acid properties of MongoDB with Mysql,redis