tl;dr
- MyRocks can be more than 2X slower than for InnoDB.
- InnoDB in 5.7 does better than in 5.6
- TokuDB without compression is comparable to InnoDB without compression and does much better than InnoDB when prefetching is enabled.
- Compression usually has a small impact on scan performance for MyRocks with zstd and a much larger impact for TokuDB with zlib. I wonder how much of this is a measure of zstd vs zlib.
- Scans were usually slower for all engines after fragmentation but the impact was larger for MyRocks and TokuDB than for InnoDB.
Configuration
I used my sysbench helper scripts with my sysbench branch. For tests with X tables there was 1 connection per table doing a full scan and when X > 1 the scans were concurrent. The scan time was measured twice -- first immediately after the load and index step and then after many updates have been applied. The second measurement was done to show the impact of fragmentation on scan performance.
I repeated tests on different hardware:
- 48core.ssd - server has 48 HW threads, fast SSD and 50gb of RAM. Tests were done with 8 tables and 100M rows/table and then 1 table with 800M rows.
- i3.ssd - a core i3 Intel NUC with Samsung 850 SSD, 8gb of RAM and 4 HW threads. The test used 2 tables and 80M rows/table.
- i3.disk - a core i3 Intel NUC with 1 disk, 8gb of RAM and 4 HW threads. The test used 1 table and 160M rows/table.
I repeated tests for MyRocks, InnoDB and TokuDB:
- I compiled MyRocks on August 15 with git hash 0d76ae. The MyRocks tests were done without compression and with zstd compression (myrocks.none, myrocks.zstd). I did one test for MyRocks with a binary that did not use special instructions to make crc32 faster (myrocks.none.slowcrc) and learned that fast crc doesn't make a difference on this test. It would be a bigger deal for an IO-bound test doing point queries.
- I used TokuDB from Percona Server 5.7.17. The TokuDB tests were done without compression and with zlib compression. I tried tokudb_disable_prefetching ON and OFF (toku5717.none, toku5717.none.prefetch), but I have been setting this to ON for my OLTP benchmarks because enabling it ruined some OLTP results.
- I used InnoDB from upstream 5.6.35 and 5.7.17. The performance_schema was enabled. The InnoDB tests did not use compression.
The results below list the number of seconds to scan the table(s) and the time relative to InnoDB from MySQL 5.6.35. For the relative time a value greater than 1 means the engine is slower than InnoDB. These values are reported for pre and post where pre is the measurement taken immediately after loading the table and creating the secondary index and post is the measurement taken after applying random updates to the table(s).
See tl;dr above for what I learned from these results.
Large server
These are results from 8 tables with 100M rows/table and then 1 table and 800M rows/table on the large server.
48core.ssd - 8t x 100m
pre pre post post engine
secs ratio secs ratio
221 2.302 246 2.256 myrocks.none
201 2.093 211 1.935 myrocks.zstd
96 1.000 109 1.000 inno5635
75 0.781 86 0.788 inno5717
67 0.697 94 0.862 touk5717.none
39 0.406 69 0.633 toku5717.none.prefetch
190 1.979 224 2.055 toku5717.zlib
48core.ssd - 1t x 800m
pre pre post post engine
secs ratio secs ratio
638 1.065 1032 1.627 myrocks.none
916 1.529 1063 1.676 myrocks.zstd
599 1.000 634 1.000 inno5635
434 0.724 449 0.708 inno5717
513 0.856 735 1.159 toku5717.none
249 0.415 502 0.791 toku5717.none.prefetch
1525 2.545 1776 2.801 toku5717.zlib
Intel NUC
These are results from the Intel NUC using SSD and then a disk.
i3.ssd - 2t x 80m
pre pre post post engine
secs ratio secs ratio
181 1.448 192 1.560 myrocks.none
182 1.456 189 1.536 myrocks.none.slowcrc
219 1.752 238 1.934 myrocks.zstd
125 1.000 123 1.000 inno5635
114 0.912 107 0.869 inno5717
i3.disk - 1t x 160m
pre pre post post engine
secs ratio secs ratio
330 1.304 348 1.343 myrocks.none
432 1.707 451 1.741 myrocks.zstd
253 1.000 259 1.000 inno5635
257 1.015 261 1.007 inno5717
Charts
Below are charts from the large server tests for 8 tables & 100M rows/table and then 1 table with 800M rows.
No comments:
Post a Comment