TOKUDB® VS. INNODB FLASH MEMORY
Details on the software settings for these tests can be found at the end of this page.
IIBENCH TESTING
Tokutek created the iiBench benchmark in 2008. The point of the benchmark is to measure the performance of indexed insertions over time. It uses an extremely simple schema, one table with a sequential insertion pattern for the primary key along with three integer fields storing random values. The table maintains 3 secondary indexes, each including several of the random integer fields. The iiBench application itself is currently maintained on Launchpad. The source code for iiBench is on GitHub.
OVER 9X FASTER INSERTIONS
iiBench is a popular open-source benchmark developed by Tokutek. It measures how fast a storage engine can insert rows while maintaining secondary indexes. This is often a critical performance measurement since maintaining the right indexes will dramatically improve query performance. The schema consists of short rows that model a retail point-of-sale transaction system. The results below show the insertion of 1 billion rows into a table while maintaining three multicolumn secondary indexes. At the end of the test, TokuDB’s insertion rate remained at 14,532 inserts/second whereas InnoDB had dropped to 1,607 inserts/second. That’s a difference of over 9x.
Platform: Centos 5.6; 2x Xeon L5520; 72GB RAM; LSI MegaRaid 9285; 2x 256GB Samsung 830 in RAID0
HIGHEST COMPRESSION
Compression is an always-on feature of TokuDB. We tested InnoDB compression with two values of key_block_size (4k and 8k) and with compression disabled. To find the maximum compression, we loaded some web application performance data (log style data with stored procedure names, database instance names, begin and ending execution timestamps, duration row counts, and parameter values). TokuDB achieved up to 26x compression, far more than InnoDB. In addition, in the second chart, you can see that even with compression, TokuDB performance remains superior, as indicated by the load speeds for each run.
Platform: Centos 5.6; 2x Xeon L5520; 72GB RAM; LSI MegaRaid 9285; 2x 256GB Samsung 830 in RAID0
EXTENDED WEAR LIFE
B-trees write small blocks, resulting in more writes and increased wear. Fractal Tree indexes write fewer and larger blocks, reducing wear. In this example, TokuDB (avg block size 215k) is performing 25x more writes than InnoDB (avg block size 23k).
Platform: Centos 5.6; 2x Xeon L5520; 72GB RAM; LSI MegaRaid 9285; 2x 256GB Samsung 830 in RAID0
SCHEMA CHANGES IN SECONDS, NOT HOURS
You can add or delete columns from an existing table with minimal downtime — just the time for MySQL itself to close and reopen the table. The total downtime is seconds to minutes.
Platform: Centos 5.6; 2x Xeon L5520; 72GB RAM; LSI MegaRaid 9285; 2x 256GB Samsung 830 in RAID0
SOFTWARE CONFIGURATION DETAILS
IIBENCH
Each data point is the average insertion rate for the last 2 million rows. Read more about the iiBench benchmark.
COMPRESSION
Read more about the compression benchmarks.
WEAR LIFE
IO data from iiBench benchmark (on this page).
HOT SCHEMA
Ran iiBench for 20 minutes, added a column to iiBench table, ran iiBench for 20 minutes. Read more about Hot Column Addition and Deletion (HCAD).
来源:TokuDB
郑重声明:本站内容如果来自互联网及其他传播媒体,其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享,并不代表本站赞同其观点和对其真实性负责,也不构成任何其他建议。