There are many attempts to classify the NoSQL world. Right now probably the most referred articles are Jonathan Elliot’s ☞ NoSQL ecosystem, Stefan Edlich’s ☞ NoSQL databases and yours truly ☞ Quick Reference to Alternative data storages.
But thanks to Emil Eifrem’s post ☞ NoSQL: scaling to size and scaling to complexity, I have realized that most of these classifications have missed a critical dimension: complexity. I don’t think there is anyone able to argue against the importance of this criteria for every business or project.
Emil’s post analysis the complexity level associated with different types of NoSQL solutions (i.e. key-value stores, column-based stores, document databases, graph databases). The presented graphs are fantastic (I allowed myself to include below one of them — it fits well with the design of MyNoSQL):
It is interesting to note that Emil’s post is describing the complexity from a single angle though: the programming model or differently said: the real data to data store impedance mismatch. I would argue that at large scale (even if “we are not all Google”) there is another factor contributing to complexity: operational complexity.
Just as a quick example, in a previous post about HBase, I was mentioning the fact that sometimes tweaking and tuning NoSQL systems may be easier than tuning RDBMS (in HBase case most of the tuning can be done at the VM level).
Anyway, going forward any new attempt to classify NoSQL systems should consider the complexity criteria from both its aspects: real data to data store impedance mismatch and operation complexity.
You should also check Emil’s presentation: “A NoSQL Overview and The Benefits of Graph Databases” embedded below: