面向对象数据库的正确评价与选择


(来源:http://www.ccidnet.com)

一、概述
就象关系数据库一样,市场上有许多面向对象的数据库(Object-Oriented Database,OODB)可供选择。然而,OODB在价格、功能、特色和体系上没有什么统一的标准。本文将帮助你理解各种OODB系统之间的一些差别,在为应用选择合适的OODB时,帮助你缩小挑选的范围。

根据标准的不同,我用于评估这些产品的参考资料也是五花八门。在大多数情况下,本文的评价以个人经验和看法为基础;另外一些细节直接从评测软件或供应商提供的数据资料获得。在作出选择之前,务必针对你的应用进行全面的测试。毕竟,你我看法可能有所不同。

我们将要分析的四种OODB产品是ObjectStoreVersant Developer SuitePoet FastObjectsObjectivity。每一种产品将从以下几个方面进行评估:
  • 价格和许可
  • 顺从性
  • 兼容性
  • 特色
  • 性能
  • 可伸缩性和可用性

二、价格和许可
工程成本包括两个方面:初始成本和维护费用。初始成本往往在评估中起支配作用,但象年度支持、联机讨论、新手培训等问题都应该成为产品成本的考虑因素。即使和它的竞争者大型RDBMS相比,OODB的价格通常显得很昂贵。

标准考虑…
评估软件可免费下载的、全功能的试用软件。
开发版许可价格低价格,以用户数量为基础的许可。
产品许可价格低价格,按照CPU数量为单位的许可,低廉的年度维护费用。
联机支持负责的技术支持人员,大量有用的技术说明、示范和论坛。
活跃的用户社团大量的热心用户,新闻组里丰富有益的活动,非官方网站的支持。

三、顺从性
和关系数据库相比,OODB一般对顺从标准的要求不是那么严格。大多数OODB都用自己独特的方法实现各种特色功能。由于还没有明确的标准评价OODB,所以对象数据库管理组织(Object Database Management Group,ODMG)的标准是当前最好的准绳。但各个OODB各自为政却带来了一些麻烦,要找出一个完全顺从ODMG 2.0或3.0规范的OODB产品很困难(与已经有一年历史的3.0规范相比,2.0规范是一个相当宽松和不完善的规范)。也许在不远的将来,我们将用Java Data Object(JDO)规范评价Java OODB。
标准考虑…
对“对象定义语言”(ODL)的顺从完全遵从ODMG 3.0规范有关对象定义的规范。
对“对象查询语言”(OQL)的顺从完全遵从ODMG 3.0规范有关查询的规范。
对Java的顺从性完全遵从ODMG 3.0规范意味着正确实现Java API/绑定。
对C++的顺从性完全遵从ODMG 3.0规范意味着正确实现C++ API。
对Smalltalk的顺从性完全遵从ODMG 3.0规范(如果你的系统不太可能用到Smalltalk,那么这只是一个可选的标准)。

四、兼容性
无论是语言还是平台,工程对可伸缩性的要求会日益增加。OODB不应该在任何一方面影响这种可伸缩性。然而,平台支持的代价很昂贵,它要求进行广泛的测试和大量的文档说明。因此,一些供应商的产品只支持数量很少的平台。要找出一个和各种主流OO语言(如C++、Java、Smalltalk)紧密结合的方案是相当困难的。

标准考虑…
支持的平台广泛的平台支持——我总是考虑三个关键的平台:Linux,Win2000,和Solaris。你优先考虑的平台可能有所不同。
Java集成广泛的JDK支持,紧紧跟踪最新的JDK规范。
C++集成广泛的编译器支持
持久类的特殊化避免紧密结合——寻找那些不要求修改代码中持久类的数据库。这是一种与偏好有关的选择,所以你应该认真研究处理后扩展和扩展/实现方式相比的优缺点。
可嵌入的版本只占用少量的磁盘空间、RAM;具有取消一些非核心功能的能力。

五、特色
每一种数据库方案都有自己的一些独特的功能。下面我特别指出一些核心功能,因为这些功能对于开发工程来说具有很高的价值:

标准考虑…
数据库浏览管理数据库、修改内容、更新模式和生成内容报表的能力。
客户端缓冲改善“热点”数据库响应速度的能力;在确保对象同步的前提下,使得对数据库的提取操作减到最少。
数据库安全用户、用户组访问控制,最好在对象(如果不是容器的话)的层次上进行。
XML支持无缝地从数据库提取、向数据库插入XML的工具。
IDE集成TogetherSoft之类提高开发效率的环境集成能够提高开发效率。

六、性能
在性能的某些方面,OODB占有优势;但在其他方面,OODB又有所不足。在这里提供每一种产品详细的性能测试数据显得过于冗长,但理解可能影响性能的体系和功能方面的局限是很重要的。

标准考虑…
加锁策略应用-对象级的加锁机制能够带来很大的方便,但页面级的加锁机制在某些条件下能够带来性能上的飞跃。
负载平衡透明地分布数据库、调用远程服务器上的方法、在并发线程/访问之间共享对象的能力。
最大的数据库大小越大越好。
事务支持检查点:由多个线程共享一个事务,一个线程占用多个事务,嵌套事务;当某个给定产品的实现影响了你的应用时,确保你自己理解了结合客户端缓冲时客户端/服务器端同步的工作机制。
有关查询/性能的信息提取这些信息的能力,它能够帮助你找出性能瓶颈;OODB提供的优化和调整选项通常要比RDB少,但一些帮你提取性能信息和解释查询执行计划的工具仍很有用。

七、可伸缩性和可用性
虽然并非每一个工程都要求有企业级的恢复、可用性、可伸缩性功能,了解你所选择的OODB方案能够随着工程一起发展而提供这方面的能力是值得的。

标准考虑…
失败转移主服务器出现问题时,透明地切换到冗余数据库。
负载平衡把负载分布到冗余服务器、把对象分割到多个服务器、同步多个客户端对象缓冲之间数据视图的能力。
复制和增量备份无缝地复制数据,支持负载平衡和恢复的能力。
专用的查询引擎(Ad hoc query engine)丰富的查询语言,允许对数据的快速访问;理想情况下,它应该能够跨越没有直接关联的对象连接数据。

八、产品评论
下面,我按照前文提出的标准评估以下产品:


请参考Cetus OODB area,那里有一个相当新的OODB供应商清单。
标准ObjectStoreVersant Developer SuitePoetObjectivity
背景信息
供应商Object DesignVersantPoetObjectivity
产品主页ObjectStoreVDSFastObjectsObjectivity
技术参考[29]SpecPDF data sheetOverviewmanualsJavaC++PDF overviewspecific data sheets
版本6.06.0t7 8.0[16]6.0
价格和许可
试用版本30天试用[1]60天试用功能限制90天试用
许可费用[2][2][2][2]
联机支持尚可[3][9]尚可[9]好[19]很好
用户社团[23]中等[4]中等较小中等
顺从性
ODL顺从性NNN不完整的2.0/3.0支持
OQL顺从性NN[10]ODMG 3.0[17]N
Java接口遵从ODMG 3.0ODMG 3.0ODMG 3.0ODMG 3.0
C++接口支持ODMG 3.0N/A不完整的2.0/3.0支持
Smalltalk接口N/AN/AN/AODMG 3.0
兼容性
支持的Unix操作系统Linux,Solaris,HP-UX,IRIX,AIX,Tru64 [ref]Linux,Solaris,HP-UX,IRIX,SGI,Tru64 [ref]Linux,Solaris,HP-UX[ref]Linux,Solaris,HP-UX,IRIX,AIX,Tru64 [ref]
支持的Windows操作系统98,NT4,2000 [ref]NT4,2000 [ref]98,NT4,2000 [ref]98,NT4,2000 [ref]
JDK要求1.0,1.1–1.3[22]1.2,1.31.1-1.31.22,1.3
持久类的特殊化N[5]N[5]N[5]Y[24]
可嵌入的版本YNY[18]N
功能
数据库浏览器YYYY
客户端缓冲YYYY
数据库安全数据库或者段的用户/组控制数据库的用户控制[14]特定类和数据库的用户/组控制数据库的用户控制
XML支持YY[15]部分[20]部分[20]
性能
加锁策略数据库,页,或者对象对象级对象级容器级[25]
最大的数据库大小[7]数百个GB?数十个GB到数百个GB?[12]根据报告,它达到了TB级
事务支持死锁检测,MVCC [8]分布式事务管理(类似于MVCC的概念)检查点,共享或并行的事务,嵌套事务检查点,死锁检测,共享或并行的事务
提供有关查询/性能的信息YN[13]NN[26]
可伸缩性
失败转移(failover)YYY可选[27]
负载平衡部分[6]部分[11]部分[21]可选[27]
复制和增量备份YYY可选[27]
专门的查询引擎(Ad hoc query engine)没有OQL。使用集合和查询对象Y[10]Y (OQL)Y[28]

■ 结束语
我希望自己还没有给人以OODB狂热鼓吹者的印象——对于我所使用的大多数应用,我认为应用OODB带有一定的风险。然而,一旦你理解并熟悉了OODB,它们可以成为很方便的工具。我个人比较看好Poet和ObjectStore,但我觉得它们都很有用。

■ 注解
[1]只提供单实例个人版(Single-instance Personal Edition,PSE)供下载。
[2]报价可以从销售代表处获得。
[3]部分支持服务只提供给有效维护合同的拥有者访问。
[4]社团规模只相对其他OODB产品而言。OODB的用户社团远远小于关系数据库的用户社团。
[5]持久类必须进行事后处理。
[6]多个数据库之间的负载平衡看来不太可能。相反,处理通过客户端缓冲得以分布,它把更多的逻辑和计算任务透明地移到了客户端,从而减小了服务器的负载。
[7]这些数据未经证实,主要从供应商的声明获得。在讨论数据库大小的时候,对象的复杂性、大小、“合理的应答时间”等问题都是必须考虑的因素。
[8]多版本并发控制(Multiversion Concurrency Control,MVCC)是一种非标准的技术,在并发读取/写入操作期间用来维持缓冲客户端和服务器端数据视图的一致性。
[9]可以从大量在线演示、FAQ、论坛获益,所有这一切都对现有和潜在用户开放。
[10]实现了一种私有的VQL语言,它和OQL有一些共同点。
[11]通过复制实现部分负载平衡能力;根据推测,负载平衡可能通过把请求重定向到多个数据库实现,但这一点未经证实。多个数据库之间的透明复制确保了每一个OODB上都有一份最新的数据。
[12]需要64位的版本,以便超越大量在内村、记录计数等方面的2^32限制;Versant的64位版本已经构造完毕,但还没有在所有它所支持的平台上经过验证。
[13]提供一些用于查询调整和计时的工具。
[14]如果不是我在什么地方错过,它似乎没有提到粒度更小的安全机制或者是在API中提供这方面的能力。我找到特别提及的只是通过OS强制的数据库文件权限实现的数据库级访问控制。
[15]需要单独提供的工具。
[16]Poet分三种形式:t2(实时嵌入式Java),e7(嵌入式Java/C++),以及t7(企业Java/C++)。版本号没有明确显示,t7的v8.0得自文件的版本号,当前是8.0.0.19。
[17]不能保证它完整地支持ODMG 3.0 OQL,但覆盖范围看来相当广泛。
[18]包含一个C++或Java的嵌入式版本,以及一个Java的实时嵌入式版本。
[19]联机支持网站community.fastobjects.com的内容非常全面,但速度常常很慢。我拥有高速连接,但它有规律地返回页面超时错误。
[20]我只能通过命令行接口使用批量导入/导出功能。
[21]没有分布式功能的任何明显标记,而且我也没有用过一个分布式的配置。如果Poet的配置中数据库复制带有“reader scalability”选项,负载平衡可以在某种程度上得以实现,使得查询可以对只读的从属数据库进行。
[22]至少JDK 1.2看来最好,你将得到更好的集合支持和避免一些已经有报道的“quirk”问题(未能肯定是否为JDK 1.1解决了这些问题)。
[23]很难进行评估。我从收入和Internet/新闻组的讨论入手分析。请把它看成是一种猜测。
[24]持久类的标识或者是它从ooObj派生,或者它实现IooObj接口。
[25]虽然对整个容器加锁听起来吓人,但它的基本思想是,它会显著减少加锁服务器的负载。
[26]通过API调用和统计功能提供一些运行时查询调试能力。
[27]一些资料,例如这一份说明,显示出这些选项会增加成本。
[28]没有提供类似OQL的等价语言。SQL++是一种遵从SQL的功能,允许针对OODB进行SQL查询;容器支持一个scan()方法,以及支持“谓词查询语言”表达式(Predicate Query Language)。
[29]这四种产品都提供评估版供下载。下载软件包附带的文档和示例一般都比较完善。