Never Settle for a “B”

OldSQL DBs based on B-trees have some well-known problems and workarounds. TokuDB is a NewSQL storage engines based on Fractal Tree indexing, so the natural question is how InnoDB practice translates into TokuDB. This post gives a quick overview. Enjoy!


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!


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.

Share this post

Leave a Reply