Patrick McFadin recently wrote a post titled “MongoDB. This is not the database you are looking for”, where he mentions “In the past year there has been a rising chorus of users stuck on a cliff with MongoDB and are desperate to get out.” The key theme seems to be that MongoDB may run into issues at scale, and he encourages users to either migrate to or just start with Cassandra.
I would like to amend this: if you want to migrate off of MongoDB because your application has issues, you should try TokuMX. Migrations may be painful, so first try a solution that will hopefully not require your application to change much, if at all.
As we’ve covered in previous posts, TokuMX provides improved storage:
In Patrick’s post, he mentions three examples. Although we will never know, let’s see if TokuMX would have been worth investigating, based on the MongoDB issues reported.
In the first example, with Shift, the post states “MongoDB versus Cassandra; for us Cassandra had a number of advantages operationally. It’s so much more sane to deal with. You don’t to worry about replica sets, config servers and Mongo’s processes and its weird sharding infrastructure.” TokuMX has the same operational characteristics as MongoDB for sharding, so it’s very possible that TokuMX would be a bad fit here as well.
In the second example, with Shodan, the post states “I reached a point where writing to it got too slow (tons of page faults) and the sharding/replication model meant that new servers wouldn’t help with write throughput significantly”. This sounds like a use case in which TokuMX would excel. TokuMX offers significantly higher write throughput on data greater than memory, which seems to be the case because there were “tons of page faults”. We’ll never know if TokuMX could have solved this user’s problem, mainly because TokuMX was not released at the time this was posted, but should an example like this hit again for users in a similar position today, I’d recommend trying TokuMX.
In the third example, with Retailigence, the post states “MongoDB’s global write lock significantly impacted our ability to scale further without significantly increasing our investment in hardware, and significantly adding complexity to our deployment and code-base.” TokuMX does not have a global write lock. TokuMX has document level locking, which means it can scale up writes on a single machine. If the global write lock was truly the issue hurting this user, I suspect TokuMX would have helped tremendously.
So that’s two out of three examples that I would have loved to see the user try TokuMX before deciding to migrate off of MongoDB. We’ll never know for sure if TokuMX would have solved these issues, and at this point, it does not matter. Cassandra worked for these users and that is great.
I am more interested in the current MongoDB users who are running into similar issues as Shodan and Retailigence. To those, I have a message: before migrating, try TokuMX. You could save yourself a lot of effort. And to those users considering MongoDB for its developer friendliness but are worried about performance at scale, I would suggest they simply start out with TokuMX, and get the best of both worlds.
Percona’s widely read Percona Data Performance blog highlights our expertise in enterprise-class software, support, consulting and managed services solutions for both MySQL® and MongoDB® across traditional and cloud-based platforms. The decades of experience represented by our consultants is found daily in numerous and relevant blog posts.
Besides specific database help, the blog also provides notices on upcoming events and webinars.
Want to get weekly updates listing the latest blog posts? Subscribe to our blog now! Submit your email address below.