NoSQL – 4. To cap it all                 Print      Add Favorite     Add Watch     Contact Author
Creator: host   12/1/2011 2:07:47 AM    Author: Charles Nurse   Source: http://charlesnurse.com/post/Look-Mom-NoSQL!-4-And-to-CAP-it-all.aspx   Views: 532    0    0  
Tags:
NoSql Database ORM Database type Raven

As my frequent readers would have noticed already, I have been diving into NoSQL databases recently – in particular Document Databases.  But why do we need NoSQL databases in the first place.  Surely the relational databases we have been using work fine – in fact they work very well in most situations. 

The problem with them is they don’t always scale very well – and when I mean scale, I mean scale really big – across multiple nodes in a cluster.  I alluded to this in the first post in this series, but as an aside I have decided to explore why in further detail in this post.

It all comes down to the CAP (or Consistency, Availability and Partition Tolerance) Theorem.  This theorem states that when working with distributed systems you can only achieve two of the three goals, so you need to decide what is important to you.

If Consistency is most important then you would choose a relational database which excels at Consistency.  Examples of when Consistency would be important are in financial systems or nuclear power stations, where it is critical that every piece of data is accounted for. 

However, in most cases, “eventual consistency” is all that matters.  For example in a content management system if a Page Editor updates a page it is not critical that every user sees that change immediately, as long as at some time in the near future (seconds or minutes) the update is visible. 

In most applications it is more important that some version of the data is available at all times – i.e. the A or Availability of the CAP theorem.  In systems that focus on Availability, server uptime is more important than the exact version of the data.

Finally, the P or Partition Tolerance defines the ability of the data to be distributed (partitioned) across multiple servers – this allows for hugely scalable systems, like Google or Facebook.

Document Databases (as with most NoSQL databases) excel at the A (Availability) and P (Partition Tolerance) corners of the triad and so are less good at Consistency - eventual consistency is good enough. 

Thus Document Databases are fast and can scale, but would never be used to run a financial system or a nuclear power station.
Rating People: 3   Average Rating:     
Comment List:
  No Record 

Post your comment
Your Name: Required
Your Mail: Email is used only to display Gravatar
Your Site:
CAPTCHA image
Enter the code shown above in the box below
Comment Info:         

     DnnModule.com is build to provide quality modules and skins, Some of them are free,some not. We wish these stuffs( free or not ) can be useful to you.

    Besides that, We also provide a full range of professional services, ranging from web site build, seo, system management, administration, support, senior consultancy and security services.   We act as if your development project or network was ours, with care and respect. We are not satisfied until it works the way you want it to, and we don't silently ignore found issues as somebody else's problem.