After TokuDB was announced as a new storage engine for MySQL, it made me very curious, but I didn’t try it out until now.
I try to check it from different aspects and I’ll be the blog it steps by step. I don’t do any serious benchmarking, just play with it, and see if it could be fit into Kinja’s MySQL ecosystem.
I use one of our development servers as a TokuDB playground. Sadly that hardware is not the same as the database masters nor as the slaves, so performance tests couldn’t be made on that piece of metal but many other ways are open to doing this.
I’ve installed the tokudb plugin from the Percona repository. The setup was quite easy and fast, the documentation is nice.
I decided to leave all the MyISAM tables as – is but convert all the InnoDB tables to TokuDB. To achieve this, I’ve done the following:
$ mysql --silent --silent -e “select CONCAT(CONCAT(‘ALTER TABLE ‘,CONCAT_WS(‘.’,table_schema, table_name)), ‘ ENGINE=TokuDB;’) FROM INFORMATION_SCHEMA.TABLES WHERE engine=’InnoDB’;” > tokudb_alters.sql $ mysql < tokudb_alters.sql
After the following commands completed the first things I noticed were the following:
- The disk space usage went dramatically low. From the current size of~500Gb, the database shrunk to 170Gb. Even better if I said the most of our biggest tables are already compressed. I’d say uncompressed Kinja is around ~560 Gb iirc, to the disk space ratio is about 1:3. Sweet.
- I also couldn’t compress all the tables: full-text indexes are not supported by TokuDB
- It causes no problem when a table on a slave is TokuDB and on master it is InnoDB. The replication thread just runs, and the SQL thread is just applying changes even in ROW based replication. There will be easy to see on a running slave how it performs beside of InnoDB
These are the first impressions. I want to check out next time the backup possibilities of TokuDB. (As well as slave rebuilds. etc.)