I 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.
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.
Vadim,
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.”
Alexis,
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.
Heh, copy pasted the same error. Trying to say: “for which *TokuMX* brings (what i’d like to call) experimental support.”
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.