关于OODB的设计思考

闲来无事，想做个OODB，慢慢来，从简单做起。

之所以想到OODB这个东西，是因为之前在公司设计过一个很类似的东西，也是对象存储，但是只需要根据主键检索，因此只要设计个持久化的B+树做索引即可，不过需要有对象的历史版本这个概念（即在星期5的时候可以查到所有对象在星期1的状态，并且可以回滚）。由于本人目前余热没地方发挥，所以有想法去设计并实现一个高性能的OODB，然后开源。可能目前的想法还不成熟，毕竟我09年6月才毕业，经验不是很丰富，欢迎大家拍砖。

以下思路纯凭本人乱想。

一.个人认为的OODB比较实在优势：

1.很大程度上减少项目开发成本。
2.不需要通过jdbc转换层次，设计良好的数据存储方案可以使OODB具有很强的性能。

二.很简单的功能列表：

1.能够以极高的性能根据id获取对象。
2.能够根据对象的字段值查找到匹配的对象集合。
3.存储的时候只需要set即可，不用在应用层做配置。
4.暂时不考虑分布式存储。

三.具体实现的思路：

首先需要解决对象的持久化问题。

java中对象持久化最简单的方式就是直接使用序列化，不过在这里序列化的方式显然不可行。因为序列化和反序列化性能很低，更主要的原因是这种方式无法根据对象的字段值进行检索(没有办法为字段设立索引，难道要一个个反序列化出来比较？)。

这里先说说之前在公司设计持久层中对象存储的一个思路。对于直接可存储的简单对象(int,long,String,和这些类型的数组)就直接二进制化，对于一个复杂对象，则将其迭代分解成简单对象直到不可再分为止，然后存储分解出来的简单对象，并记录下这个对象的组成结构。目前我觉得这种思路很适合用在OODB中，但是有两种实现方式，一种是将一个对象的不同字段存储在不同物理位置，例如Class A有10个对象实例，将这10个对象的a字段存储在一起，b字段存储在一起。取出对象的时候，将不同字段取出来然后组合成完整的对象，这种方式的优势在于可以很直接的为所有字段建立索引，并且空间比较好分配。第二中方案是每个对象的所有字段集中存储，可以分析类的成员组成，然后估算一下对象的大小，为其预留空间，如果空间不够的话标示一下即可，这种方案在取出对象的时候会很快，不用多次I/O取出多个字段，但是很容易产生碎片，而且对象的字段类型改变的话会有点麻烦。

对于对象检索使用的持久化索引，以及IO层，之前自己都有过完整的实现，而且有很高的性能保证(dell 630m的破本本插入1000w条索引只要3分钟不到)。

这个是我目前能想到的，大家有什么看法？