Classification of NoSQL databases
These set practical challenges and give you ideas for experimenting with what you
have learned.You will also find a number of styles of text that distinguish between different kinds of
information. Here are some examples of these styles, and an explanation of their meaning.
Code words in text are shown as follows: " It's difficult to standardize the install methods
for Linux, because there are many different flavors and configurations."
A block of code is set as follows:
<Directory />
Options FollowSymLinks
AllowOverride None
Order deny,allow
Allow from all
</Directory>
When we wish to draw your attention to a particular part of a code block, the relevant lines
or items are set in bold:<Directory />
Options FollowSymLinks
AllowOverride All
Order deny,allow
Allow from all
</Directory>
Any command-line input or output is written as follows:
sudo apt-get install php5 php5-dev libapache2-mod-php5 php5-curl php5-mcrypt
The NoSQL database evolution
In the early 1960s, the term database was introduced to the world as a simple layer that would serve as the backbone behind information systems. The simple concept of separating
applications from data was new and exciting, and it opened up possibilities for applications
to become more robust. At this point, databases existed first as tape-based devices, but soon
became more usable as system direct-access storage on disks.
In 1970, Edgar Codd proposed a more efficient way of storing data – the relational model.
This model would also use SQL to allow the applications to find the data stored within its
tables. This relational model is nearly identical to what we know as traditional relational
databases today. While this model was widely accepted, it wasn't until the mid 1980s that
there was hardware that could actually make effective use of it. By 1990, hardware finally
caught up, and the relational model became the dominant method for storing data.
Just as in any area of technology, competition arose with Relational Database Management
Systems (RDBMS) . Some examples of popular RDMBS systems are Oracle, Microsoft SQL
Server, MySQL, and PostgreSQL.
As we moved past the year 2000, applications began to produce incredible amounts of
data through more complex applications. Social networks entered the scene. Companies
wanted to make sense of the vast amounts of data that were available. This shift brought up
some serious concerns about the datastructure, scalability, and availability of data that the
relational model didn't seem to handle. With the uncertainty of how to manage this large
amount of ever-changing data, the term NoSQL emerged.
The term NoSQL isn't short for "no SQL;" it actually stands for "not only SQL". NoSQL
databases are a group of persistent solutions, which do not follow the relational model and
do not use SQL for querying. On top of that, NoSQL wasn't introduced to replace relational
databases. It was introduced to complement relational databases where they fell short.
What makes NoSQL different
Besides the fact that NoSQL databases do not use SQL to query data, there are a few key
characteristics of NoSQL databases. In order to understand these characteristics, we'll
need to cover a lot of terminology and definitions. It's not important that you memorize
or remember everything here, but it's important for you to know exactly what makes up a
NoSQL database.
The first thing that makes NoSQL databases different is their data structure. There are a
variety of different ways in which NoSQL databases are classified.
Classification of NoSQL databases
NoSQL databases (for the most part) fit into four main data structures:
‹ Key-value stores: They save data with a unique key and a value. Their simplicity
allow them to be incredibly fast and scale to enormous sizes.
‹ Column stores: They are similar to relational databases, but instead of storing
records, they store all of the values for a column together in a stream.
This model would also use SQL to allow the applications to find the data stored within its
tables. This relational model is nearly identical to what we know as traditional relational
databases today. While this model was widely accepted, it wasn't until the mid 1980s that
there was hardware that could actually make effective use of it. By 1990, hardware finally
caught up, and the relational model became the dominant method for storing data.
Just as in any area of technology, competition arose with Relational Database Management
Systems (RDBMS) . Some examples of popular RDMBS systems are Oracle, Microsoft SQL
Server, MySQL, and PostgreSQL.
As we moved past the year 2000, applications began to produce incredible amounts of
data through more complex applications. Social networks entered the scene. Companies
wanted to make sense of the vast amounts of data that were available. This shift brought up
some serious concerns about the datastructure, scalability, and availability of data that the
relational model didn't seem to handle. With the uncertainty of how to manage this large
amount of ever-changing data, the term NoSQL emerged.
The term NoSQL isn't short for "no SQL;" it actually stands for "not only SQL". NoSQL
databases are a group of persistent solutions, which do not follow the relational model and
do not use SQL for querying. On top of that, NoSQL wasn't introduced to replace relational
databases. It was introduced to complement relational databases where they fell short.
What makes NoSQL different
Besides the fact that NoSQL databases do not use SQL to query data, there are a few key
characteristics of NoSQL databases. In order to understand these characteristics, we'll
need to cover a lot of terminology and definitions. It's not important that you memorize
or remember everything here, but it's important for you to know exactly what makes up a
NoSQL database.
The first thing that makes NoSQL databases different is their data structure. There are a
variety of different ways in which NoSQL databases are classified.
Classification of NoSQL databases
NoSQL databases (for the most part) fit into four main data structures:
‹ Key-value stores: They save data with a unique key and a value. Their simplicity
allow them to be incredibly fast and scale to enormous sizes.
‹ Column stores: They are similar to relational databases, but instead of storing
records, they store all of the values for a column together in a stream.
‹ Document stores: They save data without it being structured in a schema, with
buckets of key-value pairs inside a self-contained object. This datastructure is
reminiscent of an associative array in PHP. This is where CouchDB lands on the
playing field. We'll go much deeper into this topic in Chapter 3, Getting Started with
CouchDB and Futon.
each object. Nodes have properties and relationships to other nodes.
We won't go too deeply into examples of each of these types of databases, but it's important
to look at the different options that are out there.
buckets of key-value pairs inside a self-contained object. This datastructure is
reminiscent of an associative array in PHP. This is where CouchDB lands on the
playing field. We'll go much deeper into this topic in Chapter 3, Getting Started with
CouchDB and Futon.
‹ Graph databases:
They store data in a flexible graph model that contains a node foreach object. Nodes have properties and relationships to other nodes.
We won't go too deeply into examples of each of these types of databases, but it's important
to look at the different options that are out there.
For the most part, NoSQL databases are scalable because they rely on distributed systems
and ignore the ACID model. Let's talk through what we gain and what we give up through a
distributed system, and then define the ACID model.
When talking about any distributed system (not just storage or databases), there is a concept
that defines the limitations of what you can do. This is known as the CAP theorem.
and ignore the ACID model. Let's talk through what we gain and what we give up through a
distributed system, and then define the ACID model.
When talking about any distributed system (not just storage or databases), there is a concept
that defines the limitations of what you can do. This is known as the CAP theorem.
Post a Comment