What is NoSQL? What makes NoSQL different from a relational database and why do we need it? These are some questions that we attempt to answer in a few lines.
NoSQL is a term used when talking about non-traditional databases. It is a very wild term. It basically defines a database that uses other Data Manipulation Language (DML) than SQL. This is why NoSQL is literally a combination of two words: No and SQL and it means "Not only SQL".
We use SQL when we want to manipulate data and access relational database servers such as Oracle, MySQL, Microsoft SQL Server, and all other relational databases. NoSQL Databases are not relational and they don't use the Codd's model.
Note
E.F. Codd was a famous mathematician who introduced 12 rules for the relational model for databases commonly known as Codd's rules. The rules mainly define what is required for a DBMS for it to be considered relational. For more information about Codd's model follow this link: http://fr.wikipedia.org/wiki/Edgar_Frank_Codd.
In a relational database, we can have a table and in this table an ID column which is used as a foreign key in another table. NoSQL Database does not have relational enforcement and it does not use SQL language to interact with stored data.
A NoSQL System aims to be easy to scale out. Scalability is the ability of a system to change its size while maintaining proportions and this usually means to increase throughput with addition of resources to address load increases. The problem with Relational Database Management System (RDBMS) isn't that they don't scale, it's that it becomes cost prohibitive to scale vertically, versus scaling horizontally. Vertical scaling means that you scale by adding more power (CPU, RAM, Hard disk space) to your existing machine, while horizontal scaling means that you scale by adding more machines into your pool of resources.
Note
A good example for horizontal scaling is Cassandra, MongoDB, and RavenDB. A good example for vertical scaling is MySQL – Amazon RDS (the cloud version of MySQL) which provides an easy way to scale vertically by switching from smaller to bigger machines, but this process often involves downtime.
Typical RDBMS makes strong guaranties about consistency. This requires to some extended communication between nodes for every transaction. This limits the ability to scale out because more nodes mean more communication.
Tip
In general, NoSQL Systems are open source, freely available on the Internet, and their use is increasingly gaining momentum in consumer and enterprise applications.
NoSQL itself is a very large concept and it involves a large number of technologies. In this section, we will introduce the different types of NoSQL but we will focus only on the RavenDB NoSQL Database type, the document-oriented database. The concepts we are introducing here apply on RavenDB and some other NoSQL Databases but not all NoSQL Database types.
Currently, the NoSQL databases types can be categorized in more than ten types. But we will only focus on the four major different types:
key-value databases: A key-value database has a key and a corresponding value together as dataset. In key-value models, the key has to be unique and the value is associated with that key. Values can be of different types such as strings, integers, floats, or byte arrays. Some databases do not even care about the data type of the value, they just store what you feed. These inputs are called blobs, meaning an arbitrary binary object, which the database does not need to interpret. It is a very simple kind of database; it is operating as a dictionary. Examples of key-value NoSQL Databases are Amazon Dynamo, Redis.
column-oriented databases: The basic idea behind column-oriented databases is that the data is not a dataset with its attributes stored in one unit as in SQL databases (row oriented) but one attribute of a set of datasets is stored in one unit (column oriented). From the simplicity of the columnar approach may accrue many benefits, especially for those seeking a high-performance environment to meet the growing needs of extremely large analytic databases. Google's BigTable, Cassandra, HBase, Hypertable are examples of column-oriented NoSQL Databases.
graph-oriented databases: The graph-oriented databases originated from the graph theory, where you have vertices (singular: vertex) and edges connecting the vertices. In databases, vertices are entities like persons and edges are relations between entities. These relations are similar to the relations in Relational Database Management Systems. Twitter uses FlockDB the graph-oriented database, Facebook and LinkedIn use also a graph-oriented NoSQL database.
document-oriented databases: The document-oriented databases use entire documents of different types as datasets. The document types are structured human readable data format such as XML or JSON. Document-oriented databases can be interpreted as particular cases of a key-value database. The database knows the format of document and it interprets it. This is the biggest difference to key-value storage. Therefore, in a document database, it is also the server itself that can operate with the document and not just the client. Ergo, it is also possible to directly work with the data in the document on the server side. Document store databases are schema free. In a schema free database you do not have to predefine what your documents looks like. For the storage this does not seem to be a problem, because the documents do not depend on each other. When the documents have some kind of structure or schema it is called semi-structured. Other examples of document-oriented databases are CouchDB, MongoDB, and obviously RavenDB.
RavenDB is a NoSQL document store database. In the context of RavenDB or a document-oriented database, you can think of a document as a web page with a hierarchical nested structure and all this data can be retrieved and fetched in one time. A document store can have a key and then it will have a document associated with that key.
Tip
The NoSQL Databases website (http://www.nosql-database.org/) currently lists more than 150 databases.
