July 2014


算起来,我从互联网开发投身企业开发已经有四年多时间了。刚刚进入企业开发领域时心里很是忐忑,虽然也读过《企业应用架构模式》之类的书,到底没有做过正经的“企业开发”,好在业务不算太复杂,所以更多是借着之前互联网开发的老底子解决问题。而且,这么做确实能解决问题,只是心里还不太放心,总觉得这不是名正言顺的“企业开发”,以后会有问题。

谈到传统的企业开发,大家通常想到的是“为明确目标(通常由甲方设定)而开发的紧耦合固定系统”,主要元素包括重型框架、长发布周期、严格的限制、海量的文档、对商用软件的倚重等等。谈到互联网开发,大家通常想到的是“为不明确或多变目标而开发的松散多变系统”,主要元素包括轻量类库、迅速迭代、不断试错、简单交流、开源/免费软件的广泛使用。传统上,企业开发和互联网开发俨然两派,你觉得我是杂乱无章的恣意胡闹,我觉得你是傻大笨粗的因循守旧,好在双方“井水不犯河水”,也相安无事。

企业开发和互联网开发的这种区别,让我在以互联网开发的方式应对企业开发任务时,始终有挥之不去的担忧。然而工作得越久,事实却不断证明这种担忧是多余的,或者至少不必高估“企业开发”的正统性。而且,有越来越多的迹象让我相信,企业开发的互联网转向,即在企业开发中越来越多地采用互联网开发的方法,是未来的趋势。按照我的总结,原因大致有以下几点。

(more…)

最近因为工作的缘故,接触了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…)