TokuDB internals
summary
TokuDB implements fractal trees: B+-trees with per-node message buffers so random inserts are batched and pushed down, yielding much slower degradation than B+-trees. Benchmarks with Facebook’s Linkbench show TokuDB beating InnoDB on slow disks but losing on SSDs; big wins come from sequential large writes and better compression (much less disk space). Defaults matter: a TokuDB node is 4 MB node size vs InnoDB ~16 KB, and checkpoint/cloning work causes CPU and I/O spikes that must be tuned.
AI-written summary · about
chapters (24)
- 0:00Introduction
- 1:48Traditional DBMS issues
- 3:52B-tree search and caching
- 5:42Sequential vs random inserts
- 8:17Random insert problems
- 9:44Fractal trees: idea and structure
- 13:20Fractal tree performance
- 14:03BBenchmark
- 16:40LinkBench
- 18:25TokuDB advantages
- 19:10Fractal tree parameters
- 21:00Node size configuration
- 22:47TokuDB data compression
- 24:46Caching and hot objects
- 25:54Checkpoints and impact
- 28:25Checkpointing process
- 31:14When to use TokuDB
- 32:24When not to use TokuDB
- 32:45TokuDB unique features
- 34:34Q&A 1
- 36:22Q&A 2
- 37:48Q&A 3
- 39:23Q&A 4
- 40:49Q&A 5
related talks
28mIntroduction to TokuDB storage engine for large data sets
45mThe Database: A Sophisticated and Special Data Structure
01h 16mOn-Disk Data Structures: B-Trees, LSM-Trees and Fractal Trees
34mWhat We Talk About When We Talk About Disk IO
24mSplinterDB: Closing the Bandwidth Gap for NVMe Key-Value Stores
18mTiFlash: Make TiKV 10x Faster and HTAP-able
01h 16mHow do to do research with Systems Researchers
47m10 Reasons Why the TiDB Database Should Power Your Next Development Project