列式数据库专栏——适用于“大科学”应用程序的数据库管理系统

 

列式 数据库专栏

一个由多名专家撰稿的关于数据库技术和创新的博客。

适用于“大科学”应用程序的数据库管理系统

最近我应邀参加了在 斯坦福线性加速器中心 举行的为期一天的研讨会。参会人员包括来自以下方面的代表：

·                  数据库研究团体（包括我本人）

·                  存在很大数据库问题的“大科学”团体

·                  商业数据库管理系统厂商

·                  其它数据库技术的 “ 超级用户 ”， 包括易趣、雅虎和谷歌

此次研讨会的目的是为了能够更好地解决在大科学中遇到的数据库管理系统的问题。我总结了一点，今天的传统概念是将科学数据存储在文件系统中并在关系型数据库管理系统中存储这些文件的元数据。在天文和量子物理方面，预计的数据规模需要用 PB 来计算了。


大科学中的三大 DBMS 问题

在数据库管理系统方面，大科学团体存在各种问题，其中包括：

1.                数据和元数据的一致性。 因为元数据和数据是分开存储的 ， 所以程序员要负责保持它们的一致性。这使我想起了二十世纪 70 年代时的数据库管理系统团体 － 它也考虑相同的问题。

2.                对数据库管理系统要求的不同看法。 科学数据之所以存储在文件系统里是因为数据库管理系统无法 “ 做正确的事情 ” 。不过，似乎没有就什么是正确的事情有现成共识。例如，研究量子物理的希望在观察数据和粒子轨迹方面有时间序列的支持，而研究天文的希望在若干个坐标系统中建立三维物体的索引，遥感天文团体则希望内置对为多维数组的支持。

3.                无自动化谱系支持。 谱系 （ 起源 ） 支持非常关键。了解任何已知数据集的起源方式对科学家来说至关重要。换句话说，他们需要跟踪以前处理过的步骤的顺序。因此，关于第一个问题，程序员目前用手工的方式来解决。

显然 ，对 这三大问题的最佳解决方案就是利用下一代数据库管理系统 － 一个可以跟踪数据、元数据和其线形关系的系统。对后者的支持将要求在数据库管理系统内使用用户定义的函数完成所有的数据操作。


以前使用 Postgres 的工作失败

显然大科学希望有人能够解决其存储问题。但始终没有人能够帮助它。这让我想起了 90 年代中期开展的 Sequoia 2000 项目，它是我在加州大学伯克利分校时与 圣塔芭芭拉分校的 Jeff Dozier 共同领导的。这是由 DEC 资助的计算机科学家和地球科学家之间的合作项目，为地球科学家开发新的工具和系统。在数据库领域，目标是利用 Postgres 进行存储。但是项目的这一部分却失败了，因为：

·                  Postgres 不支持当时的主流数据类型 － 大数组。

·                  Postgres 没有处理通道的概念，而通过处理通道可将原始图像转化为成品数据。 因此，它无法对数据的线性关系进行自动跟踪。

·                  Postgres 很难配合地球科学家们希望执行的操作 ， 比如坐标转换。因此，他们没有看到 DBMS 优于用定制的 C 或 C++ 代码来操作文件系统的价值。

Sequoia

原文：Once upon a time ... the origins of today's relational database architectures  曾经 ... 当今关系型数据库体系结构的起源下载

项目的经验教训使我深信 ， 大科学不会对商业数据库管理系统提供的东西感兴趣。这就导致了一个问题：“他们到底需要什么？”


求助电话：让研究团体帮助开发科学数据库

在 2007 年 CIDR 项目中，我们开发了一种我们认为会得到科学界青睐的、称为 ASAP 的原型。该系统提供实时处理通道、线性跟踪和对大数组的良好支持。也就是说，我们解决了十年前在 Sequoia 项目中遇到的所有问题。

由于我们无法找到愿意与我们合作的科学家，因此 ASAP 昙花一现。我们联系过的科学家一般都很忙，并且不看好短期合作带来的价值。在一定意义上他们是正确的 － 合作价值应被定义为一个在将来可能被商业化的优秀科学数据库管理系统。但是完成这一过程并获利可能要花上至少五年的时间。

更好的解决方法是要求大科学在 DBMS 研究机构的初步构思中就贡献想法。 DBMS 研究机构热衷于尝试和定义这些操作，不过还需要来自大科学界的帮助。这是期盼大科学帮助的恳求。

我们从哪里开始我们的合作？开发科学数据库管理系统时的一个重要问题是要定义一组小的基元。关系型数据库管理系统能成功进行业务数据处理是 因为基本上所有用户都愿意使用基于单一数据类型（表）和一个小操作集（过滤、连接、聚集等）构建的 SQL 引擎 。 要想成功，科学数据库管理系统也必须建立一个小的数据类型和操作的集合。一组小的基元操作是非常重要的；否则，运行时系统将会变得异常复杂。鉴于我在研讨会上看到的多样化需求，要提供一个同一的小操作集似乎是一个很大的挑战。


大科学不能独立完成的挑战

大型网站遇到的存储问题和大科学的级别相当，甚至更为严重。为了满足眼前的迫切需求，有的已经放弃了数据库管理系统技术而“另起炉灶”解决了或正在解决一些问题。然而，这些公司在开发自定义的数据库管理系统解决方案方面的预算和技术力量比大科学所能提供的要多得多。在没有资金和资源的情况下，大科学应当达成共同的标准，然后再鼓励实施，这一点至关重要。