EmergencyEMERGENCY? Get 24/7 Help Now!

Announcing MyRocks in Percona Server for MySQL

 | October 24, 2016 |  Posted In: MySQL, Percona Server

PREVIOUS POST
NEXT POST

Announcing MyRocks in Percona Server for MySQL.

RocksDB has been taking the world by the storm!

RocksDB counts Facebook, LinkedIn, Pinterest, Airbnb and Netflix among its users. It is the storage engine for many open source database technologies, including CockroachDB, Apache Flink, TiKV and Dgraph. It is also integrated with MySQL and MongoDB as the MyRocks and MongoRocks storage engines, respectively.

Percona was an early RocksDB supporter, as well as an early adopter. MongoRocks was included with Percona Server for MongoDB since its first GA version.   

RocksDB has proven itself to be a very stable, high-performance technology. The enthusiastic,  high-energy engineering team behind it cares not just about making it work for Facebook (which can be the case with some technologies built mainly for internal use), but also about satisfying the needs of the open source community at large. So it shouldn’t be a big surprise that RocksDB is getting such traction.

We have been watching RocksDB’s MySQL implementation, MyRocks, very closely. It’s been steadily getting better performance and adding more and more features – making it feasible for a broad range of general MySQL workloads (not just Facebook use cases).

What was missing, however, were large scale production deployments of MyRocks. There is a big difference between how a technology does in tests versus how it does “in the wild.” Facebook announced last month that they completed a large-scale migration from InnoDB to MyRocks, and now use MyRocks in production.

MyRocks in Percona Server

As a result, Percona decided it was time to bring MyRocks to Percona Server. Including MyRocks with Percona Server will help make it easily accessible to more MySQL users. I announced the addition of MyRocks to Percona Server during my keynote speech at this year’s Percona Live Europe.

The MySQL community’s reaction was overwhelmingly positive. They can’t wait to explore MyRocks, and see if it is right for their workload. Percona engineering teams are working as fast as possible to release the Beta version of Percona Server with MyRocks (with a GA soon to follow), but if you can’t wait that long you can check out experimental MyRocks Docker images here.

Reading this, many of you are likely wondering: when? In our experience, integrating a storage engine into database software is not a trivial task, and progress is often tricky. Completing 95% of the integration is easy enough (sufficient for most workloads). However, the last 5% of the integration – dealing with outliers and corner cases – can be quite difficult. You often discover more issues just when you think it’s done.

We know you have high expectations for Percona Server, and need it to handle the most demanding environments. With this in mind, we’re not going rush a Percona Server with MyRocks release. We will provide the experimental builds of MyRocks in Percona Server in Q1 2017, and we encourage you to start testing and experimenting so we can quickly release a solid GA version.  

Percona’s purpose is to champion the best solutions for the open source community, and we think including MyRocks as an option for Percona Server for MySQL is a step in that direction.

PREVIOUS POST
NEXT POST
Peter Zaitsev

Peter managed the High Performance Group within MySQL until 2006, when he founded Percona. Peter has a Master's Degree in Computer Science and is an expert in database kernels, computer hardware, and application scaling.

7 Comments

  • MyRocks seems pretty similar to TokuDB. They are both write-optimized. MyRocks uses LSM tree while TokuDB uses fractal tree.

    How do the 2 compare? Which one would you recommend using?

    • While both RocksDB and TokuDB are “write-optimized”, TokuDB is optimized for lots of writes with few reads, especially few concurrent reads while loading data. MyRocks doesn’t appear to have the same performance problems that TokuDB has related to reads (of course YMMV and you need to test your workload) so it offers an alternative to TokuDB. TokuDB can become unbalanced leading to performance problems, and it suffers from performance issues when the data set becomes fragmented, which can happen after updating data.

      Basically if you have a write-mostly workload, TokuDB is (and continues to be) a good solution, but for general OLTP workloads, MyRocks will likely perform better.

    • RocksDB is great for read key lookups, but it has a poor range based queries. Both engines are write optimized but RocksDB does a really good job on storage efficiency. I don’t have numbers to compare directly with TokuDB, but against InnoDB is pretty considerable. i.e. a 197MB csv file loaded into InnoDB took 352MB only the ibd file while RocksDB took 289MB (both zlib/LZ4 compression algorithms, raw data without indexes).

      • Does TokuDB have faster range-based queries than MyRocks? That’s a big thing for me because a lot of my queries are range-based using a secondary index.

Leave a Reply to Wang Cancel reply