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)

NOSQL data models

Comparison by Type

CategoryDescriptionName of the Database
Document OrientedData is stored as documents. An example format is FirstName=”Arun”, Address=”St. Xavier’s Road”, Spouse=[{Name:”Kiran”}], Children=[{Name:”Rohit”, Age: 8}]CouchDB, Jackrabbit, MongoDB, OrientDB, simpleDB,Terrastore, etc.
XML DatabaseData is stored in XML formatBaseX, eXist, MarkLogic Server, etc.
Graph databasesData is stored as a collection of nodes, where nodes are analogous to objects in a programming language. Nodes are connected using edges.AllegroGraph, DEX, Neo4j, FlockDB, Sones GraphDB, etc.
Key-value storeIn Key-value store category of NoSQL database, a user can store data in a schema-less way. A key may be strings, hashes, lists, sets, sorted sets and values are stored against these keys.Cassandra, Riak, Redis, memcached, Big Table, etc.

Detailed Comparison

StoreNameAPIProtocolQuery MethodReplicationWritten InCAP Characteristics
Key ValueRiakJsonRESTMapReduceAsyncErlangHigh Availability, Partition, Tolerance, Persistence
Key ValueMemcachedDBC, PythonMemcache protocolMemcache patternNoC, PythonConsistency, Partition, Tolerance
ColumnHBaseJavaAny Write CallMapReduceHDFSJavaConsistency, Partition, Tolerance, Persistence
ColumnCasandraCQL and ThriftThriftCasandra query languagePeer-to-PeerJavaHigh Availability Partition, Tolerance, Persistence
DocumentMongoDBBSONCDynamic object based language & MapReduceMaster Slave & Auto-ShardingC++Consistency, Partition, Tolerance, Persistence
DocumentCouchBaseMemcachedMemcached REST interface for cluster configurationJavascriptPeer-to-PeerC, C++, ErlangConsistency, High Availability, Persistence
GraphBaseInfo GridJavaOpenID, RSS, Atom, JSON, Java embeddedWeb user interface with HTML, RSS, Atom, JSON output, Java nativePeer-to-PeerJavaHigh Availability, Partition, Tolerance
GraphBaseInfinite GraphJavaDirect Language BindingGraph Navigation API, Predicate Language QualificationPeer-to-PeerJavaHigh Availability, Partition, Tolerance


Here is another quick comparison between NoSQL and RDMS:


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


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.

Girish Kumar

Girish Kumar

Technical Lead

Girish Kumar is a Technical Lead at 3Pillar Global and the head of our Java Competency Center in India. He has been working in the Java domain for over 8 years and has gained rich expertise in a wide array of Java technologies including Spring, Hibernate and Web Services. In addition, he has good exposure in implementation of complete SDLC using Agile and TDD methodology. Prior to joining 3Pillar Global, Girish was working with Cognizant Technology Solutions for more than 5 years. Over there he has worked for some of the biggest names in the Banking and Finance verticals in U.S. & U.K.

Girish’s current challenges at 3Pillar include getting the best out of Apache Hadoop, NoSQL and distributed systems. He provides day-to-day leadership to the members of the Java Competency Center in India by enforcing best practices and providing technical guidance in key projects.

3 Responses to “Selection Criteria for NoSQL Database part iii”
  1. Dinesh P on

    Good article. All the three parts were good and easy to understand

  2. leon shlimak on

    Great 3 blog posts. Helped me get my head around NoSQL. thanks :))

  3. ichard on

    Nice set of articles that introduces a newbie to NoSQL…

Leave a Reply

Related Posts

The 3 Keys to Building Products That Drive Retention –... I had the privilege of being invited to speak at the Wearable Technology Show in Santa Clara this week, where I gave a bit of a reprisal of a talk I d...
High Availability and Automatic Failover in Hadoop Hadoop in Brief Hadoop is one of the most popular sets of big data processing technologies/frameworks in use today. From Adobe and eBay to Facebook a...
3Pillar CEO David DeWolf Quoted in Enterprise Mobility Excha... David DeWolf, Founder and CEO of 3Pillar Global, was recently quoted in a report by Enterprise Mobility Exchange on the necessity of understanding and...
How the Right Tech Stack Fuels Innovation – The Innova... On this episode of The Innovation Engine podcast, we take a look at how choosing the right tech stack can fuel innovation in your company. We'll talk ...
The Road to AWS re:Invent 2018 – Weekly Predictions, P... For the last two weeks, I’ve been making predictions of what might be announced at AWS’ upcoming re:Invent conference. In week 1, I made some guesses ...