Monolithic Databases are dead
It’s today a common statement to affirm that hegemony of monolithic relational database system is ending.
ORM, Object Relation Model, were the last trial to perpetuate that pattern born in the 70’s. ORM bring to software development specialist the sweet feeling of directly interacting with objects. In Ruby on Rails world, Active Record was a wonderful implementation imposing its conventional relational approach on all web developer. In “Java world”, Hibernate has still a massive user base but controversy about its performance and ability to handle some complex situation are numerous.
Long story made short, Relational Databases persist data. That’s a fact as for all storage systems but they also structure the way we represent and organize our data model. They oblige us to think them through principles such as cardinality, relation entity, foreign keys and all those typical normalized form concept Entity Relationship Model. Furthermore, well know performance might quickly be an issue when mixing ORM and relational Databases. You want to make a query with 15 joins to display a deeply structured data set with few conditions and limit? You should rethink it.
Since 3 years and the emergence of NoSQL as a new paradigm, people started to rethink the said relational database hegemony. Keep in mind that NoSQL stand for “Not Only SQL” and not “NO SQL”. In day to day business deliveries, we observe more and more people introducing key-value store options into their architecture like Redis or Memcached. Some go further and replaced the usual Oracle, SQL Server, MySQL, PostgreSQL with a document oriented DB like MongoDB or CouchDB.
With Cassandra DB and the trend of Hadoop and Big Data, the database choice was extended with column oriented DB for massive data manipulation. That phenomenon is not finished. New approaches keep emerging. We have for example on-demand social database Salesforce Database.com. or the trendy graph oriented Neo4j.
With all those possibilities offered, all coming with their own advantages, we should re-evaluate the way we decide how to persist data. Each DB solve a specific problem. There is not one better than the other. But an intelligent mix of them could be a trade-off. That the idea behind polyglot persistence principle.
Consequently, a problem will often face in near future will be “how to integrate polyglot databases, ensure communication between them, consolidate access to them ?”. ORM have blurred boundaries previously existing between the Business Logic layer and the Persistence Layer, coding languages and query languages. What will replace ORM when we’ll have to use 3 or 4 protocols to request and store data?
To extend that introduction to Polyglot Database, and have a quick overview of the various data model I have mentionned, I recommend reading the summarized comparison by Kristof Kovacs. If you want to go deeper, buy the new book from “Seven Databases in 7 weeks” by E. Redmond and J. R. Wilson (still in Beta).