Small Datum

In previous results that I shared for the insert benchmark it was obvious that MyRocks throughput is steady when the workload transitions from in-memory to IO-bound. The reason is that non-unique secondary index maintenance is read-free for MyRocks so there are no stalls for storage reads of secondary index pages. Even with the change buffer, InnoDB eventually is slowed by storage reads and by page writeback. It was less obvious that MyRocks has more variance on both the in-memory and IO-bound insert benchmark tests. I try to be fair when explaining storage engine performance so I provide a few more details here and results for InnoDB in MySQL 5.7.10 & 5.6.26 along with MyRocks from our fork of MySQL 5.6. The binlog was enabled for all tests, fsync-on-commit was disabled and 16 clients inserted 500m or 2b rows into 16 tables in PK order. Each table has 3 secondary indexes. For MyRocks I made one configuration change from the earlier result. I changed level0_slowdown_writes_trig

I shared results last week for the insert benchmark. The test server for that result had fast SSD courtesy of several NVMe NAND flash devices. I repeated tests on a server with slower SSD and the results are interesting. Regardless of the storage device, MyRocks did better when the database was larger than RAM and InnoDB 5.7.10 did better when the database fit in RAM. But the difference between MyRocks and InnoDB 5.7.10 for the in memory workload is much smaller on slow SSD than it is on fast SSD. It is always risky to ignore the context from benchmark results and the important context here is the performance of the storage device. Slower SSD hurts InnoDB more than it hurts MyRocks because MyRocks is more efficient for writes. Spending less IO on writes saves IO to do more writes or more reads as I  previously demonstrated  for Linkbench. When the database fits in RAM there are no reads from storage. But there are many writes to storage whether or not the database is larger than R

I haven't been sharing many performance results on my blog as I have been saving results for my conference talks. Later this year I expect to blog more and travel less. Today I will share two results from the insert benchmark to compare MyRocks and InnoDB. tl;dr - both are expected MyRocks insert performance doesn't degrade when the database is larger than memory InnoDB in MySQL 5.7 scales much better than in MySQL 5.6 for in-memory workloads InnoDB in MySQL 5.7 wins for in-memory, MyRocks wins for io-bound Configuration This test does inserts in PK order into a table with 3 secondary indexes. Without the secondary indexes the workload is friendly to a b-tree. But secondary index for a b-tree is read-modify-write and the reads from and writes to storage will make InnoDB slower when the working set doesn't fit into RAM. InnoDB is likely to do better than other b-trees because of the insert buffer . With MyRocks, non-unique secondary index maintenance is read-free

Percona Live 2017 is a great place to learn about MyRocks , MongoRocks and RocksDB . The MyRocks community continues to grow as one of the talks is from Alibaba. I am excited that they help make MyRocks better. Talks about RocksDB MyRocks Deep Dive - a tutorial by Yoshinori Matsunobu. I continue to learn about MyRocks from him. This is a great way to learn about MyRocks. MyRocks: best practice at Alibaba - a talk by Jiayi Wang and Dengcheng He that explains the work by the Alibaba MySQL team to evaluate and improve MyRocks for a production workload. MariaRocks: MyRocks in MariaDB - a talk by Sergei Petrunia on the work to implement MyRocks and then merge it into MariaDB. If you want to know what it takes to connect MySQL to a new storage engine then Sergei is the person to ask. MyRocks Engineering: deploying a new MySQL storage engine to production at Facebook - a talk by Herman Lee on the effort to confirm that MyRocks is performant, correct and robust for production and t