Not Only SQL

Globally maximum percentage of the applications utilize presentation layer, business layer and data layer in serving its users. But most of the enterprises are finding it difficult in scaling up an application with RDBMS data layer. For e.g., let us assume that the famous social websites like Facebook, Twitter, Digg etc are built in such a way that they make use of RDBMS to serve contents to millions of its users. The results of huge number of hits to the database server will impact the performance of application in providing data and it also results in chaos in network traffic too. But the expectation of the users of such social media application is the lighting performance in delivering and displaying data. Hence such social media application developers presume to develop the application as a scalable and highly available entity.No SQL

The other option hitting the neurons of the developer is the replication of database which comes with an add-on problem of data in-consistency i.e., it decreases the ACID feature of the RDBMS. Replication is not providing the guarantee that the slave(s) are always in sync with the master at any point of time. The other factors blocking the developer in opting for replications are the single point-of-failure, maintenance cost etc.

Differing from RDBMS, NoSQL development approach focus on the scalability of data store for large set of data. The data are replicated at many places, but it uses different approach like “memtable” and so on. NoSQL is an artifact which has no structured schema. It makes the developer to add columns on the fly. For scaling up the requests, one can dynamically add the nodes/machine without making any impact on the applications.

Categories of NoSQL stores
NoSQL are categorized in different ways in terms of data storing models.
No SQL Categories

Pros & Cons of NoSQL store
NoSQL are categorized in different ways in terms of data storing models.
Pros & Cons of NoSQL

Brewer’s CAP Theorem depicts that any shared or distributed systems should possess the following characteristics

Strong Consistency
All clients see the same view, even in presence of updates
High Availability
All clients can find some replica of the data, even in the presence of failures
The system properties hold even when the system is partitioned

The CAP theorem states that you can always have only two of the above three CAP properties. The ACID system serves consistency. Hence Amazon Dynamo providing Availability and Partitioning properties, consistency is eventually achieved.


One thought on “Not Only SQL

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s