As a matter of fact, latency tends to come at the cost of consistency.
Considering several replicas in the system, a client could
immediately read the first replica which it can access without
checking consistency. The second option is that the client could opt
for the ‘‘Quorum reads’’, which requires the system to check for inconsistency
across multiple replicas before reading. Surely the second
option causes some amount of latency. Difference in latency
between these two options can be a factor of four or more [22].
(7) Scalability and Complexity Analysis.
Fig. 1 shows the NoSQL Scalability Complexity relationship.
As shown in the figure Key-value NoSQL are suitable for data
intensive applications, while the Graph databases (Non Aggregate)
NoSQL are best fit for applications dealing with complex data. It
is also evident from the figure that, the Document (Aggregate oriented)
NoSQL is the most suitable NoSQL databases having a good
balance of ‘‘Data Complexity’’ and ‘‘Data Size’’. Since 90% of use
cases are much below the ‘‘Data Size’’ supported by the entire
NoSQL database, still most of the application is perfectly running
with conventional RDBMS.
(8) NRW Analysis.
NRW (Node, Read, Write) analysis is used to analyze the
characteristics of distributed database how they will trade off
Consistency, Read and Write performance [24].
Here,
N is the number of Nodes keeping copies of distributed record;
W, number of nodes that must successfully acknowledge for a
Write to be successfully committed.
R, the number of nodes that must send back the data to be
accepted as read by the system.
The majority of NoSQL databases uses N > W > 1 i.e. more
than one write must complete, but not all nodes need to be updated
immediately.
Tables 4 and 5 categorize the NoSQL according to NRW [25,24].
The ‘‘Read Repair’’ algorithm is often implemented to improve
consistency when R = 1.
The following are some more muscle with various Consistency
levels [24].