zardosht

Another thing to keep in mind is that not all systems are meant to be CP systems.

Your last question is a bit loaded with a bunch of "ifs", so let's unwind it. I don't know what MongoDB will "support" as far as other engines go. But assuming we, Tokutek, release something that we support that is our engine plugged into 2.8 using MongoDB's storage engine plugin, then according to the design we heard about at MongoDBWorld, that product will be what you think it is: Mongo with geo and "other bells", and TokuMX's compression + write performance.

But 2.8 is a bit away and the storage engine API is a very fresh development. I don't think anyone is in a position to be able to really guarantee what it would look like and how TokuFT (https://github.com/Tokutek/ft-index/) will plug into it. I definitely cannot make any promises.

If you are interested in TokuMX + some missing features from MongoDB (sounds like geo), and don't mind discussing your needs and use cases with our sales guys, please give us feedback at http://www.tokutek.com/contact/. As I mentioned previously, user feedback drives what we do, so at the very least, you can provide some additional data points.

Another engineer at Tokutek here. As you see, we are up to 2.4, and have been investigating 2.6 and Geo. With all possible features, whether they be from MongoDB 2.6 or things we innovate on our own like partitioned collections, we prioritize and address them based on customer and user feedback.

Also, 2.6 is not an all or nothing proposition that needs to be done in one release. Features with the most demand (whether it be the new write commands or aggregation framework improvements) will be done before others. We've done this before. When we released 1.0 that was based on 2.2, we also released hash based sharding with it which was a 2.4 feature. We did so because users demanded it.

As for pushing bug fixes upstream, we file bugs when we see them. Our VP of engineering was a winner in the MongoDB 2.6 bug hunt with SERVER-12878. SERVER-9848 and SERVER-14382 are among the bugs I've filed.

Not for single-server performance. The database level lock severely limits MongoDB's single server performance. Just look up the sysbench benchmark comparing MongoDB with TokuMX (which I work on)

TokuMX does have MVCC

TokuMX, which I work on, has document level locking and compression right now.

(I work for Tokutek)

Write concurrecy: yes, TokuMX does not have a database level reader/writer lock.

Index Building: yes, fractal trees can write data much more efficiently, so if index building is a problem, I bet TokuMX solves it.

Practically reducing file size: to be honest, I am not sure because due to our great compression, this has not been a general issue for our users. Our reindex command could reduce file size, but I cannot point to examples.

One of our big goals is to address storage issues MongoDB has.

ddorian, Can you elaborate what that means?

Roger,

I work at Tokutek (and wrote the post above). I'm sorry you ran into issues trying out TokuMX. I assure you, we are "ready", as we have users running in production.

Nevertheless, you ran into problems and that is unfortunate. If you have details, can you please share them with the tokumx-user google group? We might be able to help. I suspect the transition to using a transactional system like TokuMX where entire statements are transactional is resulting in some "gotchas", but that is just an educated guess.

-Zardosht

MongoDB 2.2 and 2.4

Just as in our TokuDB for MySQL product, we have zlib and lzma compression available.

Staying up to date is not an all-or-none proposition. We use feedback to drive direction. For example, even though we used 2.2 as a base, user feedback compelled us to include hash-based sharding, a 2.4 feature, in this release.

I work for Tokutek. Slava, thanks for the kind words. Just to clear up any possible confusion, this is the product. We release and support TokuMX. The research started roughly a year ago (the blog posts we've done are out there), and it has led to this.

We consider this to be full featured in the sense that we have a feature set that we feel users can deploy in production. As with any product, as users give feedback on what more they would like to see, be it existing MongoDB features or something else, we will use that feedback to enhance the product.

From Leif earlier, "TokuMX offers multi-document transactional semantics without application changes (snapshot reads), as well as protocol support for multi-statement (read-modify-write style) transactions, within a single shard. We are still designing how we want to present transactions in a sharded cluster."

TokuMX was forked from 2.2.4, but we have and will continue to add features from 2.4. For instance, hash based sharding is in TokuMX.

One cannot mix a replica set with TokuMX and MongoDB.

I work for Tokutek. In addition to performance improvements and compression, another cool thing about TokuMX: it's fully transactional. We hope this makes development of applications simpler.

Hope this helps, from Tokutek's website: http://www.tokutek.com/solutions/

One big differentiating feature between TokuDB and other write optimized databases is that TokuDB is fully transactional, it is ACID compliant. There is a demand for this.

AFAIK, TokuDB is the only write-optimized transactional data store. We (I work at Tokutek) are working on integrating with MongoDB as we speak, and when we do, we will bring transactional semantics to MongoDB in addition to improved performance.

So, I think there is still a big demand out there that TokuDB will be able to meet

Link to source code: https://github.com/tokutek

And our google groups: - tokudb-dev - tokudb-user