用对象数据库引擎探索全球气候变暖问题

               大数据：用对象数据库引擎探索全球气候变暖问题

    我们不能把北极塞进关系型数据库里面。这是研究世界各地的冰雪气候的大卫加拉赫在设计一个解答基础性问题的系统时发现的，这个问题就是：“全球变暖是如何影响南极和北极的？”。

    加拉赫的研究开始与格陵兰岛的大约66万平方英里的冰层覆盖区域。事实证明，在如今传统的关系型数据库的黄金时代，有一种被人们忽视的技术，利用这种技术能够更好的完成对格陵兰30年的大数据的探测任务。其中包括一天三次的卫星扫描，产生的数据量几乎是PB级规模的任务。这项技术便是将数据作为对象来处理的面向对象的数据库管理系统- 来自于Versant公司的对象数据库引擎。

    “这些数据对于Oracle或者传统的关系型数据库来说太过庞大了，很容易在数据装载的时候导致系统崩溃。”位于科罗拉多大学博尔德分校的国家冰雪数据中心（NSIDC）IT服务部经理加拉赫说。为处理那些非常适合表结构的连续性数据的报告和分析而设计的关系型数据库是无法展示陵兰岛上冰的历史变迁过程的。

    作为一个经过专业训练的地理学家，加拉赫是这一项目的主要负责人。该项目总投资为60万美元，由国家科学基金会拨款，目的是要建立一个可以处理几十亿比特时序信息（以统一的时间间隔测量的数据序列）的系统，并使这些信息通过互联网可以被世界各地的研究人员获取。加拉赫说，“我们必须转向这样的模式，它能更方便地去分析数据，而不是将数据转成分析所用。”
   
    数据如此庞大，以至于国家冰雪数据中心（及其数据收集合作伙伴，国家航空航天局）只将元数据放在关系数据库中。数据本身存储在目录树下，在研究人员要了解如什么、哪里和何时等关键问题时才会被提取出来——如果研究人员要分析原因的话，那就更费力了。由于文件太大，如果一个研究人员想要知道，例如，冰的反射率，或是反射属性——冰颜色的深浅，反射率的高低或反射变化的快慢，可能要花上好几个星期的时间才能得到想要的数据。（属性是面向对象技术中用来表示持久化数据的专业术语。）

    “然后他们还必须写出些什么来整理他们手中的信息。如果他们很幸运，通过运算，才有可能在经费用完之前可以得到一些结果，”加拉赫表示，“我们认为，必须要找到其它的解决办法。”。

被遗忘的面向对象数据库

    IDC负责信息管理及数据集成软件研究的副总裁，Carl Olofson表示，面向对象数据库技术一直被人们误解——甚至在数据库社区中也常常被人们误解——人们认为这种技术已经过时，只局限在一些特殊的领域应用之中。这可能是因为制定收集数据和制作报表的数据库标准的工作重点放在了关系数据库上。

    为了充分利用对象数据库，必须建立映射其属性结构的对象模型。“要完成这项工作需要有一定的抽象思维，”Olofson说，“IT公司可能会感到他们并没有时间来进行这样的分析。”。

    但是观念是在不断更新的。用对象数据库引擎能够更好地将现在各个企业想通过时间和空间范围追踪的复杂数据和复杂结构的类——例如，社交网络中的人与人之间的关系——进行存入和检索。目前，诸如Versant，GemStone Systems（该公司最近被VMware Inc.收购了）以及Objectivity Inc.这样的供应商正在赢得更多企业和程序员关注的目光。
   
    Olofson表示，“最基本的一点，对象数据库在对大数据领域中建立秩序，同时不丢失任何信息上是十分有用的。”

    新的NoSQL技术与此有一定的相关性，也提供了许多便利，但是这些技术缺少用户基础和行业标准。Olofson举了个例子，例如Hadoop擅长数据的初始输入，但是创建某种结构化输出却是它的短板。

能够时间旅行的“数据棒”

    加拉赫表示，对象数据库应用成功的关键在于知道你想要解决的问题。此外，说服已经习惯关系数据库的数据库管理员停止从表的角度来思考也是一大挑战。Gallaher以及小组成员——两个研究生和一位教授（兼职）——想出了一个被他们称作为数据棒的结构。这里面包含了几十亿个像素，作为一个固定区域的整体时间记录观察。

    他解释说，“把数据棒看作是由片组成的一个堆，每一片都代表了几个小时，这个堆现在有30英尺高。”以反射率为例，您可以要求系统“告诉你哪些‘片’的颜色比其它片的颜色深，颜色深的片发生了什么情况。如果有了有趣的发现，你也可以要求系统告诉你临近的对象的情况。”

    加拉赫表示，“这其中的亮点就是，我们不要把它看作是一个图像，相反，你应该把它看作是一个跨越时间的棒。我们把它看作是一个巨大的3维矩阵。”

    出于效率（以及可恢复性）的原因，格陵兰所有的数据棒以五年为一个时间段，包含了多个数据库。加拉赫说：“你可以查询所有的数据库。如果你愿意的话，你可以把这些数据库当作一个“棒”来用”。通过使用VQL, 即Versant查询语言（他认为这一语言对于外部用户类似SQL），了解一段时间的变化就变得相当直接明了。

    加拉赫说：“对于我来说，向人们解释最佳的方法就是把数据棒看作是对一个无限时间长度的记录，在这个时间维度上你可以随时随地了解你想知道的情况。”

    加拉赫之前在对Hadoop以及类似的技术做了大量的调查之后，他认为Versant数据库能够完成他想要的工作。Versant数据库可以处理他们所需要的任何大小的数据。“我们问的问题包括巨大的区域，繁多的时间点，大量的变量，以及要求在几秒中内得到响应或者被缓存等等，”他又补充道，“现在我们几个小时内所做的事情，以前要花上六个月，这绝不是玩笑。”

这个用什么数据库不是关键，拿到什么数据才是关键

db4o也是号称 实时数据库..我试过根本不是这么一回事

db4o没有把自己定位在实时数据库,虽然它确实具备了一些实时性的特点。
db4o还是会把自己定义在对象数据库，重点关注在终端应用，以及一些嵌入式应用之中。

http://developer.db4o.com/LearnMore/RealTimePerformance.aspx

A lightweight, robust and fast persistence engine like db4o is the perfect companion for real-time systems.


当初我就是被这话骗了，搞了一阵子，发现根本不work。果断放弃，改用其他方案。

能知道您的应用情况吗？当时是什么时候？是试用了什么版本的db4o?不知道你们的需求是如何的？最后你们又是用了什么样的解决方案？希望有机会探讨。

呃...原来的应用非常简单..和gis有些关系。具体来说就是有些矩形之类的对象会存放在db4o。每次设备返回信号就需要
从库中load出矩形进行一些运算。该矩形对象结构十分简单，基本上除了double，string就没有复杂的结构，更加不会有
所谓的嵌套（这个就避免了db4o里面提到的嵌套更新之类的问题）。

有趣的是我发现，当存储的对象超过1万，查询就开始变得很慢, 用简单的string匹配都需要50-60ms。 而且我发现当关闭dbo4 object container的时候.close这个调用本身就耗费将近50ms。对此我感到有些奇怪。我使用了从7.12到8.o
preview版本都无法得到更好的结果， 最后使用了pytables去解决这个问题。我用过java, .net的版本。前者性能略好。

我一直很想知道db4o宣称的高性能的case是需要怎么样的条件下才能有此效果，从我的试用和其他人的反馈来说，迷惑不解的时候更多。当然这个不排除我使用不当，但是从现有的文档我不能获得更好的性能。

根据你提及的现象，可能是由于参数设置不当造成。当然也有可能没有打上最新的patch。如果今后还有机会使用的话，可以随时联系我，我会安排技术人员支持。
当然，我们更希望有机会能够使用我们的旗舰产品，Versant Object Database。

另，2009年在华为刚开始使用db4o开发一个网管产品的时候，也碰到过类似问题，现在已经解决，产品已经在今年发布了。

根据你提及的现象，可能是由于参数设置不当造成。当然也有可能没有打上最新的patch。如果今后还有机会使用的话，可以随时联系我，我会安排技术人员支持。
当然，我们更希望有机会能够使用我们的旗舰产品，Versant Object Database。

另，2009年在华为刚开始使用db4o开发一个网管产品的时候，也碰到过类似问题，现在已经解决，产品已经在今年发布了。


问你个问题。db4o现时有在Mono上有完整的支持吗？


Versant object database是否开源，或者和db4o一样也是双协议的产品？

我们原来在收购db4o之前就是支持Mono的，目前我们有一个同事专门在负责Mono的认证工作。

Versant Object Database是一个商用数据库。