All of the data is on github. With the exception of the scan section, the graphs below have the absolute QPS for 48 concurrent clients using 8 tables and 1 table.
tl;dr
- MyRocks scans are up to 2X faster with readahead
- update-one - all engines do worse. This is expected.
- update-index - InnoDB 5.6 & 5.7 do worse. This doesn't repeat on the in-memory benchmark.
- read-write - InnoDB 5.6 does better on the 1 table test. This is odd.
- hot-points - all engines do worse. This is expected. MyRocks can do 3X better by switching from LRU to Clock once that feature is GA.
- insert - InnoDB gets ~50% of the QPS with 1 table vs 8 tables.
scan
This scan test uses one connection to scan the 800M row table. For the previous post there were 8 connections each scanning a different table with 100M rows/table. Fortunately the results here are similar to the results from the previous test.
- InnoDB 5.6 is faster than MyRocks without readahead.
- MyRocks with readahead is faster than InnoDB 5.6 but slower than InnoDB 5.7/8.0
update-one
All engines lose QPS with 1 table, the result is expected given all updates go to one row on this test. The result here is similar to the in-memory benchmark.
update-index
MyRocks and InnoDB 8.0 do great. InnoDB 5.6/5.7 lose QPS with 1 table but I did not debug that.
read-write range=100
Most engines do the same for 1 vs 8 tables. InnoDB 5.6 does much better with 1 table but I did not debug that.
hot-points
All engines lose QPS with 1 table and this is similar to the in-memory benchmark. That is expected because the test fetches the same 100 rows per query and this stays in-memory. The QPS for MyRocks can be ~3X better by switching from using LRU to Clock for the block cache but that feature might not be GA today.
insert
InnoDB gets ~2X more QPS with 8 tables than with 1. That result is similar to the in-memory benchmark. I didn't debug the source of contention.
No comments:
Post a Comment