Database Reference
In-Depth Information
discusses the notion of providing database management as a services and gives
an overview of the main representative systems and their challenges. In Sect.
3.5
,
we briefly describe the approach of deploying database servers on cloud-hosted
virtual machine environments. The Web scale data management trade-offs and open
research challenges are discussed in Sect.
3.6
before we conclude the chapter in
Sect.
3.7
.
3.2
NoSQL Key Systems
In general, relational database management systems (e.g. MySQL, PostgreSQL,
SQL Server, Oracle) have been considered as the
one-size-fits-all
solution for data
persistence and retrieval for decades. They have matured after extensive research
and development efforts and very successfully created a large market and solutions
in different business domains. However, ever increasing need for scalability and
new application requirements have created new challenges for traditional RDBMS.
Therefore, recently, there has been some dissatisfaction with this
one-size-fits-all
approach in some Web scale applications [
216
].
Recently, a new generation of low-cost, high-performance database software has
emerged to challenge the dominance of relational database management systems.
A big reason for this movement, named as
NoSQL
(
N
ot
o
nly
SQL
), is that
different implementations of Web, enterprise, and cloud computing applications
have different database requirements (e.g. not every application requires rigid data
consistency). For example, for high-volume Web sites (e.g. eBay, Amazon, Twitter,
Facebook), scalability and high availability are essential requirements that can
not be compromised. For these applications, even the slightest outage can have
significant financial consequences and impacts customers' trust.
In general, the
CAP
theorem [
86
,
138
] and the
PACELC
model [
57
] describe
the existence of direct tradeoffs between consistency and availability as well as
consistency and latency. For example, the
CAP
theorem shows that a distributed
database system can only choose at most two out of three properties: C
onsistency
,
A
vailability
and
tolerance to
P
artitions
. Therefore, there is a plethora of
alternative consistency models which have been introduced for offering different
performance trade-offs such as
session guarantees
,
causal consistency
[
70
],
causal+consistency
[
178
] and
parallel snapshot isolation
[
212
]. In practice, the
new wave of NoSQL systems decided to compromise on the strict consistency
requirement. In particular, they apply a relaxed consistency policy called
eventual
consistency
[
226
] 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 communication 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).
