One more struggle, and I am free
最近因为工作的缘故，接触了TokuMX，尝试下来感觉不错，值得介绍给大家。
事情的起因是要解决MongoDB的问题。系统中需要保存程序输出的运行信息，这类信息比程序语言的log更高级，但又不如业务操作日志高级，是某些时候发现问题的关键证据，所以必须保存。因为格式不太规范，又需要方便检索，所以文档型NoSQL的MongoDB是比较好的选择。
但是，选择MongoDB就必然会面对磁盘空间的问题。我们的数据大概是这样的：每天的数据量不到200万条，单条数据的平均大小不超过4k，但MongoDB存一个月的数据就消耗了接近40G，最近三个月的数据则需要接近100G。限于具体的硬件环境，只能保存最近三个月的数据，但这无法满足业务需求，所以必须另想办法。
本文翻译自 TokuMX Fractal Tree(R) indexes, what are they?
TokuMX的一大创新在于，它打破了一条长久存在的关于数据库的规则：要保证好的写入性能，索引的工作集应当能够放在内存里。标准答案是这样的：如果索引的工作集比内存要大，写入就需要执行I/O，I/O就会成为限制因素，性能就会下降。所以，要么让索引小到能全部放进内存，要么提供一种索引写入模式，避免工作集过大，比如MongoDB所采用的，内存中只为最近插入的数据保存索引。
但对TokuMX来说，这是绝对不成立的。依靠TokuMX所提供的创新性的分形树索引，索引的工作集可以比内存更大，同时写入性能不受影响。分形树索引为什么在重度写入（无论是MongoDB还是MySQL）的评测中能表现优异，原因就在这里。