Polyglot persistence and NOSQL

This is a 2 min read

Recently I had a real life encounter with a scenario where I had to design a solution with a strategy which turned out to be strategy called Polyglot persistence, which I learnt later doing some research. Actually 4 years ago from when I wrote this post  Martin Fowler put forth the concept Polyglot persistence.

So what’s polyglot persistence ?

A quick history – we all know RDMBS came into existence beating network and hierarchical database systems. Until this decade the concept of tackling unstructured data with No-SQL stores didn’t reach main stream with some open source and commercial products even though discussions started way back. We all know the limitations of using RDBMS for unstructured data or the data which doesn’t fit into a fixed data model.  While RDBMS’ dominance cracked, the delirium of RDBMS must go and NoSQL is the replacement went on for some time. But that cannot be right as well isn’t it ? Still we have some data that perfectly fit into a data model and we very well might need RDBMS. Also for storing relationships between entities came RDF semantic based Triple stores. Later more refined Query-able graph databases came into existence like Neo4J and TitanDB. Here is a good quora discussion about the same. So we may have different forms of data which does or does not fit into a data models, with or without relationships. How dow e tackle this ?

Now people have reached a state of maturity to say let use the data store which makes sense for the type of data. Lets mix and match. Polyglot persistence is just a fancy term to describe that.  This apparently is the future of data storage. Here is the presentation from Martin Flower and Pramod Sadalage.

I have borrowed a slide from the above presentation to give you a glimpse of how polyglot persistence might look like and here it is.

Screen Shot 2015-01-17 at 11.02.18 pm

Ok, What are the challenges in doing polyglot persistence ?

Just think about your Data Access layer, how will build a unified data access layer to access different data stores. What will be the impact on the business logic layer, what level abstraction we should design for. These are some few challenges to start with.

Here is a great article – this should get you started.

Think about this and share your thoughts. I will write about my opinions in a followup post.

Leave a Reply

Your email address will not be published. Required fields are marked *