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?
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?
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?
TokuDB tables don’t fragment, so OPTIMIZE TABLE doesn’t defragment them.
Q: How often should I dump and reload a table?
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?