我认识不少从事处理和存储大量数据的科学家。所有人都对关系DBMS不满意。他们列举了三个常见的原因:
表不是应用程序的良好数据模型。地球科学家、海洋学家、高能物理学家和天文学家最常见的要求是支持大型阵列。已经多次证明,在表的顶部模拟数组是一种不自然的行为,并且会带来非常糟糕的性能。生物学家和化学家似乎同样不喜欢表格,尽管他们想要的不是数组。
关系型dbms中的操作符不能满足科学的需要。例如,拥有遥感数据的科学家经常希望对该数据进行网格化,以匹配其他一些数据集的坐标系。使用SQL操作重写数组数据几乎是不可能的。因此,地球科学家希望科学特定的操作,如网格,作为原始操作。
当前商业dbms不支持所需的特性。例如,所有的科学数据都有不确定性;然而,rdbms假设数据是精确的(在业务数据处理中通常如此)。科学家必须处理应用逻辑中的不确定性,结果并不乐观。必须添加一个具有不精确性的额外字段,然后必须重新编码所有操作(如过滤),以考虑这种不确定性。此外,科学家从来不想在原地更新数据,从而失去原有的价值。如果数据值是坏的,他们希望将新值添加到DBMS中,而保留旧值。通过这种方式,他们可以看到数据的历史状态和修正过程。这种“不覆盖”策略在执行复式记账法的会计系统中也很普遍。然而,目前的rdbms更新数据的位置,科学家必须在痛苦的应用程序逻辑中处理历史。在当前的rdbms中,同样令人不安的是缺乏对数据沿袭(数据是如何派生的)和命名版本的支持(因此科学家可以在不影响其他用户的情况下对数据集进行本地更改)。
这些问题的最终结果是科学家们要么不使用商业dbms,要么不情愿地使用它们。
不幸的是,科学应用目前还不是一个十亿美元的市场。因此,科学要求在很大程度上被主要的商业供应商所忽视。此外,没有证据表明这种状况会很快改变。这让科学使用者受到了冷落,他们常常必须求助于在“裸露的金属”上“自己卷”。
就我个人而言,我认为有一系列威胁地球的问题,如气候变化和臭氧消耗,只有科学家才能解决。因此,对于这类用户来说,DBMS支持的糟糕状态(以及一般的系统软件支持)非常令人不安。
科学用户当然想要一个商业质量的DBMS,也就是说,一个可靠的、可扩展的、有良好文档和支持的DBMS。他们还想要一些开源的东西。这样的软件系统是不可能在实验室或大学里建立起来的。这样的机构擅长原型,但不擅长生产软件。因此,显而易见的解决方案是一个非营利基金会,沿着Apache或Mozilla的路线,其章程将构建这样一个DBMS。由于市场规模的问题,它无法得到风险资本的资助。这种支持必须来自政府和基金会。
现在是美国支持这一倡议的时候了。
Mike,你认为为什么没有人围绕这个想法组织一个大型的开源计划呢?什么是停止创建一个sci-mysql?
虽然我同意RDBMS不是科学应用的最佳技术,开源计划可能会带来一些好的创新,但我会谨慎地将数据模型与查询和管理语言分开。
有一些专有工具(如kx.com)已经成功地做到了这一点。这些工具的速度和容量是惊人的(就像必须支付的许可费一样)。
我不明白table for array的问题。我所能想到的是,表与模式是不必要的“复杂”数组。
我同意传统的RA运营商局限性太大。但是,像RA算子那样统一科学运算的一般高级原语是很困难的。
一种方法是在数据库之上构建机器学习算法。由于这些操作通常是计算密集型的,并且用于处理不确定性,因此性能指标不再仅仅是I/O。然而,DBMS是用于数据存储和管理的,分析功能应该留给上层。
这种说法可能会让一些人感到惊讶,但是关系数据库确实需要使用关系方法来存储数据。在最近几个月努力将GIS数据压缩到关系数据库中之后,我已经筋疲力尽了,所以我不认为我有任何与这个问题相关的宗教天分,但在我们考虑在RDBMS中实现任何东西之前,我们需要考虑学习/尝试理解这样的关系范式:数据实体之间的关系(在RDBMS圈子中称为分析话语宇宙),规范化过程,传递依赖关系(!),3-范式和5-范式。是的,RDBMS的使用带来了学习开销,而且曲线是陡峭的。我不确定是否有可能设计一个软件工具,让我们从最初的研究中解脱出来,在这种情况下,这是一个复杂的关系世界,但我们可以尝试:-)
我在商业和科学领域都工作过,并且目前管理着大约22tb的气候科学数据,我不会再尝试使用RDBMS来存储大量数据,就像试图跳过月球一样。然而,在商业领域,RDBMS只是一个工具;也就是说,需要大量的软件开发来生产定制的应用程序,这些应用程序使用RDBMS的核心功能来访问所需的数据,但从本质上讲,仍然是应用程序提供了繁重的工作。
对于科学数据,RDBMS可以用来保存元数据,加上指向实际数据的指针;这里的“指针”指的是文件路径或url等。但是您仍然需要定制应用程序以适应项目需求,但这就是生活!
显示所有5评论