# Consistency Models of NoSQL Databases
## 5 NoSQL Consistency Implementations
### Summary  
In this section, we compared the different consistency implementations of several NoSQL databases. Table 1 summarizes the consistency models supported by the five NoSQL databases: Redis, Cassandra, MongoDB, Neo4j, and OrientDB.  
Figure 9: Neo4j Cluster Architecture.  
Redis is a high-available and very low latency (the best of the group) database, due to the in-memory architecture. It can relax consistency to an eventual consistency level.  
Cassandra introduces a storing system composed of many nodes on a ring. Cassandra is the database system that offers the broadest spectrum of eventual consistency levels. Cassandra is cheaper for storing data than Redis and has a robust eventual consistency architecture while maintaining high-availability and low-latency. Cassandra's best uses cases are core data storage from applications that don't always need the latest data but prefer a high available and low latency service instead.  
MongoDB is the database system that offers more consistency configurations, strong consistency, causal consistency, session consistency, and eventual consistency. Although MongoDB's default consistency model is strong consistency, it has the ability to perform at higher availability and lower latency when on its eventual consistency configuration. However, MongoDB is a single master architecture. For this reason, it does not scale writes well as it scales stale data reads (eventual consistency). MongoDB's best use cases are, for example, logging and data that don't demand write requests from a large pool of clients.  
Neo4j promotes consistency and availability. Neo4j does not support data partitioning. However, it has a variant of the master-slave model, where it is possible to read from replicas that may or may not have the latest data. Therefore, the applications can choose to have eventual consistent readings.  
Similar to MongoDB and Neo4j, OrientDB allows the application to choose which consistency level it prefers. OrientDB defaults to strong consistency when its data is read solely from master nodes and eventual consistency when reading from replicas. In their eventual consistency configurations, Neo4j's and OrientDB's scaling limitations are similar to the ones found on MongoDB.  
Figure 10 summarizes the lessons learned by depicting where each database positions itself with respect to the three quality attributes addressed by the CAP theorem. Note that this analysis only considers the default configurations of each database engine [43]. The three vertices of the theorem describe each property, Consistency, Availability and Network Partition Tolerance. Neo4j, OrientDB, and Relational DBs favor strong consistency and availability. Cassandra favors eventual consistency, resulting in high availability, better tolerance to network partition and low latency. Finally, MongoDB and Redis favor strong consistency and network partition tolerance.  
\begin{table}
\begin{tabular}{c c c c c} \hline \hline  & **Strong** & **Casual** & **Session** & **Eventual** & **Weak** \\ \hline Redis & & \({}^{2}\) & & ✓ \({}^{1}\) & \\ Cassandra & ✓ & & & ✓ \({}^{1}\) & \\ MongoDB & ✓ \({}^{1}\) & ✓ & ✓ & ✓ & \\ Neo4j & ✓ \({}^{1}\) & ✓ & & ✓ & \\ OrientDB & ✓ \({}^{1}\) & & ✓ & ✓ & \\ \hline \hline \end{tabular} \({}^{1}\) default configuration, \({}^{2}\) across replicas.  
\end{table}
Table 1: Consistency models comparison.  
Figure 10: Consistency, Availability, and Network Partition Tolerance (CAP) Theorem and classification of databases based on their default configurations.