Sysbench Benchmark for MongoDB – Performance Update

http://www.tokutek.com/2013/05/sysbench-benchmark-for-mongodb-v0-1-0-performance-update

by plasma • 13 years ago

63 24 13 years ago

tokutek.com

plasma• 13 years ago

Received an email from TokoDB about this new tech, available to play now.

Perf Blog: http://www.tokutek.com/2013/03/sysbench-benchmark-for-mongod...

Download Source: https://github.com/Tokutek/mongo

TokuTek say to contact them for using it.

TokuTek made TokuDB, a storage engine for MySQL that uses Fractal Indexes (as opposed to B-Tree), read more at http://www.tokutek.com/products/tokudb-for-mysql/

danielbarla2• 13 years ago

I'm curious about the fractal tree indexing referred to, but so far all the information I'm running across seems to be fairly one-sided. Performance is rarely so one-dimensional that I can accept statements like "When used in a database, they can be used in any setting where a B-tree is used, with improved performance" (from http://en.wikipedia.org/wiki/TokuDB) on face value. The algorithm claims to have strong insert performance, as well as higher compressability when compared to B-trees, and all the performance results play heavily on these.

What about read-heavy workloads, etc? Can someone with a bit more insight provide an objective overview?

leif5• 13 years ago

I am an engineer at Tokutek. Just talking about TokuMX, I have only seen MongoDB beat us on single-threaded, read-only workloads on extremely small data sets (like under 8K, or one MongoDB B-tree bucket).

The statement is really pretty much true. The best B-tree indexes (InnoDB) beat Fractal Tree indexes a little bit on in-memory reads, but we're not done tuning our implementation. On out-of-memory reads though, we usually beat B-trees because we compress so much better that we simply need to read less off disk.

Benchmarking is a tricky business though. Workloads can be varied, and you can probably find some corner cases where InnoDB beats TokuDB. I think we have some outstanding issues where the MySQL optimizer doesn't plan our queries properly, and we're still working on that. I'm a little out of touch with the MySQL side these days though so that could be wrong. But algorithmically, there are no cases where a B-tree index has a significant advantage over a Fractal Tree index.

Generally though, the read performance advantage we see is that if your indexes are Fractal Tree indexes, you can afford to maintain a richer set of indexes than you could have on InnoDB or MongoDB, and these extra indexes make your queries orders of magnitude faster. I think this is the most important (non-obvious) point to understand. I gave a talk about it here: http://www.youtube.com/watch?v=q6BnG74FZMQ

mjs• 13 years ago

The best explanation I've found of how it works (slides, PDF):

http://cdn.oreillystatic.com/en/assets/1/event/36/How%20Toku...

nemothekid• 13 years ago

What version of MongoDB was TokuDB forked from? Could I use this as a drop in replacement for a 2.4 deployment, or mix a replica set with 2.4 and Toku?

zardosht3• 13 years ago

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.

programminggeek2• 13 years ago

So, TokuMX is web scale?

In all seriousness, this looks super cool, but I'm easily fooled by benchmarks and I don't have any projects right now that really push MongoDB that hard, so it doesn't impact me other than giving us a potentially faster Mongo, which is cool.

zardosht3• 13 years ago

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.

programminggeek2• 13 years ago

That's awesome! I hope you didn't mind the joke too much. I really do use/love Mongo and I appreciate anyone who contributes to it.

kapilvt• 13 years ago

could you clarify this statement. mongodb native is consistent and atomic wrt to single documents. Are you saying that tokumx does something additional wrt to transactions (which also implies client api changes)?

toolslive• 13 years ago

is to be expected: you have a data structure where half of the inserts can be done in O(1).

philsnow2• 13 years ago

From what I understand, what mongodb needs is not more speed, but better acid guarantees by default.

zardosht3• 13 years ago

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."

philsnow2• 13 years ago

All built on the rock-solid webscale foundation of Mongo?

nasalgoat2• 13 years ago

I've signed up for this beta release - even without ACID transactions on a cluster-wide basis, the other features alone are worth it, especially the compression.

malkia• 13 years ago

I'm working with PostgreSQL right now, and it supports various indices (I'm sticking with btree for everything I have for now). Just made me wonder, whether the folks behind TokuDB cannot pursue PGSQL variant of their solution?

never mind - found some good answers here - http://postgresql.1045698.n5.nabble.com/Fractal-tree-indexin...

Sysbench Benchmark for MongoDB – Performance Update

Related Stories