EmergencyEMERGENCY? Get 24/7 Help Now!

Announcing TokuDB v6.1

 | July 18, 2012 |  Posted In: Tokutek, TokuView


TokuDB v6.1 is now generally available and can be downloaded here.

New features include:

  • Added support for MariaDB 5.5 (5.5.25)
    • The TokuDB storage engine is now available with all the additional functionality of MariaDB 5.5.
  • Added HCAD support to our MySQL 5.5 version (5.5.24)
    • Hot column addition/deletion was present in TokuDB v6.0 for MySQL 5.1 and MariaDB 5.2, but not in MySQL 5.5.  This feature is now present in all MySQL and MariaDB versions of TokuDB.
  • Improved in-memory point query performance via lock/latch refinement
    • TokuDB has always been a great performer on range scans and workloads where the size of the working data set is significantly larger than RAM.  TokuDB v6.0 improved the performance of in-memory point queries at low levels of concurrency.  TokuDB v6.1 further increased the performance at all concurrency levels.
    • The following graph shows our sysbench.oltp.uniform performance on an in-memory data set (16 x 5 million row tables, server is 2 x Xeon 5520, 72GB RAM, Centos 5.8)

  • Modified table compression (tokudb_row_format) to be a hot operation
    • TokuDB v6.0 offered 4 choices of compression algorithms for each table (uncompressed, zlib, quicklz, and lzma).  Changing the compression of an existing table was a blocking operation in TokuDB v6.0 as the table was copied into a new table using the chosen compression.  This change is now performed online and the table is fully available for select, insert, update, and delete operations during the transition.
  • TokuDB is now the default storage engine
    • Tables created without specifying “engine=” now utilize the TokuDB storage engine.  Prior to this change MyISAM wast he default in MySQL 5.1 and MariaDB 5.2, InnoDB was the default in MySQL 5.5 and MariaDB 5.5.
  • The sql_mode server variable now defaults to NO_ENGINE_SUBSTITUTION
    • If the engine specified in a table create statement is unavailable, an error is returned to the user and the table is not created.  The prior behavior was to create the table with the default storage engine and issue a warning to the user.


    • The test is using the generic sysbench schema, each point query is of the form “select c from sbtest[1 .. 16] where id=[1 .. num_rows];”. Each client picks a random table and performs this query against a random value of id (the primary key column).

    • Mark,

      In 5.2, we had a latch that protected nearly all in-memory operations. In 6.0, we removed the latch from the query path, and in 6.1, we fully removed the latch from the system. This is what helped lead to many of the performance gains we have in 6.1. With this latch removed, we are now able to address other bottlenecks that were lying underneath this latch.

    • TokuDB does not currently support foreign keys, it it something we have considered adding to the product. Some people want FK support for constraint enforcement, others need cascading deletes. Does your use-case require one, the other, or both?

Leave a Reply