PolePosition 开源数据库评测框架

www.polepos.org 这个评测引擎的结果被放在了 HypersnoicSQL 和 db4o 两个产品的网站上用于宣传, 但是评测结果的曲线图正如它所强调的那样并不能简单的看待, 它强烈建议用PolePosition框架进行数据库系统评估的人仔细阅读框架源代码以后再推断自己的结论.

首先HSQL和DB4O这两个在polepos上拿了比较高分数的官方参赛者都是内存数据库, 而内存数据库显而易见的一个局限就是所能 [u]管理[/u] 的 [u]全部[/u] 对象/记录数受到内存大小限制, 而且运行状态下就要永久占用这么多内存, 不管是3,5年才用一回的数据还是一秒用几百回的.

另外DB4O冠以对象数据库的称号, 也并不是彻底先进性的象征. 目前几乎所有对象数据库系统都不是十分成功, 至少达不到关系数据库的程度. 原因之一就包括成熟OQL的难产, 古怪, 和带来的巨大学习成本, 似乎一直没有办法把它设计得既高效又像SQL那样好用. DB4O所极为推崇的java查询语法, 其实潜在的一个代价就是牺牲了作为关系数据库中流砥柱技术的索引检索法所带来的强劲检索性能提升. 科班出身的哥们儿们大概都开发过自己的MiniSQL作为数据库课程的大作业, 其中最关键的技术就是通过B+树的索引来加快检索速度. 一旦了解了这个原理, 一眼看到DB4O的通过java函数来判断一个对象是否符合查询条件的形式, 就知道它必须是在底层枚举所有每个可能匹配的对象来完成过滤筛选的. 这在语法上虽然自然了很多, 但是就好比一个内力深厚的人, 为了换一个文质彬彬的形象而自废武功, 能力上不是打折扣, 而是跳崖了. 而DB4O也很老实, 对它的这个处理方法也据实讲了. 按说这么丢脸的事情它本不太好直言不讳的, 但是仔细研究了它的成功案例和应用领域, 就不难明白. 其实它最主要的市场是用于嵌入式系统的, 这种系统求的不是强劲的性能, 而是完整的功能, 以及软件的小巧和易用. 但是一旦拿到哪怕是小型网站系统上去, DB4O的这套东西就真的不太拿得出台面了.

poleposition另一个发人深省的结果就是反映了Hibernate框架在追求OO的同时在性能上所造成的巨大牺牲. 不过我觉得按目前的软硬件局势, 较之加强硬件的成本, 软件开发和维护的成本相对还是更高一些, 所以在很多场合下Hibernate还不失为一个最优的解决方案.

但是真如PolePosition所给出的官方解释那样: The results show very clearly that there can not be one single "best product".  答案是不一定. 也许自此以前这就是现实情况, 但是很快会有一个翻案的可能性.

已经有将近两年的时间我一直在思考研究面向能力的程序设计方法, 近来将近半年的时间里, 我在专注的开发一个基于这种新的编程思想之上的对象数据库系统. 不过个人乃至小软件公司的力量毕竟有限, 要开发一个实际有用的软件平台, 还必须脚踏实地. 所以直到Java5.0的出现, 有了泛型,变参,标注的处理等新的语言特性, 这套系统才真正得以以实用的方式开发出来. 不过写这篇文章的时候, 我正在进行功能代码的收尾工作, 然后还需要写一些文档. 这些工作其实很快会完成了, 到时候都会公布在 www.ableverse.org 上, 感兴趣的同行可以关注一下.