Migration from MongoDB to TokuMX – Big performance gain

Benchmark

About a month ago I’ve done some benchmarking. I’ve compared TokuMX, TokuMXse, MongoDB 2.6, MongoDB 3.0 and WiredTiger. My use case is mainly based on constant selects and updates, all at the same time. Inserts were made before actual select/update test. Here are my results:

20150423032340

As you can see, TokuMX performed best. This benchmark was with 128MB physical ram on server and 250MB of data being inserted (2 mio rows and 100k select/update queries at the same time in total). Idea was to have larger data set selected/updated, than our actual RAM size is, because our production database is 160GB size and we only have about 80GB of ram. Idea is not to have everything in RAM. (I disabled compression feature of TokuMX in this case, because I didn’t want it to compress data to a point, where it could fit actual RAM size).

Upgrade TokuMX on production

After the benchmark, we decided to gradually upgrade all our MongoDB instances to Community TokuMX release. Recently we came to our Europe datacenter, where TokuMX really showed some great performance. Here is our execution time of one event on production:

Selection_039.2
psvc-write is call to MongoDB/TokuMX. You can clearly see, when we switched from MongoDB to TokuMX. Previous response time for psvc-write was around 20ms on average and was jumping for quite a lot. Current response time is 2ms and constant. It does not jump anymore and it’s about 10x faster than it used to be. There are several thousands of queries per second on this service, so you can imagine general performance boost for our adserving.

Disk usage and it’s performance impact

Thing to mention at the same time, is disk size. Our database used to be 160GB and after migration to TokuMX, it shrinked to 8GB in total. (At first I thought I lost some data, because this % of compression was incredible, but to my surprise, after manual check, all data was there.) Thanks to this fact, our performance gain was even bigger than it would have been if we didn’t use compression. You can imagine our database was way larger than physical RAM of server, but now 8GB can fit into our RAM without a problem.

Final note

This is not benchmark to promote TokuMX. Idea is to encourage you, to do same benchmark of your infrastructure. Think of your production environment, take actual data from production, create benchmarks based on your use case and you can make some wise choices on improving your current infrastructure.

Leave a Reply

help-hint.png
Purpose of the commenting system is to share your experience. I encourage you to post feedback with your own suggestions, ideas or optimizations regarding the topic of a blog post. What commenting system isn't for, is asking questions about similar issues of yours and requesting support for it. Blog post is provided as is and I am not here to solve all your problems. Please bear that in mind and try to avoid posting such comments. I do take privilege to remove comment from my blog for any reason whatsoever. Usually I do it when I sense a comment was posted only for spam/seo reasons or is out of blog post's topic. Thank you for reading this, now you may continue :)
 

Your email address will not be published. Required fields are marked *