Buy Percona ServicesBuy Now!

Announcing TokuMX v1.0: Toku+Mongo = You Can Have It All

 | June 19, 2013 |  Posted In: Tokutek, TokuView


Tokutek is known for its full-featured fast-indexing technology. MongoDB is known for its great document-based data model and ease of use. TokuMX, version 1.0, combines the best of both worlds.

  • So what, exactly, is TokuMX? The simplest (but incomplete) answer is that TokuMX is MongoDB with all its storage code replaced by Tokutek’s Fractal Tree indexes.
  • How do Fractal Tree indexes improve MongoDB? The direct benefits include high-performance indexing, strong compression, and performance stability – in other words, the performance stays high, even when data is larger than RAM.
  • Are there any features in TokuMX that MongoDB doesn’t have? Yes. We have added support for transactions to TokuMX, so that TokuMX is ACID compliant and has MVCC. We have also added support for clustering indexes, which dramatically accelerate many types of queries.
  • So TokuMX is MongoDB with the storage code replaced? Almost. It’s actually better than that. We have replaced the locking and replication code in MongoDB — code that sits above the storage layer — so that TokuMX scales with client count on read/write workloads. And TokuMX has great replication performance.
  • But will my MongoDB application code still work? Yes. At the application level, all the regular MongoDB commands will still work. Well, almost all. We have deprecated some commands: compact is no longer needed since Fractal Tree indexes don’t fragment; repairDatabase is no longer needed since TokuMX is transactional, and so forth. In other words, we deprecated commands that support no-longer-necessary housekeeping. You can use them, but they just don’t do anything. All the commands involving you and your data still work, and require no change to your application. All the new features are extensions of the language. You can access them with simple syntax changes or use TokuMX as a drop-in replacement for MongoDB.

So, if you have a MongoDB application that could benefit from faster indexing, or better compression, or ACID transactions, or more concurrency, check out TokuMX.

To learn more about TokuMX:

TokuMX features



    • Hi Dorian.

      Correct, we don’t have a native Windows version for now. Registering is not required for downloading our software, but it will allow you join our community. By joining the community of users, you will get product updates (like when there is a Windows version available), invitations to webinars and other events, and access to premium content. We are careful to be respectful of your contact information and will focus on high-value information.

      • Hi, Totty. We have no firm plans to offer a Windows version at this time. However, those plans could easily change due to customer demand. Reach out to our sales team via the Contact form if you’d like to discuss.


  • Congratulations to the team at Tokutek on making TokuMX, it is very impressive! Just a quick question-Is TokuMX compatible with 10gen MongoDB Monitoring Service and 10gen MongoDB Backup Service?

    • Hi Ryan. Thanks.

      TokuMX is not compatible with MongoDB Backup Service. As for MongoDB Monitoring Service, we are testing the interaction to make sure everything works.

    • Yes, sharding works—and it performs wonderfully because of clustering indexes. However, just like with replication, you can’t have a mixed cluster containing TokuMX and MongoDB nodes. It’s all TokuMX or nothing.

      • Great ! Congrat to tokutek team ! (I’m already testing it with mysql, and it’s working really fine 🙂

  • Sounds like awesome work!

    What version of MongoDB are you relying on? I have just read about Mongo 2.2.3 . Are there any time plans to come up with a version based on MongoDB 2.4? Will be hard to test / use your product for all the guys who are using an up-to-date version of Mongo …

    • We are based on the 2.2 series. We are up to date with all bugfixes and features in 2.2.4, except for 2d indexes and background indexing. From 2.4, we’re also missing the beta text indexes and the 2dsphere indexes, and a few operators like $setOnInsert. I would guess that 2.4 compatibility is not a big deal for the majority of users.

      We will be adding features from 2.4 based on customer interest, for example, we backported hash-based sharding for this reason. If we see enough interest for other features, we can do it, but we don’t have a timeline for these things yet. You should talk to us if you have specific features that you need, our support email address and the mailing lists are good places for that.

    • Yep! We actually use them in our test infrastructure. There are a few things to watch out for though, around transactions. Anything you want to be transactional needs to be done over the same connection, and these drivers use a connection pool.

      With the python driver, you can use start_request (described here to make sure a set of operations all use the same connection. You need to do this if you want to use multi-statement transactions. I think you can use Pool#checkout and Pool#checkin in the ruby driver, but I haven’t looked too closely at it yet. If you need help, let me know.

      Additionally, if you try to insert a very large array of objects using the ruby driver, it will transparently group them into smaller batches (to avoid exceeding the maximum BSON object size) for you. In MongoDB, this doesn’t really make a difference because batched inserts are sort of “we’ll do as many as we can but stop midway if there’s an error”, but in TokuMX, this will break up what seems like a single transactional batch insert into several transactions, which is maybe not what you want. We have a ticket to look in to fixing the driver so that it also wraps the batches in a transaction, but for now if you have large arrays, you should just be aware of this behavior and think about adding your own transaction around it if that matters to you. I’m not sure if the python driver does this off the top of my head but I wouldn’t be surprised if it did.

  • Any plans to add 2d indexes ? I’m using a lot of geospartial queries, and i need that functionality. Without it i can’t try TokuMX for my project.

Leave a Reply