最近因为工作的缘故,接触了TokuMX,尝试下来感觉不错,值得介绍给大家。

事情的起因是要解决MongoDB的问题。系统中需要保存程序输出的运行信息,这类信息比程序语言的log更高级,但又不如业务操作日志高级,是某些时候发现问题的关键证据,所以必须保存。因为格式不太规范,又需要方便检索,所以文档型NoSQL的MongoDB是比较好的选择。

但是,选择MongoDB就必然会面对磁盘空间的问题。我们的数据大概是这样的:每天的数据量不到200万条,单条数据的平均大小不超过4k,但MongoDB存一个月的数据就消耗了接近40G,最近三个月的数据则需要接近100G。限于具体的硬件环境,只能保存最近三个月的数据,但这无法满足业务需求,所以必须另想办法。

(more…)

本文翻译自 TokuMX Fractal Tree(R) indexes, what are they?

TokuMX的一大创新在于,它打破了一条长久存在的关于数据库的规则:要保证好的写入性能,索引的工作集应当能够放在内存里。标准答案是这样的:如果索引的工作集比内存要大,写入就需要执行I/O,I/O就会成为限制因素,性能就会下降。所以,要么让索引小到能全部放进内存,要么提供一种索引写入模式,避免工作集过大,比如MongoDB所采用的,内存中只为最近插入的数据保存索引。

但对TokuMX来说,这是绝对不成立的。依靠TokuMX所提供的创新性的分形树索引,索引的工作集可以比内存更大,同时写入性能不受影响。分形树索引为什么在重度写入(无论是MongoDB还是MySQL)的评测中能表现优异,原因就在这里。

(more…)