After TokuDB was announced as a new storage engine for MySQL , it made me very curious, but I didn’t tried it out until now.
I try to check it from different aspects and I’ll be blog it step 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 do 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 achive this, I’ve did 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 more 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 slave is TokuDB and on master it is InnoDB. The replication thread just run, 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 besides 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.)