锁定老帖子 主题:关于OODB的设计思考
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
---|---|
作者 | 正文 |
发表时间:2009-05-31
之所以想到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分钟不到)。 这个是我目前能想到的,大家有什么看法? 声明:ITeye文章版权属于作者,受法律保护。没有作者书面许可不得转载。
推荐链接
|
|
返回顶楼 | |
发表时间:2009-05-31
OODB的思路,在学术上可以尝试以下,但在实践中很难行的通.
作为数据库来说,其根本功能是有序存储信息,以及快速检索信息,这个是本质要求.至于这些信息是以何种格式存储,是具体的技术实现问题. 如果使用上文中提到的OODB方法存储,有一个问题是饶不过去的,就是数据的查看问题. 请问采用何种方式才能从这个oodb里面查询到所存储的数据是否正确呢? 如果直接以object的方式存储,用sql语句读取出来又该如何展示呢?很困难. oracle,sql server都提供自定义数据类型的功能,但在实践中很难使用. 一个很重要的问题就是一旦进了数据库,就变成了一个黑匣子,根本没有办法来检查里面存储的数据到底对还是不对. |
|
返回顶楼 | |
发表时间:2009-05-31
数据的检索(非主键)从技术上来说确实有难度,但不是不可行。
在使用上 sql:select * from student where name = "WangMeiMei" oodb:Student s = new Student(); s.setName("WangMeiMei"); Student result = OODB.query(s); 难度其实就在对象的存储上,只要存到文件里,就能查的到,只是一个高难度算法的问题。数据库本质上不也是通过文件存储么? |
|
返回顶楼 | |
发表时间:2009-05-31
现在也有所谓的oodb,但是不知道现实中有用的么?
|
|
返回顶楼 | |
发表时间:2009-05-31
感觉db4o总体来说不错,但还是很多地方不理想。
OODB用起来确实很方便,不过现在公司项目估计很不太敢用吧,自己做些小软件小网站用的很爽。 |
|
返回顶楼 | |
发表时间:2009-05-31
laiseeme 写道 现在也有所谓的oodb,但是不知道现实中有用的么?
DB4O貌似很强大。。不过上周用了一阵子发现embedded下吃内存惊人,后来换用h2,,至今工作良好。 |
|
返回顶楼 | |
发表时间:2009-05-31
DB4O占用内存不可配置,也是一个问题。
不过h2就不属于oodb范畴咯 |
|
返回顶楼 | |
发表时间:2009-06-01
这个方向是可行的,我也正在做类似的事情。有几个需要注意到地方:
1、ACID的实现,特别是Atomicity怎么实行。 2、在Load的时候如何避免N+1 |
|
返回顶楼 | |
发表时间: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 怎么写? |
|
返回顶楼 | |
发表时间:2009-06-01
oodb什么啊 感觉象hibernate一样
|
|
返回顶楼 | |