Percona Server for MongoDB storage engines in iiBench insert workload

Percona Server for MongoDB storage engines in iiBench insert workload

PREVIOUS POST
NEXT POST

storage enginesWe recently released the GA version of Percona Server for MongoDB, which comes with a variety of storage engines: RocksDB, PerconaFT and WiredTiger.

Both RocksDB and PerconaFT are write-optimized engines, so I wanted to compare all engines in a workload oriented to data ingestions.

For a benchmark I used iiBench-mongo (https://github.com/mdcallag/iibench-mongodb), and I inserted one billion (bln) rows into a collection with three indexes. Inserts were done in ten parallel threads.

For memory limits, I used a 10GB as the cache size, with a total limit of 20GB available for the mongod process, limited with cgroups (so the extra 10GB of memory was available for engine memory allocation and OS cache).

For the storage I used a single Crucial M500 960GB SSD. This is a consumer grade SATA SSD. It does not provide the best performance, but it is a great option price/performance wise.

Every time I mention WiredTiger, someone in the comments asks about the LSM option for WiredTiger. Even though LSM is still not an official mode in MongoDB 3.2, I added WiredTiger-LSM from MongoDB 3.2 into the mix. It won’t have the optimal settings, as there is no documentation how to use LSM in WiredTiger.

First, let me show a combined graph for all engines:
engines-timeline

And now, let’s zoom in on the individual engines.

WiredTiger:

wt-3.0

RocksDB + PerconaFT:

rocks-perconaft-3.0

UPDATE on 12/30/15
With an input from RocksDB developers at Facebook, after extra tuning of RocksDB (add delayed_write_rate=12582912;soft_rate_limit=0;hard_rate_limit=0; to config) I am able to get much better result for RocksDB:
rocks-3.0-dyn12M

What conclusions can we make?

  1. WiredTiger’s memory (about the first one million (mln) rows) performed extremely well, achieving over 100,000 inserts/sec. As data grows and exceeds memory size, WiredTiger behaved as a traditional B-Tree engine (which is no surprise).
  2. PerconaFT and RocksDB showed closer to constant throughput, with RocksDB being overall better, However, with data growth both engines start to experience challenges. For PerconaFT, the throughput varies more with more data, and RocksDB shows more stalls (which I think is related to a compaction process).
  3. WiredTiger LSM didn’t show as much variance as a B-Tree, but it still had a decline related to data size, which in general should not be there (as we see with RocksDB, also LSM based).

Inserting data is only one part of the equation. Now we also need to retrieve data from the database (which we’ll cover in another blog post).

Configuration for PerconaFT:

Configuration for RocksDB:

Configuration for WiredTiger-3.2 LSM:

Load parameters for iibench:

PREVIOUS POST
NEXT POST

Share this post

Comments (5)

  • Ives Stoddard Reply

    great post Vadim!

    January 6, 2016 at 2:28 pm
  • Moni Reply

    Thank you for good article about this engine.

    January 13, 2016 at 2:23 am
  • Jetware Team (@jetware_org) Reply

    Thank you Vadim for great article. Did you test new versions of these three engines? AFAIK at least RocksDB and WiredTiger had more improvements last year.

    January 24, 2017 at 6:35 am
  • Kevin Hanson (@hungarianhc) Reply

    I’m actually pretty darn impressed by all 3. MongoDB has come a long way.

    February 4, 2017 at 1:38 pm
  • Colin Reply

    I’d love to see performance of deletes as last time I tried MongoDb the delete performance is the one that was simply unacceptable and caused me to have to look elsewhere..

    March 31, 2017 at 6:58 pm

Leave a Reply