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
