I switched an app from MySQL to MongoDB 2 years ago.
First, why? The app purpose is to dispatch work order to people on the field, but also gets back some datas such as reports, pictures, gps coords, action times, an so on.
At the beginning, app was developed for a customer, based on its specifications. As business was growing, every customer has to own needs, and most of the time, its customization. Adding more and more fields whatever the approach on the SQL DB becomes messy.
At this point, we got 2 ways : first, to put every specific stuff into a big text json encoded field (at a point, this is a key feature of postgresql 9.4 with abilty to search within the field). second, to find another way.
MongoDB appears to be a nice choice to get more flexibility.
The Pros:
- no fucking fixed schemas
- embedded object-oriented approach
- “new and fashion”
The cons:
- No more “join” => need to rethink the way data is organized
- Write performance
- “new and fashion”
2 years after, here are some feedbacks. For information, we are collecting a lot of GPS points from smartphone on the field, even if some are dropped.
The Pros:
- For the flexibility, it is a very good choice. Less pain on specific customization. But, the most difficult part was to think out-the-box in order to defined a schema which is NOT “SQL-Join-oriented”. And specifically, to think “Object” and use embedded stuff.
- Read performance is really acceptable : from millions of GPS coords, even without any index, any specific data is found within 400 sec on my server (2 CPU, 8Go RAM, RAID1, 7200rpm disk).
- Map Reduce : I love map reduce. It brings a way to make really nice processing on the fly. Couple with Hadoop, you can get really nice analytics
The cons:
- the “Join” approach from usual SQL DB. it lacks, but often because the schema is not well thought.
- Pure write performance.
The Question : was it a good or bad choice? For a business and cost point of view, this was and still is a really good choice, no way. But, we graph-oriented DB, and other choices (Cassandra, PstgreSQL 9.4, HBase, …), there are many openings to test in the future.
Alex'Blog 