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!
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.
