Two weeks ago we released an Alpha release of Percona Server with TokuDB. Right now I am on a final stage of evaluation of TokuDB for using in our project Percona Cloud Tools and it looks promising.
What is the most attractive in TokuDB? For me it is compression, but not just compression: TokuDB provides great performance over compressed data.
In my synthetic tests I saw a compression ratio of 10:1 (TokuDB LZMA to InnoDB uncompressed), in the real production data it is less, 6:1, but still impressive.
In our servers we have 4 x SSD Crucial M500 960GB combined in RAID5, which give 2877.0 GB of usable space. With TokuDB we should be able to pack around 15TB of raw data. Of course we can try InnoDB compression, but the best we can get is 2x compression without sacrificing performance.
And of course TokuDB is transaction, fully ACID-compliant with automatic crash-recovery storage engine.
This all makes TokuDB a very attractive choice for handling terabytes of data (or as it popular to say nowadays “BigData”).
One of first operational questions we have is how to handle backups.
For backups we use LVM partitions and the mylvmbackup tool. Unfortunately Percona XtraBackup is not able to handle TokuDB tables (and probably won’t be able anytime soon). The other choice is to use TokuDB Hot back-up, available by Tokutek Enterprise Subscription. I did not test it myself, so I can’t provide any feedback.
And of course there are things which I do not fully like in TokuDB:
- No Foreign Keys support. It is not a big issue for us, but I know for some users this is a showstopper.
- Time-based checkpoints. You may not notice a direct effect from this, but we clearly see it in our benchmarks. Every 60 sec (default timeperiod between checkpoints) we see a drop in throughput during write-intensive benchmarks. It is very similar to drops in InnoDB we tried to solve (and are still trying), for example see Adaptive flushing in MySQL 5.6. My advice to the Tokutek team would be to also look into a fuzzy check-pointing, instead of time-based.
- All TokuDB files are stored in a single directory, sometime with mangled filenames. This especially becomes bad in sharding or multi-tenant environments when tens of thousands of files are in the same directory
Well, I guess for now, we will take these limitations as TokuDB specific and will deal with them.
Next week we plan on a Beta release of Percona Server with TokuDB, so stay tuned!
The post Percona Server with TokuDB: Packing 15TB into local SSDs appeared first on MySQL Performance Blog.