Non-relational Database Systems – NoSQL

There is a paradigm shift in web applications that were there in early 1990s and now. Most of the earlier web applications were content based sites where a few people used to update / create content and a lot many people used to consume it. So there were fewer writes and more reads. Now with the advent of social networking, more and more people are creating content on the application. There is a shift from read-only architectures to read/write or write heavy architecture. In such a scenario, traditional relational databases do not suffice as the number of users grow. In a large database to make the queries faster, the logic of relating the tables is being implemented at application level. By doing this, the features of a relational db are not being used and the databases are just becoming stores.

Hence was borne a system where we do not maintain relations and is much more flexible and scalable. The NoSQL movement is a used to describe the increasing usage of non-relational databases among Web developers. This approach has initially pioneered by large scale Web companies like Facebook (Cassandra), Amazon (Dynamo) & Google (BigTable) but now is finding its way down to smaller sites like Digg. This movement was initially called the No-SQL as in an alternative to SQL but later was renames as Not Only SQL 🙂

Salient features:

1. It isn’t a relational database.
2. lack of fixed schemas
3. limited support for rich querying.
4. Offer little functionality beyond record storage (e.g. key–value stores)
5. Highly optimized for retrieval and appending operations
6. Has no limit on number of columns , size of data
7. Development cycle might be faster as one does not need to spend too much time on data modelling and schema design.
8. Has a distributed, fault-tolerant architecture. Several NoSQL systems employ a distributed architecture, with the data held in a redundant manner on several servers. In this way, the system can easily scale out by adding more servers, and failure of a server can be tolerated. This type of database typically scales horizontally and is used for managing large amounts of data, when the performance and real-time nature is more important than consistency