An Overview of the NoSQL World - Large Scale and Big Data: Processing and Management - page 289

NoSQL systems decided to compromise on the strict consistency requirement. In
particular, they apply a relaxed consistency policy called eventual consistency [63],
which guarantees that if no new updates are made to a replicated object, eventually
all accesses will return the last updated value. If no failures occur, the maximum
size of the inconsistency window can be determined based on factors such as com-
munication delays, the load on the system, and the number of replicas involved in
the replication scheme. In particular, these new NoSQL systems have a number of
design features in common:

• The ability to horizontally scale out throughput over many servers.

• A simple call level interface or protocol (in contrast to a SQL binding).

• Supporting weaker consistency models in contrast to ACID guaranteed

properties for transactions in most traditional RDBMS. These models
are usually referred to as BASE models ( B asically A vailable, S oft state,
E ventually consistent) [53].

• Efficient use of distributed indexes and RAM for data storage.

• The ability to dynamically define new attributes or data schema.

These design features are made to achieve the following system goals:

• Availability : They must always be accessible even during network failure or
a whole datacenter going offline.
• Scalability : They must be able to support very large databases with very
high request rates at very low latency.
• Elasticity : They must be able to satisfy changing application requirements
in both directions (scaling up or scaling down). Moreover, the system must
be able to gracefully respond to these changing requirements and quickly
recover its steady state.
• Load balancing : They must be able to automatically move load between
servers so that most of the hardware resources are effectively utilized and
to avoid any resource overloading situations.
• Fault tolerance : They must be able to deal with the situation that the
rarest hardware problems go from being freak events to eventualities.
While hardware failure is still a serious concern, this concern needs to
be addressed at the architectural level of the database, rather than requir-
ing developers, administrators, and operations staff to build their own
redundant solutions.

• Ability to run in a heterogeneous environment : On scaling out environ-

ment, there is a strong trend toward increasing the number of nodes that
participate in query execution. It is nearly impossible to get homogeneous
performance across hundreds or thousands of compute nodes. Part failures
that do not cause complete node failure, but result in degraded hardware
performance become more common at scale. Hence, the system should be
designed to run in a heterogeneous environment and must take appropriate
measures to prevent performance degradation that are due to parallel pro-
cessing on distributed nodes.