Buy Percona ServicesBuy Now!

TokuMX is MongoDB on steroids

 | June 25, 2013 |  Posted In: Cloud and NoSQL, MySQL


TokuMX is MongoDB on steroidsI am actually quite excited about Tokutek’s release of TokuMX. I think it is going to change the landscape of database systems and it is finally something that made me looking into NoSQL.

Why is TokuMX interesting? A few reasons:

  • It comes with transactions, and all that good stuff that transactions provide: a concurrent access to documents (no more global write-lock in MongoDB); crash recovery; atomicity
  • Performance in IO-bound operations
  • A good compression rate, which is a money-saver if you use SSD/Flash
  • But it is also SSD/Flash life-time friendly, which is double money-saver

So having all these factors it is just a no-brainer if you have a MongoDB component in your setup. I actually started to use it as a service for queue in a system I’m working on right now, and my experience so far has been quite smooth.

I have some suggestions for Tokutek – please stop placing all files into a single directory (this is for both TokuDB and TokuMX) – if you have 1,000 databases with 100 tables or collections each, it gets quite messy with 100.000*x files in the single datadir.

In general I will agree with Baron, that TokuMX means for MongoDB the same as InnoDB to MySQL, and the NoSQL world just got a level-up… and it is becoming interesting.

Vadim Tkachenko

Vadim Tkachenko co-founded Percona in 2006 and serves as its Chief Technology Officer. Vadim leads Percona Labs, which focuses on technology research and performance evaluations of Percona’s and third-party products. Percona Labs designs no-gimmick tests of hardware, filesystems, storage engines, and databases that surpass the standard performance and functionality scenario benchmarks. Vadim’s expertise in LAMP performance and multi-threaded programming help optimize MySQL and InnoDB internals to take full advantage of modern hardware. Oracle Corporation and its predecessors have incorporated Vadim’s source code patches into the mainstream MySQL and InnoDB products. He also co-authored the book High Performance MySQL: Optimization, Backups, and Replication 3rd Edition.


  • Wow, you’re already testing mongodb!

    Just to be clear: mongodb has crash recovery since a couple year’s back. It does not have multi-statement or even multi-document transactions though, for which brings (what i’d like to call) experimental support.

  • Henrik,
    stock MongoDB does have crash recovery but is not acid, the journaling approach not only does double writes ( which will double disk io if enabling journaling from a pre 2.0 version, since it was off by default before that ). Mongo also has as default a 100 ms journal interval where data can still be loss, which is not ACID part. TokuMX fixes both of those issues.

    Having all the files in one dir is messy for sure, but humor credit goes to Tokutek for the *_dont_delete_me_* files.

    The biggest draw back I see to TokuMX right now, is not being able to sync from or to and stock MongoDB replica, so migrating / upgrading would require reloading data or writing a migrator.

  • Seems like phone ate part of my previous comment, I was trying to say: “for which brings (what i’d like to call) experimental support.”


    Yes but you’re still confusing things. What you’re saying is that MongoDB does not have Durability in the classic ACID sense. This is true. But it is crash safe: After a server crash you can restart it and continue from a consistent point without data corruption and no need to run some repair tools.

    In general I would say that out of the ACID properties stock MongoDB does perhaps a small “ac” at best. TokuMX brings an ACID storage engine (which is great!) but would still not give you AC if using sharding. Which most people seem to do.

  • Not being compatible with Mongo installs is a feature not a bug. When you look at all the advantages, and apparently no drawbacks of using the toku version, I applaud the forced upgrading.

Comments are closed