This version offers performance enhancements over previous releases, especially for multi-client scale up and point queries, and extends the cases where ALTER TABLE is non-blocking, in particular adding Hot Column Rename.

TokuDB v5.2 maintains all our established advantages: fast trickle load, fast bulk load, fast range queries through clustering indexes, hot schema changes, great compression, no fragmentation, and full MySQL compatibility for ease of installation. See our benchmark page for details.

Multi-client workloads

In TokuDB v5.2, we have reworked our locking scheme to better support multi-client workloads, and as always, we have focused on large databases. How did we do? Let’s check out some benchmark numbers.

SysBench

This is a SysBench comparison of InnoDB 1.1.8 and TokuDB v5.2. Prior to the run we started the database from a cold back-up (the cache is empty at the beginning of the 1 client thread run) and ran for 1 hour at each number of client threads. The following graph shows a significant performance improvement (10%-60%) at all measured levels of concurrency. The values shown are the average transactions per second for the final 15 minutes of the benchmark.

Additional details on the software settings for Sysbench can also be found in the Appendix at the end of this page.

TPCC

This is a TPCC-like comparison of InnoDB and TokuDB v5.2 on a 5000 warehouse database. The horizontal axis is the number of clients, the vertical axis shows throughput (New Order Transactions/10 seconds). Our multi-client work brings us to parity with InnoDB for this test.

Other key improvements

Both the Sysbench and the TPCC-like benchmarks have strong point-query components. Our improved performance over InnoDB, even with one client, shows that we are now outperforming InnoDB for point queries, at least in these tests. We’ll be blogging more specifically about point query performance so stay tuned. One way we achieve better point query performance is to have a different read-block size and write-block size. I’ll explain what that means in later blog posts, but one consequence is that read-intensive loads on RAIDed disks now perform many fewer I/Os.

In other news, we previously released Hot Indexing (HI) and Hot Column Addition and Deletion (HCAD). In both cases, the downtime of these Alter Table operations goes from hours to seconds.

In v5.2, we have added Hot Column Rename to the suite of online operations we support. You’ll be able to change the name of a column in a matter of seconds, just as you can now add or delete columns. We have also made Optimize Table hot, but it’s important to note that in TokuDB, Optimize Table only flushes background work, such as that produced by a column addition or deletion. It does not rebuild indexes, nor does it need to, because TokuDB indexes don’t fragment.

Summary

TokuDB v5.2 offers great scaling with increasing client thread count, improved point query performance, and Hot Column Rename. In the next couple of weeks, we’ll be posting more performance information, so stay tuned. TokuDB v5.2 is available for download.

Appendix – Configuration Details

Hardware

Centos 5.7; 2x Xeon L5520; 72GB RAM; 8x 300GB 10k SAS in RAID10.
TokuDB (running MySQL 5.1.52) is configured to use 36GB cache,
and InnoDB (running MySQL 5.5.16) with 52GB cache.

The difference is because InnoDB uses direct I/O whereas TokuDB reserves space for the OS cache.

TokuDB MySQL Config File (TokuDB v5.2 on MySQL 5.1.52)

[mysqld]
max_connections=400
table_open_cache=2048

InnoDB MySQL Config File (InnoDB v1.1.8 on MySQL 5.5.16)

[mysqld]
innodb_flush_method=O_DIRECT
innodb_thread_concurrency=0
innodb_log_file_size=1900M
innodb_log_files_in_group=2
innodb_file_per_table=true
innodb_log_buffer_size=16M
innodb_file_format=barracuda
innodb_buffer_pool_size=52G
innodb_flush_log_at_trx_commit=1
max_connections=400
table_open_cache=2048

TPCC
All TPCC-like benchmarks were run with the following command line:

tpcc-mysql/tpcc_start localhost tpcc root 5000 \
         ${num_threads} 10 3600

Sysbench
All sysbench benchmarks were run with the following command line:

sysbench --test sysbench-0.5/sysbench/tests/db/oltp.lua
--oltp_tables_count 16  --oltp-table-size 50000000 --rand-init on
--num-threads ${num_threads} --oltp-read-only off
--report-interval 10 --rand-type uniform --mysql-socket
/tmp/mysql.sock --mysql-table-engine tokudb --max-time 3600
--mysql-user root --mysql-password --mysql-db sbtest
--max-requests 0 --percentile 99 run

mysql> SHOW CREATE TABLE t;
| t     | CREATE TABLE `t` (
  `a` VARCHAR(255) DEFAULT NULL,
  `b` BIGINT(20) NOT NULL DEFAULT '0',
  `c` BIGINT(20) NOT NULL DEFAULT '0',
  `d` BIGINT(20) DEFAULT NULL,
  `e` CHAR(255) DEFAULT NULL,
  PRIMARY KEY (`b`,`c`),
  KEY `a` (`a`,`b`,`d`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1

Now we’d like to perform the following query:

SELECT sql_no_cache COUNT(d) FROM t WHERE a = 'this is a test' AND b BETWEEN 8000000 AND 8100000;

Great! We have index a, which cover this query. Using a should be really fast. You’d expect to use the index to jump to the beginning of the ‘this is a test’ values for a and from there continue using the index to the 8000000 section of the b‘s. From there it’s just a range query.

We added some test data (see this script) to see what would happen. We added 10M lines and made the value of a be ‘this is a test’ in every field. We got:

mysql> SELECT sql_no_cache COUNT(d) FROM t WHERE a = 'this is a test' AND b BETWEEN 8000000 AND 8100000;
+----------+
| COUNT(d) |
+----------+
|   100001 |
+----------+
1 ROW IN SET (3.53 sec)

So the question is, is this any good? Checking the explain, we get:

mysql> EXPLAIN SELECT sql_no_cache COUNT(d) FROM t WHERE a = 'this is a test' AND b BETWEEN 8000000 AND 8100000;
+----+-------------+-------+------+---------------+------+---------+-------+--------+--------------------------+
| id | select_type | TABLE | TYPE | possible_keys | KEY  | key_len | REF   | ROWS   | Extra                    |
+----+-------------+-------+------+---------------+------+---------+-------+--------+--------------------------+
|  1 | SIMPLE      | t     | REF  | PRIMARY,a     | a    | 258     | const | 201438 | USING WHERE; USING INDEX |
+----+-------------+-------+------+---------------+------+---------+-------+--------+--------------------------+
1 ROW IN SET (0.00 sec)

Yow! Index a is used, but it’s not being used as expected. The ref type in the explain means that MySQL is performing a scan on all rows where a is ‘this is a test’ and not filtering on the values of b. This translates into looking at 10M rows instead of 100K, so this query plan is looking at 100x too much data.

This is a MySQL query planner bug, and it has been reported here. However, there is a workaround (in this case):

mysql> SELECT sql_no_cache COUNT(d) FROM t USE INDEX(a) WHERE a = 'this is a test' AND b BETWEEN 8000000 AND 8100000;
+----------+
| COUNT(d) |
+----------+
|   100001 |
+----------+
1 ROW IN SET (0.04 sec)

By adding a use index(a) — which shouldn’t do anything because we’re already using index a! — we get an 88x speedup. This is in line with looking at 1% of the data. Consulting the explain, we see:

mysql> EXPLAIN SELECT sql_no_cache COUNT(d) FROM t USE INDEX(a) WHERE a = 'this is a test' AND b BETWEEN 8000000 AND 8100000;
+----+-------------+-------+-------+---------------+------+---------+------+--------+--------------------------+
| id | select_type | TABLE | TYPE  | possible_keys | KEY  | key_len | REF  | ROWS   | Extra                    |
+----+-------------+-------+-------+---------------+------+---------+------+--------+--------------------------+
|  1 | SIMPLE      | t     | range | a             | a    | 266     | NULL | 201438 | USING WHERE; USING INDEX |
+----+-------------+-------+-------+---------------+------+---------+------+--------+--------------------------+
1 ROW IN SET (0.00 sec)

We’re still using index a, but the type of the query plan has changed to range (which is what we would have expected all along). Now we are filtering on a and b.

Take home messages

• Query planners are complicated things, and the MySQL query planner has some bugs.
• It’s possible, in many cases, to deal with those bugs by checking the explain of a query that doesn’t behave as expected.
• Although adding a use index isn’t the best software engineering practice, if you need to get fast query speeds and you’re getting a faulty query plan, it’s a handy tool to know about.

Of course, Tokutek customers care a lot about indexes. TokuDB for MySQL and MariaDB lets you define lots of indexes, because indexing is fast. You can define indexes with random keys, indexes that won’t fit in memory, clustering indexes that cover all queries, …. This insertion speed translates directly into query speed, so TokuDB can address many performance complaints, ranging from write- to read-intensive workloads.

Remember that if you take care of your indexes, they’ll take care of you!

Why SQL Wins

Sergei Tsarev (Clustrix) gave a great overview of the last 50 years of database development. He talked about the early days, in which what we now think of as database functionality had to be implemented in each application. Programmer productivity was therefore low.

As modern SQL databases emerged, productivity shot up since databases bundled up common functionality with an easy-to-code interface. This now seems like a golden age of databases, in which transactional semantics were hashed out.

Fast forward to today. Database performance has failed to keep up with database demands. Sergei didn’t talk much about why this is. Personally, I have my own take on what caused this problem. The demand side is due to the success of SQL semantics. Relational databases capture what many (most?) people want to do with a database. So they keep pounding harder on the database. On the performance side, the data structures that drive databases (B-trees) were invented in early ’70s, when computers had a very different balance of resources. As the decades went by they grew to be more and more out of balance with each new generation of hardware, creating many of today’s performance bottlenecks. And now, back to Sergei’s talk.

Sergei talked about how NoSQL was a reaction to these performance issues. He pointed out that what NoSQL does is kill off chunks of database functionality. That doesn’t make those requirements go away. It just makes the database appear to go faster — but, it’s important to note, not the system. It means that the “slow code” gets moved to the application layer. So the performance problem isn’t solved and programmer productivity goes down.

He predicts a move back to SQL solutions, as these performance problems get solved. (And since our TokuDB storage engine solves a bunch of them, I agree!)

Migrating From MyISAM to InnoDB

Matt Yonkovit (Percona) gave a very detailed talk on moving MyISAM tables to InnoDB. The audience was really into it, and the questions were coming fast and furious. As someone interested in transactional databases, I don’t think that much about MyISAM, but it was clearly on a lot of people’s minds.

The most striking thing about this talk was the contrast with Sergei’s talk. Matt did a great job of detailing all the parameters you need to worry about when running InnoDB — parameters you don’t need for MyISAM. I expected this to be the source of some disappointment. After all, databases, in Sergei’s conception, are supposed to abstract away common problems so that the application programmer can work on their problem-specific code.

Instead, InnoDB comes with a large number of tuning parameters, some of which are set by default to values that have to be changed to make InnoDB useable at all. The odd part for me is that there was a consensus in the room that the large number of parameters was a strength of InnoDB, and the lack of tunability was a weakness of MyISAM. Call me old fashioned, but this kind of resetting of defaults is computer work, not work for humans.

I came away from this talk more proud that ever that TokuDB has almost no tuning parameters. Expect this to continue. We even have the math for why this no-tuning approach works.

Loads of other talks

There were loads of other great talks — on solid state drives, on replication, on many of the topics that are critical to the care and feeding of a MySQL database. Maybe I can wrangle a trip to Percona Live London so I can report on those.

FAQ

Q: How do I tune TokuDB?
A: You don’t!

TokuDB has almost no parameters you can set, and many of them are related to diagnostics — things like how often should the information about insertion or query progress be updated. We recommend that parameters be left unchanged.

Q: What do I do when indexes are bigger than memory?
A: Nothing!

TokuDB is based on Fractal Trees, which are designed to index fast, even when indexes are bigger than memory.

Q: What’s the best way to partition in TokuDB?
A: Don’t!

Partitions are a poor replacement for covering indexes. Define the indexes that actually solve your problem, and TokuDB will keep up with the insertion rate.

Q: How often should I run OPTIMIZE TABLE?
A: Never!

TokuDB tables don’t fragment, so OPTIMIZE TABLE doesn’t defragment them.

Q: How often should I dump and reload a table?
A: Never!

Same as OPTIMIZE TABLE.

Q: How much downtime should I schedule for adding an index?
Q: How much downtime should I schedule for column addition/deletion?
A: None!

Well, maybe a few seconds. In TokuDB 5.0 we announced Hot Column Addition and Deletion and Hot Indexing, so that these ALTER TABLEs incur minimal downtime, on the order of a few seconds.

“There are many environments where you could end up creating N! indices to cover queries for queries against lots of dimensions.”

[Just a note: this is only one of several points he made. I just wanted to dig into this one in some detail. Here goes...]

Although it is, in theory, possible to generate a workload that would take N! indexes, this is not a realistic (or useful) bound (leaving aside that this workload would kill partitioning!). For one thing, it would take N! queries to exercise all those indexes. And the queries would have to include every field in the where clause — as we’ll get into below.

So what is a reasonable bound on the number of covering indexes that would be useful? Not surprisingly, there’s no one answer, so let’s look at a couple of cases.

Before we get started, let’s simplify the discussion by making all indexes CLUSTERING, which means they include all fields, and therefore, we only need to look at the WHERE clause of our queries to figure out what needs covering. More on that later.

How many indexes does it take to beat partitioning?

When partitions are used to avoid table scans, it’s because the secondary indexes do not cover the queries. All it takes to make them cover whatever query they are used on is to declare them CLUSTERING. Once you do that, they will be faster than using the same indexes with partitions.

So not only do you not need N! indexes, what you need is the same number of indexes! (Here the first ‘!’ is factorial, and the second is emphasis!)

A little detail here: suppose you have partitioned on field T and you have defined an index on (A,B,C). Now get rid of partitioning and define CLUSTERING index (T,A,B,C). Lather, rinse, repeat.

How many indexes does it take in general to cover your queries?

As noted above, you only need to look at the WHERE clause because making your indexes CLUSTERING takes care of the rest of the fields you might need in your query.

Next we need to consider what rows get examined in a query. Suppose you have a query like:

SELECT * from foo WHERE A = 5 and B = 10 and C < 20 and D = 30;

What do you need to cover this query? It turns out that once you hit an inequality, MySQL stops searching in the index and starts a scan of the index. So that means that a CLUSTERING index on (A,B,C) is all you need. There’s no need for D in the index definition. If you also had:

SELECT * from foo WHERE A = 5 and B > 10 and D = 30;

the CLUSTERING index on (A,B,C) would also work for this query.

So how many indexes do you need? Certainly not N!. Take a look at your most important queries. Consider their WHERE clauses and throw away all the fields after the first inequality test. Throw away any set of fields that’s a prefix of another set. So if you end up with:

(A,B,C)

(A,B)

(C,D,A)

you don’t need the (A,B). The remaining sets of field are your candidates. Each CLUSTERING index is as big as the primary table — that’s what makes them so good for covering lots of different queries! While this may sound like it would take up a lot of space, TokuDB uses very aggressive compression, typically getting 10x-15x compression, so it’s possible to add quite a few such indexes.

So how many indexes do I need?

How many mission-critical queries do you have? How many of them can be clumped together using CLUSTERING indexes? When talking to customers, the most number of useful indexes I’ve seen is 20. That sounds like a lot for two reasons: size and update time. But the total size should be less than twice the original data size, assuming at least 10x compression. And TokuDB is all about updating indexes fast, even when they don’t fit in memory, so this hasn’t been a complaint either. I’m going to go out on a limb and say that a typical upper bound is 20.

What if I don’t know what queries I’ll be performing?

In this case, partitioning isn’t the answer. We already beat the performance of partitioning by switching over the indexes to CLUSTERING. What you need in this case is flexibility. When you get a new query type, what you need is TokuDB’s hot indexing, which allows you to add an index with basically no downtime (3 seconds downtime is typical).

But what happens if I always get queries that are unrelated to previous queries and they are mission critical and they are never repeated? Such a hypothetical leads us down the N!-index path. It doesn’t seem that realistic.

Good but not perfect covering is OK too

Finally, it’s not necessary to tailor your indexes perfectly to your queries. The CLUSTERING index (A,B) covers the query

SELECT * from foo where A = 5 and B = 10 and C = 20 and D = 30;

even though C and D are not mentioned. CLUSTERING indexes cover all queries. It’s all a matter of getting the table into the best possible order for your queries. You can still get benefit from an index that isn’t the perfect order, and that index will cover more queries. It’s a tradeoff.

If you are interested in evaluating TokuDB for deployment and want to know how to proceed, try the following

1. Download TokuDB (free for trials and evaluations).
2. Review the evaluation guide.
3. Convert an existing InnoDB table to TokuDB. Make sure that the table is big enough to be realistic. You’ll really notice the difference when the table is bigger than memory.
4. Convert your indexes to CLUSTERING indexes. Maybe they don’t all need to be CLUSTERING, but the easiest eval is to make them all CLUSTERING and cut back if needed.
5. Add more indexes using the steps outlined above.
6. Feel free to contact support@tokutek.com. We’re here to help.

The talk is an introduction to performance issues related to big data without getting too technical. You’ll have to decide if I succeeded with the “not too technical” part. My take is on how to keep big data indexed — not surprising since the work in this talk is the basis for TokuDB®, Tokutek’s MySQL storage engine for keeping large data indexed. A video of my talk can be found here.

Elephants on a Trapeze: Keeping Big Data Agile from Tokutek on Vimeo.

Marko Mäkelä recently posted a couple of “tips and tricks” you can use to improve InnoDB performance. Tips and tricks. A general purpose relational database like MySQL shouldn’t need “tips and tricks” to perform well, and I lay the blame on design choices that were made in the early ’70s: the B-tree data structure underlying all OldSQL databases. B-trees were designed for machines that had very different performance characteristics than the machines of today. Hardware has changed, but B-trees are the same. Tips and Tricks are an attempt to make up the difference.

So B-tree implementers — InnoDB, Oracle, MS SQL Server — are fighting an uphill battle; they’re fighting the future. B-trees just aren’t meant to cope with high-bandwidth, slow-seek-time storage systems, because they perform unnecessary disk seeks. In fact, they aren’t meant to cope with lower-bandwidth, fast-seek-time storage systems (like SSDs), because they waste bandwidth. Hardware trends move computers further and further from B-trees’ sweet spot. In 1972, they were a great idea, but a lot has changed.

Don’t get me wrong. InnoDB is a great piece of software. In my own testing, its B-tree implementation outperforms the big enterprise implementations, though it lacks some features like hot indexing and hot column addition and deletion.

So the problem is OldSQL B-trees, which have two big shortcomings. These are both illustrated very well in the tips and tricks posting. They are slow to index, and they fragment. Let’s look at Marko’s points one by one:

• Marko’s first point is that “Data Dictionary Language (DDL) operations have traditionally been slow in MySQL”. The slow part of DDL is mostly ALTER TABLE commands.
  • Hot Column Addition and Deletion and Hot Indexing, recently released in TokuDB 5.0, brings the downtime of these schema changes from hours to seconds.
• Marko’s second point is that insertions, deletions and updates “can be slow [with InnoDB] even despite the change buffering in MySQL 5.5.”
  • Fast insertions, deletions and updates have been a hallmark of TokuDB’s Fractal Tree Indexes since they were introduced.
• Marko’s next point is that if you populate an InnoDB index out of order, it will fragment. His proposed solution involves dropping and adding indexes, which means table downtime.
  • The best way to deal with fragmentation is to not fragment your tables in the first place. So what’s the solution? You guessed it: TokuDB tables don’t fragment by design, so this particular chunk of maintenance is not needed.
• Finally, Marko discusses fill factors in B-trees, and the impact of packed versus unpacked nodes on future modifications.
  • TokuDB is based on cache-oblivious analysis, which means that you don’t need to worry about fill factors, and it means that there are very few parameters to set. In fact, we recommend that you leave the parameters set to the defaults.

Treats, not tricks

In short, TokuDB’s Fractal Tree indexes are fast to update (20x-80x faster than InnoDB) and never fragment. Hot schema changes, fast insertions, no fragmentation, and no tuning. That’s what happens when your solution matches your hardware.

We have sessions coming up at both O’Reilly and Collaborate 11 conferences next week, as well as a booth at O’Reilly. Please come by and tell us your “tips and tricks” (and band-aids and duct tape) for working around old database structures, and we’ll work to get you on a better path with Tokutek’s NewSQL alternative.

In the previous HCAD post, I described HCAD and showed that it can reduce the downtime of column addition (or deletion) from 18 hours to 3 seconds. In fact, the downtime of InnoDB is proportional to the size of the database, whereas the downtime for TokuDB 5.0 depends on the time it takes for MySQL to close and reopen a table — a time that’s independent of database size. Go ahead and build bigger tables. The HCAD downtime for TokuDB won’t increase.

You may be wondering how we do HCAD. Here goes:

Under the hood

TokuDB is based on Fractal Tree indexing, one of the cools features of which is that they replace random I/O with sequential I/O. The way this happens has an impact on how HCAD happens, so here’s the 20,000 foot view.

You can think of everything in a TokuDB table (or index) as a message. There can be messages to insert a row, or update a row, or delete a row. Rather than delivering these messages immediately, the messages are bundled up by common destination, and they progress towards the leaves of the Fractal Tree indexes when there are enough of them to make the disk-head movement worthwhile. They are applied in the right order, obviously, in order to keep the semantics of the SQL commands correct.

Even a query can be thought of as a message, except in the case of a query, it has to be delivered on the spot, even if that means moving the disk head. The query “sees” all the messages ahead of it, so it gets all the right answers, once again, according to the SQL semantics.

An HCAD command generates yet another type of message: it’s a broadcast message that needs to be applied to every row. Sticking the message into the Fractal Tree indexes is fast. In fact, the downtime associated with HCAD has nothing to do with the TokuDB work. Instead, MySQL closes and reopens a table on an alter table command. This causes dirty pages associated with that table to be flushed. The downtime is on the order of seconds, though we have seen extreme cases with many dirty pages and very large RAM where this can take a couple of minutes.

And since this is TokuDB, you also get to define clustering indexes, which reference all columns and therefore speed up lots of queries. The HCAD message gets injected into the primary table and into each clustering index.

The work of changing the rows does not happen when the HCAD message is injected. Rather, the broadcast message makes its way down to the leaves as other messages push it along. In this process, when an HCAD message reaches a row — either because other messages push it along or because of a query — the row gets rewritten to include the added column or exclude the delete column, as the case may be. Once the work is done to rewrite a row, the HCAD work is done for that row. The user can choose to have this work done immediately — say by a query that touches all rows — or lazily — as part of the normal operation of the database. Neither case involves downtime, and once the work is done to rewrite a row, the HCAD work is done for that row.

You can schedule the background work of updating the rows as follows. Recall that any query that touches a row, HCADs the row. A query of the form

SELECT COUNT (*) FORCE INDEX(X);

where X is primary or one of the clustering indexes, will touch each row and finish all the HCAD work for that index. I should emphasize that you don’t need to do this. Everything works fine without it. This
is an option if you want to get the work done all at once.

Trying it out

This is a 3 step process:

1. Download TokuDB (free for evaluation purposes or in production up to 50GB of user data).
2. Read section 3.4 of the User’s Guide.
3. Load your tables and go!

Learning more

I had the privilege of sitting down for the MySQL Community Podcast with Sheeri Cabral and Sarah Novotny where we spoke about the new TokuDB 5.0 features in depth. See Episodes 39 and 40.

Enjoy!

Hot Indexing Overview

TokuDB v5.0 introduces several features that are new to the MySQL world. Recently, we posted on HCAD: Hot Column addition and Deletion. In this post, we talk about Hot Indexing.

What happens when you try to add a new index, as follows?

mysql> create index example_idx on example_tbl (example_field);

In standard MySQL 5.1 InnoDB, the table example_tbl gets locked while all indexes, including the primary key, get rebuilt. In the InnoDB plugin for 5.1, as well as in previous releases of TokuDB, things are improved in that the table is only locked while the one index is built. This still however can easily cause hours of downtime.

TokuDB v5.0 introduces Hot Indexing. You can add an index to an existing table with minimal downtime. The total downtime is seconds to a few minutes, because when the index is finished being built, MySQL closes and reopens the table. This means that (unlike HCAD) the downtime is not at the time of the command, but later on. Still, it is quite minimal, as the following experiment shows. The details of the table are here.

Adding index (Year, Month, DayofWeek) took 31 minutes, 34 seconds for the InnoDB 5.1 plugin, during which the table was locked for insertions/deletions/updates.

TokuDB 5.0 took 9 minutes, 30 seconds to add the same index. At the end of this time, the table was locked for under 2 seconds (we polled the database at 1 second intervals, and it was only locked at one of these test points).

The v5.0 release is fun for me. I get to blog about great features that bring great value to people trying to run big data in MySQL. Stay tuned for the details of how we do hot indexing.

Learning More

1. I had the privilege of sitting down for the MySQL Community Podcast with Sheeri Cabral and Sarah Novotny where we spoke about the new TokuDB 5.0 features in depth. See Episodes 39 and 40.
2. Try TokuDB v5.0 for yourself.

Hot Column Addition and Deletion (HCAD) Overview

TokuDB v5.0 introduces several features that are new to the MySQL world. In this series of posts, we’re going to present some information on these features: what’s the feature, how does it work under the hood, and how do you get the most out of this feature in your MySQL setup.

Today we start with HCAD: Hot Column Addition and Deletion. Many users have had the experience of loading a bunch of data into a table and associated indexes, only to find that adding some columns or removing them would be useful. An

alter table X add column Y int default 0;

or the like takes a long time — hours or more — during which time the table is write locked, meaning no insertions/deletions/updates and no queries on the new column until the alter table is done.

Mark Callaghan points out that changing the row format in InnoDB is a “significant project”, so it looked like slow alter tables were going to be a challenge for MySQL for the foreseeable future. Slow alter tables is a reason for the inability of MySQL to scale to large tables.

TokuDB v5.0 changes all that with the introduction of HCAD. 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.

Here we present an example of HCAD in action. See this page for details of the experiment. Drum roll…

TokuDB:

mysql> alter table ontime add column totalTime int default 0;
Query OK, 0 rows affected (3.33 sec)

InnoDB:

mysql> alter table ontime add column totalTime int default 0;
Query OK, 122225386 rows affected (17 hours 44 min 40.85 sec)

That’s 19,000x faster! Goodbye long downtimes.

As a note, the “0 rows affected” for TokuDB means that the column addition work happens in the background. All queries on the table, however, will see the new column as soon as the alter table returns, in this case after 3.33 sec.

We’re psyched about being able to provide this feature to our users. In the next post, we’ll take a look at how TokuDB is able to achieve HCAD. Finally, we’ll present a how-to on getting the most out of HCAD.

Click here for Part II.