Is MongoDB a good alternative to RDBMs databases (like Oracle and Mysql)?
During the 10th Devoxx at Antwerp a presentation was given about MongoDB by Brendan McAdams from 10Gen.
This was one of the presentations during this event which I attended. I have to say I was pleasantly surprised by the ease of use and the features of this product. MongoDB is a NoSQL (non-relational, next-generation operational datastore and databases) database which is a schema-less database having huge advantages over most current existing RDBM databases.
The main pros of MongoDB can be divided in the following three:
The aim of this article is to give an idea of this product, by giving an overview of advantages and disadvantages. Next, I will give some pointers to take into consideration in order to determine if this type of database is suitable for a specific situation or not. At the end of this article I will provide the link to the presentation that was given, providing more details (like example models & queries).
This is ideal for flexible data model altering. It is easy to declare \ extend \ alter extra fields to the data model, and optional non used (nulled) fields take no space. Using RDBM databases one must run scripts first in order to update the model. In this case it can be done through coding and no scripting is needed.
- Structure of a single object is clearer
The structure of the model is in json and the structure is directly clear instead of deriving it from a table structure.
- No sql or hibernate queries (complex joins).
The nice thing about MongoDb is that the operations are easy to use (without any sql of course) and are key / value based. Easy expression language operators (i,e, $gt, $lt, ) can be used and usage of indexes & cursors is possible.
You can choose what level of consistency you want depending on the value of the data (e.g. faster performance = fire and forget inserts to MongoDB, slower performance = wait till insert has been replicated to multiple nodes before returning)
- Ease of scale-out
Scale reads by using replica sets. Scale writes by using sharding (auto balancing). Just fire up another machine and away you go. Adding more machines causes your working set to be distributed over all the machines.
- Conversion \ mapping of application objects to database objects not needed.
- Uses internal memory for storing the (windowed) working set, enabling faster access of data.
- If something crashes while it’s updating ‘table-contents’ – you loose all you data.
Repair takes a lot of time, but usually ends up in 50-90% data loss if you aren’t lucky. So only way to be fully secure is to have 2 replicas in different data centers.
- Indexes take up a lot of RAM. They are B-tree indexes and if you have many, you can run out of system resources really fast.
- Data size in MongoDB is typically higher due to e.g. each document has field names stored it
- Less flexibility with more complex querying (e.g. no joins)
- No support for transactions – certain atomic operations are supported, at a single document level
- At the moment Map/Reduce (e.g. to do aggregations/data analysis) is OK, but not blisteringly fast. So if that’s required, something like Hadoop may need to be added into the mix
Well suited for the following situations
- Scaling out
- High volume traffic
Less suited for the following situations
- High transactional applications
- Ad-hoc business intelligence
- Problems which require a sql solution
Of course, using a NoSQL technology like MongoDB involves some trade-offs and a different mindset than the traditional RDBMS. The main advantages as mentioned before are flexibility, scalability and performance. As the noSQL principle looks promising it is not (yet) the holy grail and therefor currently cannot replace the RDBMs for each situation. It is a different type of database which can be a solution, based on the requirements of the situation. It will not replace RDBMs databases but it I reckon it might run well side-by-side in the future (delegating model / functionality at which MongoDB is good at).
To get more information on MongoDB please follow this link to see the presentation that was given this week: link to presentation
It contains more in depth information as well as some neat query examples and code examples.