Databases Reference
In-Depth Information
APPENDIX A
NOSQL Overview
Recent years have seen a meteoric rise in popularity of a family of data storage tech‐
nologies known as
NOSQL
(a cheeky acronym for
Not Only SQL
, or more confronta‐
tionally,
No to SQL
). But NOSQL as a term defines what those data stores are not—
they're not SQL-centric relational databases—rather than what they are, which is an
interesting and useful set of storage technologies whose operational, functional, and
architectural characteristics are many and varied.
Why were these new databases created? What problems do they address? Here we'll
discuss some of the new data challenges that have emerged in the past decade. We'll
then look at four families of NOSQL databases, including graph databases.
The Rise of NOSQL
Historically, most enterprise-level web apps ran on top of a relational database. But in
the past decade, we've been faced with data that is bigger in volume, changes more
rapidly, and is more structurally varied than can be dealt with by traditional RDBMS
deployments. The NOSQL movement has arisen in response to these challenges.
It's no surprise that as storage has increased dramatically,
volume
has become the prin‐
cipal driver behind the adoption of NOSQL stores by organizations. Volume may be
defined simply as
the size of the stored data
.
As is well known, large datasets become unwieldy when stored in relational databases;
in particular, query execution times increase as the size of tables and the number of joins
grow (so-called
join pain
). This isn't the fault of the databases themselves; rather, it is
an aspect of the underlying data model, which builds a set of all possible answers to a
query before filtering to arrive at the correct solution.
In an effort to avoid joins and join pain, and thereby cope better with extremely large
datasets, the NOSQL world has adopted several alternatives to the relational model.
