In this post I’ll share the results of a sysbench-mongodb benchmark I performed on my server. I compared MMAP, WiredTiger, RocksDB and TokuMXse (based on MongoDB 3.0) and TokuMX (based on MongoDB 2.4) in an IO-intensive workload.
The full results are available here, and below I’ll just share the summary chart:
I would like to highlight that this benchmark was designed to emulate a heavy IO load on a (relatively) slow IO subsystem. This use case, I believe, is totally valid and represents frequently used “cloud” setups with limited memory and slow IO.
The WiredTiger engine, as B-Tree based, is expected to perform worse comparing to RocksDB and Toku Fractal Trees, which, are designed to handle IO-intensive workloads. My assumption is that WiredTiger will perform better (or even outperform others) for CPU intensive in-memory workloads (see for example Mark Callaghan’s results). Also WiredTiger is expected to perform better with faster storage.
Resources
RELATED POSTS
Interesting….
It looks like both TokuMX/TokuSE and WiredTiger has same problems Innodb used to have few years ago – very uneven performance at sustained high load. I wonder who will fix the problems first 🙂
Bugs are open for WiredTiger in the JIRA. They are making progress, but there is more to be done.
https://jira.mongodb.org/secure/Dashboard.jspa
I know of someone working on adding something like InnoDB’s fuzzy checkpointing to the fractal tree engine.
Vadim: why did you choose a fanout of 128 for the toku engines?
Leif,
I am going to write on fanout soon. The optimal choice seems to be workload depended, but what I found out, with a small fanout, a lot of cache memory wasted by non-leaf pages and messages in them, which results in Fractal Tree performing a lot of unnecessary IOs by writing huge pages (4MB) to disk, evicting them and bringing new huge (4MB) pages from disk.
Vadim,
Cool. Sounds about right. I’ll be interested to see your data results.