NoSQL, Couchbase, MongoDB. Fast but can we compensate?

Source

The NoSql movement has picked up in the last 10 years with the rising popularity of the Internet.

With the creation of large amounts of unstructured data, consistency isn’t that important considering that a lot of what is being written to these databases is just content like blog posts and tweets.

The real requirement for NoSql databases is to support tens of millions of users. The compromises they make for scalability and performance will seldom affect their users in any noticeable way.

NoSql technologies when paired with a data cache (Couchbase = Memcached + Couchdb) offer available and low latency solutions, but they do so by relaxing consistency

Couchbase and mobile

Summary

When deciding what data store to use in your next application, if availability or low latency is on the list of important quality attributes, you had best think twice.

When considering this type of technologies;

  • first pick the processes that are suitable candidates
  • ask the question 'How do you intent to compensate in the case of inconsistency?'
  • realise that the decision of where to use this technology may be constrained by the ability and willingness of the business to compensate.


Available and fast

An example of this is when amazon.com sells books, say they are using a cluster of machines to hold the state of the warehouse and they update that state when purchases occur, they are highly available and fast.

If for any reason one if the machines is unable to communicate with the others (a partition forms), or misses an update, that version of the state may differ from what is actually available.

If a customer was served information out of one these machines with 'stale' data, the potential to sell something that one does not have stock of exists.

This is both good and bad, on the good side, the shop is open and you are taking sales, you are perceived to be available and fast (low latency), on the bad side you have just sold a thing you do not have in stock.

Consistent...always

SQL technologies value consistency over all, while they can be clustered it requires special expertise and one rarely finds large clusters of hundreds of machines.

SQL technologies value consistency so much that they trade-off availability and low latency in any case where consistency may be compromised.

An example of this can be seen when calls get queued up while waiting for locks to be released, the database prefers to make callers either wait (high latency) or time out (unavailability) in periods of high load rather than risk any inconsistency in the data.

This is both good and bad, on the good side, the shop will never sell anything it does not have, but on the bad side you may miss sales and frustrate customers in high load scenarios.

PACELC

A good way to remember this is PACELC. PACELC reads as ‘When a partition forms choose between being available or being totally consistent in all other cases choose between low latency and consistency’

Can we compensate?

In deciding to use a NoSql technology designers should seek to discover how good a fit the business process is to that technology. The best question to ask of business is 'How do you intend to compensate in the case of inconsistency?'

In the example above, amazon.com, on discovering the inconsistency could contact the client, admit the mistake and offer a voucher on the next purchase and place an express order to get it to them as soon as they can, most of us would be happy with such an outcome.

No room at the hospital

In the research I did for a hospital, who were looking at using NoSql technologies to back the admissions process I asked if they could compensate?

It turned out no, if there are no beds available in the hospital and a sick person arrives due to a consistency mistake, they cannot add more beds into the hospital, and send that sick person on a road trip to the nearest hospital in the group with a bed.

Enterprise Scenarios

Some enterprise scenarios that I can think of are;

  • reading enterprise wide static data out of a NoSql backed in-memory cluster of machines, this makes sense as the data does not go stale often, and the resource needs the high availability and low latency characteristics
  • backing a payment/financial system with NoSql technologies, what is the impact of the customer not seeing the payment reflected immediately?, or what does it mean if a transaction is not included in the invoicing run due to a consistency issue?, it depends on your situation, but at least you have asked the right questions.

Important points

So when considering this type of technologies;

  • first pick the processes that are suitable candidates
  • ask the question 'How do you intent to compensate in the case of inconsistency?'
  • realise that the decision of where to use this technology may be constrained by the ability and willingness of the business to compensate.

More by this Author


Comments

No comments yet.

    Sign in or sign up and post using a HubPages Network account.

    0 of 8192 characters used
    Post Comment

    No HTML is allowed in comments, but URLs will be hyperlinked. Comments are not for promoting your articles or other sites.


    Click to Rate This Article
    working