高性能存储引擎TokuDB剖析 关于我 • 一工@淘宝核心系统 • 开源爱好者、存储引擎探索和实践者 • 博客：logN.me • 微博：@BohuTANG_ • Gtalk: overred.shuttler@gmail.com 大纲 • TokuDB简介 • TokuDB的索引结构 • TokuDB的特点 • 不适用场景 TokuDB简介 • 公司研发(2007--2013年open source) • 目前5个研发，1个性能测试，1个科学家(MIT) • 支持MySQL/MariaDB，GPL开源协议 TokuDB的索引结构 随机读/写时间 = 寻道时间 + 读/写时间 TokuDB的索引结构 B-tree索引的缺陷 假设：B = 16KB 50GB / 16KB ~ 300w个node，太多了！ 缺点：不适合随机读写，大部分是寻道时间！ TokuDB的索引结构 Fractal-Tree® 索引 B = 4MB (块大，整块压缩，~1MB) 50GB / 4MB ~ 1w个node，node少！ • 每个node有4-16个子节点 • 每个node都有一个message buffer • 内节点message buffer是FIFO结构，减少cmp • 叶节点message buffer是OMT结构，弱平衡的二叉树 INSERT TokuDB的索引结构 • Fractal-Tree® ，由TokuTek注册专利 • 它其实是Buffer-Tree的一个“变种” • Buffer-Tree是由Lars最早提出 • TokuDB对细节做了不少优化:CPU+Memory TokuDB的特点 一切的好处均要归功于message buffer TokuDB的特点 • Insert/Update/Delete/Column等，均是message • lazy式操作，自上而下逐步Flush到leaf节点 • 天然多版本，无需做undo log • Fast insert/ Fast update，延迟小 TokuDB的特点 TokuDB的特点 • node块大，适合压缩 • IOPS少，适用于SSD TokuDB的特点 Log • log manager来管理log文件，InnoDB的rotate log效果 • 为了并发性能，log在实现上，分: in buffer和out buffer • 支持group commit • 只有redo log ，不压缩，顺序写文件 TokuDB的特点 Transaction • ACID • Fractal-tree在事务实现上有优势，无undo log • Leaf节点做MVCC，实现最终多版本 • 内存维护活动事务(live transaction)链 • tokudb.rollback记事务逻辑日志 TokuDB的特点 CheckPoint • 类型是sharp checkpoint • 后台线程定期执行 • Begin checkpoint: 1) 给所有node打pending标记 2) 获取当前checkpoint的LSN • End checkpoint: 3) 把dirty node写盘 4) 把ft meta信息写盘 • 中途Crash问题 TokuDB的特点 Hot Schema • Add/Delete Column， message类型为BROADCAST • Lazy式 • 每个node遇到BROADCAST，都要把它带给子节点 TokuDB的特点 Indexing • 索引分两种： a) clustering index b) covering index • 每个索引均是一个单独的fractal-tree结构文件 • 表foo: TokuDB的特点 Indexing covering index: 此时索引文件里一条记录的结构： 索引key有covering key组成，value空 TokuDB的特点 Indexing clustering index: 此时索引文件里一条记录的结构： TokuDB的特点 Indexing Covering index VS Clustering index • 都是物理的 • Clustering index包含全数据 • Clustering index可是表的另一种排序方式 不适用场景 • select count操作，需做表扫描 • affected rows操作，需做表扫描 Thanks!