Kiril Savino explains in detail the evoluton of GameChanger from using MySQL to MongoDB:
It was at about this point that I saw MongoDB hit version 1.1. Here’s what went through my head:
- I can scrap the whole JSON->dict->Model->SQL->Table overhead
- My underlying datastore can more exactly mirror my API structure
- Denormalization is an inherent part of the Document model
- I’ll get this whole scalability roadmap for free
We never looked back. It took 6 months to frankenstein our way from MySQL onto MongoDB entirely (I don’t believe in big-bang rewrites, so we built cross-DB bridging code, and migrated our data system-by-system across).
There’s a fragment that made me wonder if CouchDB wasn’t an option too:
But at GameChanger we’re tackling this hairy problem: we synchronize data across mobile devices and all kinds of wacky web end-points, and the whole things is built on a RESTy JSON-based HTTP API. Everything, including our website itself, consumes our API.
Kiril explains in a comment that what set off CouchDB was the lack of “secondary indexes or arbitrary querying”. Or differently put, they felt uncomfortable having to always use MapReduce.
Original title and link for this post: MongoDB Case Study: From MySQL to MongoDB at GameChanger (published on the NoSQL blog: myNoSQL)