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

Building a Microservice Architecture with Spring Boot and Do... This is the first post in what will be a 4-part series on building a microservice architecture with Spring Boot & Docker. This post will provide a...
Building a Microservice Architecture with Spring Boot and Do... Part II: Getting Set-Up and Started Introduction and Tools In this part, we'll get to work on building out the solution discussed in Part I. I'm goi...
Building a Microservice Architecture with Spring Boot and Do... Part III: Building Your First Microservice, its Container, and Linking Containers We're about ready to actually get started with building a microserv...
Building a Microservice Architecture with Spring Boot and Do... This is the fourth blog post in a 4-part series on building a microservice architecture with Spring Boot and Docker. If you would like to read the pre...
Innovation Wars, with Scott Bales Scott Bales joins us on this episode of The Innovation Engine to dive into the concept of "innovation wars." Among the topics we'll discuss are what c...


Sign up today to receive our monthly product development tips newsletter.