Selection Criteria for NoSQL Database part iii

In the first part of this blog series we discussed about the reasons in support of NoSQL databases vis-à-vis relational databases. The second part  grappled with the various types of NoSQL databases. Here we are back again, with the third and concluding part that will delve deep into the ‘Selection Criteria for NoSQL Database.’

Let’s cut to the chase and give you the all important factors that you need to take into account before finalizing which NoSQL database is right for your needs:

1.    Storage Type – A good indicator towards making the right choice of NoSQL database is its storage type.

• For instance, get, put and delete functions are best supported by Key Value systems.
• Aggregation becomes much easier while using Column oriented systems as against the conventional row oriented databases. They use tables but do not have joins.
• Mapping data becomes easy from object oriented software using a Document oriented NoSQL database such as XML or JSON as they use structure document formats.
• Tabular format is replaced and data is stored in graphical format.

2.    Concurrency Control- Concurrency control are what defines how two users can simultaneously edit the same bit of information. It happens quite often that one of the user is locked out and is unable to edit or perform other actions till the active user has finished editing.

• Locks prevent more than one active user to edit an entity such as a document, row or an object.
• MVCC (Multi-Version Concurrency Control), guarantee a read consistent view of the database, but result in conflicting versions of an entity if multiple users modify it at once. MVCC makes it possible for a transaction to seamlessly go through by maintaining many different versions of the object. That means transaction consistency is maintained even if that shows varying snapshots to different users at any given point in time. Any changes made to the database will be shown to others depending which snapshot are they referring to.
• None – Atomicity is missing in some systems thereby not providing the same view of the database to multiple users editing the database. 
• ACID – For reliable database transactions, ACID or Atomicity, Consistency, Isolation, Durability is a safe bet. It allows for pre-screening transactions to avoid conflicts with no deadlocks.

3.    Replication – Replication ensures that mirror copies are always in sync.

• Synchronous Mode – Though it is an expensive approach as there is a dependency on the second server to respond, but it always ensures consistency. After receiving response from the second server, the first server sends back the ACK to the client. This ensures data is placed in multiple nodes at the same time.
• Asynchronous mode- In this mode, one database gets updated without waiting for the answer from the other database.Two databases could be not consistent in the range of few milliseconds.  This should explain why this cost-effective and synchronous replication method is also dubbed as ‘Eventaully Consistent.’

4.    Implementation Language- Implementation language helps to determine how fast a database will process. Typically NoSQL databases written in low level languages such as C/C++ and Erlang will be the fastest. On the other hand, those written in higher level languages such as Java make customizations easier.

Comparison of NoSQL databases

Comparison by Data (Size & Complexity)

Comparison by Type

Detailed Comparison

Conclusion

Here is another quick comparison between NoSQL and RDMS:

Opt NoSQL

1.     If data is huge, unstructured, sparse/growing

2.     Less rigid schema

3.     Performance & Availability preferred over Redundancy

4.      While scaling out is an out-of-the-box feature, it does not prevent scale up,

5.     Cost Effective- uses clusters of cheap commodity servers to manage the exploding data and transaction volumes

Opt RDBMS

1.    If Analytics, BI or Reporting is required.

2.     For Benefits of ACID

3.     Rigid Schema

4.     No redundancy allowed

5.     Allows Scale up & limited Scale-out (sharding)

6.     Expensive- rely on expensive proprietary servers and storage systems

This concludes our 3-part series on NoSQL and the merits in its adoption. We hope you liked reading it. Please leave us with your valuable comments in the box below.