# Consistency Models of NoSQL Databases
## 5 NoSQL Consistency Implementations
### MongoDB  
One of the strongest features of MongoDB is horizontal scaling by using a technique called sharding. Sharding allows distributing data across many data nodes. Hence, avoiding the architectures composed of a couple of big and powerful machines. MongoDB balances data across these nodes in an automatic way. There are three types of sharding:  
_Range-based Sharding_: documents are distributed based on their shard key-values. Consequently, two shard key-values close to each other are likely to be on the same shard. Hence, optimizing operations between them.  
_Hash-based Sharding_: the key-values are subject to an MD5 hash. This sharding strategy tends to distribute data across shards uniformly. Although, it performs worse in range-based queries.  
_Location-aware Sharding_: the user can specify a custom configuration to accomplish application requirements. For example, high-demanding data can be stored In-Memory (Enterprise Edition), and less popular data can be stored on the disk.  
A dispatcher called Query Router will redirect application issued queries to the correct shard depending on the sharding strategy and shard value.  
MongoDB follows the ACID (Atomicity, Consistency, Isolation, and Durability) properties [38] similar to RDBMS implementations:  
* **Atomicity**. MongoDB supports single operation inserts and updates;
* **Consistency**. MongoDB can be used on a strong consistency approach;
* **Isolation**. While a document is updated, it is entirely isolated. Any error would result in a rollback operation, and no user will be reading stale data;
* **Durability**. MongoDB implements a feature called write concern. Write concern are user-defined policies that need to be fulfilled in order to commit (i.e., writing at least three replicas before commit).  
MongoDB allows configuring a replica set. A replica set has primary replica set members and secondary replica set members. There are two configurations based on the desired consistency level:* **Strong consistency**. Applications write and read from the primary replica set member. The primary member will write all the operations that made it transact to the new state. These operations are idempotent and constitute the oplog (operations log). After the primary member acknowledges the application of the committed data and operations logging, secondary replica set members can now read from this log and replay all operations so that they can be on the same state of the primary member.
* **Eventual consistency**. Applications can read from secondary replica set members if they do not prioritize reading the latest data.  
In the case of a primary member failover, secondary replicas will elect a new primary among them by using the Raft consensus algorithm [39]. Once the primary member is elected, it will be responsible for updating the oplog read by secondary members. In the case of a recovery of the primary member, this will play the role of a secondary member for then on.  
Oplog has a configurable back-limit history (default: 5% of the available disk space). If a secondary member fails longer enough to need operations that are no longer available in the oplog, all the databases, collections, and indexes directives are copied from the primary member or another secondary member. This process is called _initial synchronization_. The same one that is used when adding a new member to the replica set