For a long time, relational databases have dominated software industry, providing mechanisms to store data persistently, to control concurrency and transactions, to ensure standard interfaces to integrate application data, reporting. etc. Almost any software system was built around a relational database. In time, the rise of web as a platform has changed the perspective about data storage. Huge volumes of data were now required to be stored in clusters and to be manipulated faster.
On these aspects, relational databases don't perform very well. They are not designed to run efficiently on clusters. With Object Oriented Design, applications are built around a data model which describes the problem domain but that is usually different from the actual relational data structures used to store the data. So there is always a need to translate from one model to the other. A lot of ORM (Object-Relational Mapping) frameworks have been developed for this purpose but that always impacts performance but also the developers productivity.
NoSQL means Not Only SQL, implying that when designing a software solution or product, there is more than one storage mechanism that could be used based on the needs. There is no formal definition about, but more like a set of common observations like:
- not using a relation model
- running well on clusters
There are several types of NoSQL databases, each type with numerous existing implementations.
Key-value databases are the simplest NoSQL data stores to use from an API perspective. The client can either get the value for the key, put a value for a key, or delete a key from the data store. The value is a black box that the database just stores, without caring or knowing what's inside; it's the responsibility of the application to understand what was stored.
Since key-value stores always use primary-key access, they generally have great performance and can be easily scaled. Some of the popular key-value databases are Riak, Redis , Memcached, Berkeley DB, upscaledb , Amazon DynamoDB, and Couchbase.
Documents are the main concept in document databases. The database stores and retrieves documents, which can be XML, JSON, BSON, and so on. These documents are self-describing, hierarchical tree data structures which can consist of maps, collections, and scalar values. The documents stored are similar to each other but do not have to be exactly the same. Document databases store documents in the value part of the key-value store; think about document databases as key-value stores where the value is examinable. Document databases such as MongoDB provide a rich query language and constructs such as database, indexes etc allowing for easier transition from relational databases.
Column Family Databases
Column-family databases store data in column families as rows that have many columns associated with a row key. Column families are groups of related data that is often accessed together.
Each column family can be compared to a container of rows in an RDBMS table where the key identifies the row and the row consists of multiple columns. The difference is that various rows do not have to have the same columns, and columns can be added to any row at any time without having to add it to other rows.
When a column consists of a map of columns, then we have a super column. A super column consists of a name and a value which is a map of columns. Think of a super column as a container of columns.
To conclude, all the choice provided by the rise of NoSQL databases does not mean the demise of RDBMS databases. We are entering an era of polyglot persistence, a technique that uses different data storage technologies to handle varying data storage needs