Over the past 6 months or so we have been making quite a few changes in the technology we use at Zuberance. One of the biggest shifts has been transitioning from Postgres to MongoDB for our persistence. Like many people I had a hard time wrapping my head around Mongo at first. After years of developing on SQL databases the very idea of a schema-less persistence layer seemed wrong. I also had a healthy fear of the unknown and started grasping at straws for reasons why I didn’t want to use Mongo. I developed a sudden devotion to the tenants of ACID (an acronym I had never spent much time considering before) and tried to convince myself that there was something inherently logical in highly normalized data structures.
The fact is that for many web applications there is no need for relationships between data and the main requirement of the persistence layer is to allow instances of objects to be persisted. Being a small team we needed the lowest overhead possible to get object instances saved and didn’t want to spend time trying to pretend we knew what our final data schema would be.
With Mongo you can be up and running and persisting your data in a matter of minutes. Depending on your language of choice it will be trivial to convert an object instance into a Mongo DBObject (basically a Map) and store it. No need to create your database or your tables. Mongo simply creates those the first time you insert data.
Think of the Schemas!
A common fear of Mongo is that the schema-less nature of the system will lead you down a path of data chaos the likes of which your team has never seen. This risk, as they say, is greatly overstated. Coming from the world of Java we were already used to representing database schemas at the code level using tools like JPA annotations. So in a Java/SQL stack you maintain your schema in two places and need to make sure those things stay in sync. From a code perspective very little changes when moving to Mongo. Your code still enforces data structures, but making changes to this structure is no longer a painful process of maintaining DB migration scripts and timing releases carefully with DB downtime. Could this system be abused? Of course. Garbage in will always be garbage out but this is true whether the garbage conforms to a schema or not.
MongoDB for a Flexible Architecture
My favorite thing about Mongo is that it doesn’t force you into a box when designing your data. Different projects often have very different needs for data persistence. In our case the majority of our data is stored in straightforward collections which correspond to object instances in our code. On the other hand our aggregation system uses a completely different structure to aggregate daily data on the fly and make report generation a much simpler affair.
We have been adopting a lot of new technology at Zuberance over the past few months and it has made me realize the benefits of keeping a flexible mind as a programmer. I mostly write Scala these days but the new concepts I have been exposed to working with tools like Mongo and Akka have made me a better developer regardless of the specific language I’m using.
