我们知道，当一个实例的数据空间超过TB级别时，空间存储和运维成本都是非常高的，尤其是做实例迁移和备份，整个过程耗时会非常长。

我们对线上一些大的InnoDB实例(TB级)平滑迁移到TokuDB后，数据空间从 2TB+ 直接降到 400GB ，空间成本仅为原来的五分之一，而且读写性能没有任何降低(写性能反而提升不少)。通过线上几个大实例(TB级)的使用，TokuDB的压缩比均在５倍以上，同样的空间大小，使用TokuDB后可以存５倍的容量！

TokuDB的另外一个特点就是低IO消耗，相同数据量下，IO花销基本是InnoDB的1/8，IO成本也降低了不少，同样的IOPS限制下，TokuDB写性能会更高。因为IOPS消耗较少，RDS已经在线上部署TokuDB+廉价SATA盘集群，配合“方寸山”(分库分表proxy)来提供低成本高性能的PB级日志存储能力。

这个集群使用廉价的SATA盘(IOPS能力~120)，单台物理机基本可提供30,000 TPS的写能力(tokudb_fsync_log_period=0和sync_binlog=1，针对类如日志型应用，对数据安全性要求不是很高的话，调整tokudb_fsync_log_period=1000，sync_binlog=1000，性能会更高)，利用TokuDB的大页(page size 4MB)压缩优势，尤其是对日志内容，压缩比基本在1/8以上，单机可提供160TB+的的存储能力，整个集群可轻松支持PB级。

使用TokuDB，让你随便任性！

本篇来探讨下TokuDB内部的一个重要机制: checkpoint。

TokuDB引擎里，数据存在于3个地方：

1. Buffer Pool (memory)
2. Data File (disk)

为了性能，对“页”级的操作会先被Cache到Buffer Pool里，当触发某些条件后，才会把这些“脏页”刷到磁盘进行持久化，这样就带来一个问题： 对于TokuDB来说，整个Fractal-Tree元素有两部分的“页”组成：(Buffer Pool里的“页” ) + （Data File里已持久化的”页”），如果TokuDB crash后，Buffer Pool里的“页”丢失，只剩Data File的“页”，此时的Fractal-Tree处于“混沌“状态(不一致状态)。

为了避免出现这种“混沌“状态，TokuDB需要定期(默认60s)做Checkpoint操作，把Buffer Pool里的“脏页”刷到磁盘的Data File里。

当TokuDB Crash后，只需从上次的一致性状态点开始“回放” Redo Log里的日志即可，恢复的数据量大概就是60s内的数据，快吧？嗯。

TokuDB checkpoint分2个阶段：begin_checkpoint 和 end_checkpoint

大体逻辑如下：

end_checkpoint:

以上就是整个checkpoint大概的逻辑，整个过程中，只有C6的任务最“繁重”，在这里面有几个“大活”：

1. 刷盘前做大量压缩 –CPU消耗
2. 多线程并发的把page刷到磁盘 –IO操作

以上3点会导致checkpoint的时候出现一点点的性能抖动，下面看组数据：

以上为sysbench测试数据(读写混合)，仅供参考，可以看到在[255s]和[315s]checkpoint的时候，性能有个抖动。

喵，另外一个问题来了：如果TokuDB在end_checkpoint C6的时候crash了呢，只有部分“脏页”被写到磁盘？此时的数据库(Fractal-Tree)状态岂不是不一致了？

TokuDB在这里使用了copy-on-write模型，本次checkpoint的“脏页”在刷到磁盘的时候，不会覆写上次checkpoint的文件区间，保证在整个checkpoint过程中出现crash，不会影响整个数据库的状态。