论坛首页 Java企业应用论坛

关于OODB的设计思考

浏览 7365 次
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
作者 正文
   发表时间:2009-05-31  
OO
闲来无事,想做个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分钟不到)。

这个是我目前能想到的,大家有什么看法?
   发表时间:2009-05-31  
OODB的思路,在学术上可以尝试以下,但在实践中很难行的通.
作为数据库来说,其根本功能是有序存储信息,以及快速检索信息,这个是本质要求.至于这些信息是以何种格式存储,是具体的技术实现问题.
如果使用上文中提到的OODB方法存储,有一个问题是饶不过去的,就是数据的查看问题.
请问采用何种方式才能从这个oodb里面查询到所存储的数据是否正确呢?
如果直接以object的方式存储,用sql语句读取出来又该如何展示呢?很困难.
oracle,sql server都提供自定义数据类型的功能,但在实践中很难使用.
一个很重要的问题就是一旦进了数据库,就变成了一个黑匣子,根本没有办法来检查里面存储的数据到底对还是不对.
0 请登录后投票
   发表时间:2009-05-31  
数据的检索(非主键)从技术上来说确实有难度,但不是不可行。
在使用上
sql:select * from student where name = "WangMeiMei"
oodb:Student s = new Student();
     s.setName("WangMeiMei");
     Student result = OODB.query(s);
难度其实就在对象的存储上,只要存到文件里,就能查的到,只是一个高难度算法的问题。数据库本质上不也是通过文件存储么?
0 请登录后投票
   发表时间:2009-05-31  
现在也有所谓的oodb,但是不知道现实中有用的么?
0 请登录后投票
   发表时间:2009-05-31  
感觉db4o总体来说不错,但还是很多地方不理想。
OODB用起来确实很方便,不过现在公司项目估计很不太敢用吧,自己做些小软件小网站用的很爽。
0 请登录后投票
   发表时间:2009-05-31  
laiseeme 写道
现在也有所谓的oodb,但是不知道现实中有用的么?

DB4O貌似很强大。。不过上周用了一阵子发现embedded下吃内存惊人,后来换用h2,,至今工作良好。
0 请登录后投票
   发表时间:2009-05-31  
DB4O占用内存不可配置,也是一个问题。
不过h2就不属于oodb范畴咯
0 请登录后投票
   发表时间:2009-06-01  
这个方向是可行的,我也正在做类似的事情。有几个需要注意到地方:
1、ACID的实现,特别是Atomicity怎么实行。
2、在Load的时候如何避免N+1
0 请登录后投票
   发表时间:2009-06-01  
Salin 写道
数据的检索(非主键)从技术上来说确实有难度,但不是不可行。
在使用上
sql:select * from student where name = "WangMeiMei"
oodb:Student s = new Student();
     s.setName("WangMeiMei");
     Student result = OODB.query(s);
难度其实就在对象的存储上,只要存到文件里,就能查的到,只是一个高难度算法的问题。数据库本质上不也是通过文件存储么?

如果要:
SELECT * FROM student WHERE id>100 AND id<500;
OODB 怎么写?

如果要:
SELECT * FROM student WHERE name LIKE 'Zhang%';
OODB 怎么写?
0 请登录后投票
   发表时间:2009-06-01  
oodb什么啊 感觉象hibernate一样
0 请登录后投票
论坛首页 Java企业应用版

跳转论坛:
Global site tag (gtag.js) - Google Analytics