On February 3rd MongoDB, Inc. formally announced MongoDB v3.0 (the product release formerly known as v2.8). It includes a number of important enhancements, some of them of particular interest to users of the Tokutek distribution of MongoDB, TokuMX, or anyone thinking about using TokuMX.
Most notably, MongoDB v3 includes a storage engine API that can be used to create new, “pluggable” storage engine options for MongoDB; and that MongoDB itself is using it to integrate the WiredTiger storage engine technology they recently acquired when they acquired the company that developed it (also called WiredTiger).
Here’s some food for thought, with links to additional reading on each point.
- As previously discussed in a previous blog post, Tokutek will offer a “pluggable storage engine” that is compatible with the new MongoDB APIs. It will be built with the very same Fractal Tree indexing libraries that underpin TokuMX and TokuDB (i.e., new product, but proven technology). It will be called TokuMXse
See: YES, VIRGINIA, THERE IS GOING TO BE A TOKUMX STORAGE ENGINE FOR MONGODB 2.8
- Tokutek will continue to offer TokuMX (think of it as the bigger & broader sibling to TokuMXse) as this fork of MongoDB includes much more than Fractal Tree indexing. In other words, The MongoDB storage engine API takes us (and everyone else) only so far.
- It’s important to understand the WiredTiger storage engine supports two indexing models: 40-year-old B-tree and the more modern Log-Structure Merge Trees (LSM). However, in the 3.0 release MongoDB will support only B-tree indexing. Therefore, TokuMX (and/or TokuMXse) will continue to outperform basic MongoDB.
See: MongoDB Storage Engine Shootout : Round 1 : Indexed Insertion
|
1 |
<a rel="nofollow" href="/blog/wp-content/uploads/2015/02/iibench-tps-se-shootout-01-all-oplog-off.png"><img class="alignnone wp-image-8913" src="/blog/wp-content/uploads/2015/02/iibench-tps-se-shootout-01-all-oplog-off.png" alt="iibench-tps-se-shootout-01-all-oplog-off" width="647" height="485" /></a> |
|
1 |
(Courtesy Acme Benchmarking) |
- Even when MongoDB adds support for WiredTiger with LSM (later this year, or early 2016) TokuMXse will still have a number of important advantages. They are discussed in a white paper we offer on the topic.
See: A Comparison of Log-structured Merged & Fractal Tree Indexing
- MongoDB 3.0 supports Collection-level Locking, a big step forward from the previous Database-level locking limitation, but still far short of the Document-level locking supported in TokuMX from day one.
See: Diving Deeper into MongoDB 2.8 Collection-level Locking
The NoSQL marketplace is growing like crazy, and like MongoDB, Inc., Tokutek continues to enjoy success riding the same rising tide (albeit at the smaller / high-end of that market, where Big Data and IoT workloads come into play).
And, as MongoDB evolves, so will TokuMX (& TokuMXse).
Exciting times ahead.
Remember, MongoDB v3.0 is the release formerly known as MongoDB v2.8. Wherever you see “MongoDB 2.8” read it as “MongoDB 3.0.”
Feel free to comment or ask questions here on TokuView, and/or share your thoughts with me on Twitter via @dcrosenlund
The reasons people choose mongodb is: hype, easy to use/start, webscale.
While mongodb ~failed on webscale, they are beginning to fix it.
The good of tokumx is: better performance, some different features(more like performance-features like fast updates).
The bad of tokumx: less features than mongodb, less hype(they don’t even mention you exist, although many customers do).
The bad of both mongodb/tokumx:
1. The sharding thing (~all of it), compared to couchbase,riak,cassandra,aerospike,rethinkdb) etc.
While none of those support range-sharding, it gives you many features (see bigtable,hbase (global indexes etc))
This can be semi-done by doing a regex-sharding (see redislabs). Thus keeping every node the same and having ~range-based sharding.
2. More features: This is a little hard, since you don’t control the client-layer (you’d have to fork everyone of them) in some features, which isn’t preferable.
Probably just looking at the mongodb-top-feature-requests. Or a sane query-language. Not sure.
Meaning it will be hard to offer a better mongodb when you have to always keep compatibility. Probably build your own db and keep a mongodb-compatibility-layer. This way everyone wins (except mongodb).
AFAIK, collection-level locks were introduced in MongoDB 2.6. This release introduces document level locks, according to the official MongoDB blog https://www.mongodb.com/blog/post/announcing-mongodb-30
@Saurabh: With all due respect to our friends at MongoDB, they appear to be obfuscating things a bit.
As far as we can tell (V3 release candidates, code base, etc.) the MMAPv1 storage engine still does NOT support document-level locking. And, IMHO, this is the storage engine nearly all MongoDB users will choose. (It is the default, and WiredTiger is unproven in production environments.)
It is that unproven WiredTiger storage engine that will support document-level locking.
In other words, MongoDB appears to be happy letting the unsuspecting think that the document-level locking we’ve all been waiting for is coming in v3. I humbly submit, it is not.
> 40-year-old B-tree
That’s kind of a cheapshot. Microsoft’s BW-Tree is a B-Tree and it’s probably the fastest one out there now.
@Leon: Hi, Leon. I like to think I was trying to be “thought-provoking” (versus a cheap shot artist). And your point about Bw-tree is a fair one.
However, in the context of this post, I’d point out that MongoDB does NOT use a more modern form of B-tree. If it did, your point would be more relevant to this discussion.
Has there been any discussion on forking the drivers from mongo as well? We’re currently running in production using the MongoDB deprecated requestStart() method (mongo driver version 2.x) and the next version (3.x) removes it completely. Are there modern alternatives to support transactions using TokuMX in a Java environment?