Skip to main content

第 2 章 传统 RDBMS 系统（Traditional RDBMS Systems）

原文：Readings in Database Systems, Fifth Edition (2015)，Chapter 2: Traditional RDBMS Systems，Introduced by Michael Stonebraker。原书文本采用 CC BY-NC-SA 4.0 许可；本译文按同一许可发布。

导读：Michael Stonebraker

选读论文​

  • Morton M. Astrahan, Mike W. Blasgen, Donald D. Chamberlin, Kapali P. Eswaran, Jim Gray, Patricia P. Griffiths, W. Frank King III, Raymond A. Lorie, Paul R. McJones, James W. Mehl, Gianfranco R. Putzolu, Irving L. Traiger, Bradford W. Wade, Vera Watson. “System R: Relational Approach to Database Management.” ACM Transactions on Database Systems, 1(2), 1976, 97-137.
  • Michael Stonebraker and Lawrence A. Rowe. “The design of POSTGRES.” SIGMOD, 1986.
  • David J. DeWitt, Shahram Ghandeharizadeh, Donovan Schneider, Allan Bricker, Hui-I Hsiao, Rick Rasmussen. “The Gamma Database Machine Project.” IEEE Transactions on Knowledge and Data Engineering, 2(1), 1990, 44-62.

本节收录的论文讨论的，可以说是三个最重要的真实 DBMS 系统。在这篇导读中，我们将按时间顺序讨论它们。

System R 项目大约在 1972 年左右于 IBM Research 启动，由 Frank King 领导。到那时，Ted Codd 的开创性论文已经发表 18 个月，许多人都明显意识到，应该构建一个原型来检验他的想法。不幸的是，Ted 没被允许领导这项工作，于是他转而思考 DBMS 的自然语言接口。System R 很快决定实现 SQL；SQL 从 1972 年一种干净的块结构语言，演变成这里这篇论文中描述的复杂得多的结构。关于 SQL 语言设计的评论，可参见十年后写成的文献 [46]。

System R 被组织成两个小组：“下半部”和“上半部”。它们并不是完全同步的，因为下半部实现了 links，而上半部并不支持 links。为下半部团队的决定辩护一下：他们显然在与 IMS 竞争，而 IMS 具有这种构造，所以包含它是很自然的。只是上半部没能让优化器支持这个构造。

事务管理器可能是这个项目最大的遗产，而且它显然出自已故 Jim Gray 之手。他的许多设计至今仍然存在于商业系统中。排在第二位的遗产是 System R 优化器。基于代价、使用动态规划的方法，至今仍然是优化器技术的黄金标准。

我对 System R 最大的抱怨是，团队从未停下来清理 SQL。因此，当“上半部”被简单地粘到 VSAM 上形成 DB2 时，语言层面被原封不动地保留下来。这个语言所有令人恼火的特性一直延续到今天。SQL 将会成为 2020 年的 COBOL：一种我们被迫继续使用、人人都会抱怨的语言。

我第二大的抱怨是，System R 使用子例程调用接口，也就是现在的 ODBC，把客户端应用程序连接到 DBMS。我认为 ODBC 是这个星球上最糟糕的接口之一。为了发出一个查询，必须打开数据库、打开游标、把游标绑定到查询，然后对数据记录逐条执行 fetch。仅仅运行一个查询，就需要一页相当晦涩的代码。Ingres [150] 和 Chris Date [45] 都有更干净的语言嵌入方式。此外，Pascal-R [140] 和 Rigel [135] 也是把 DBMS 功能包含进编程语言的优雅方式。直到最近，随着 LINQ [115] 和 Ruby on Rails [80] 出现，我们才看到更干净的、面向特定语言的嵌入方式重新兴起。

System R 之后，Jim Gray 前往 Tandem 从事 NonStop SQL 工作，Kapali Eswaran 则创办了一家关系数据库初创公司。团队其余大多数成员留在 IBM，继续从事各种其他项目，包括 R*。

第二篇论文讨论 Postgres。这个项目开始于 1984 年，当时已经很明显，继续使用学术版 Ingres 代码库做原型已经没有意义。关于 Postgres 历史的叙述见文献 [147]，读者可在那里看到开发过程起伏的完整回顾。

不过，在我看来，Postgres 的重要遗产是它的抽象数据类型（ADT）系统。大多数主流关系 DBMS 都采用 Postgres 模型，加入了用户定义类型和函数。因此，这个设计特性一直延续至今。这个项目还实验了 time-travel，但效果并不太好。我认为，随着更快的存储技术改变数据管理的经济性，非覆盖式存储终有一天会迎来自己的高光时刻。

还应该指出，Postgres 的很大一部分重要性应归功于一个健壮且高性能的开源代码线的可用性。这是开源社区开发和维护模型的最佳例子之一。20 世纪 90 年代中期，一支临时组成的志愿者团队接手 Berkeley 代码线，并从那以后一直引导它的发展。Postgres 和 4BSD Unix [112] 都对使开源代码成为首选代码开发机制起到了重要作用。

Postgres 项目在 Berkeley 一直持续到 1992 年，随后成立了商业公司 Illustra 来支持商业代码线。关于 Illustra 在市场中经历的起伏，可参见文献 [147]。

除了 ADT 系统和开源发布模型之外，Postgres 项目的另一个关键遗产，是培养了一代训练有素的 DBMS 实现者；他们后来在构建若干其他商业系统中发挥了重要作用。

本节的第三个系统是 Gamma，它于 1984 到 1990 年间在 Wisconsin 构建。在我看来，Gamma 普及了面向多节点数据管理的 shared-nothing 分区表方法。虽然 Teradata 同期也有相同思想，但正是 Gamma 普及了这些概念。此外，在 Gamma 之前，没人谈论哈希连接；因此，Gamma 应该与 Kitsuregawa Masaru 一起，被认为提出了这一类算法。

基本上所有数据仓库系统都使用 Gamma 风格的架构。使用共享磁盘或共享内存系统的想法几乎已经消失。除非网络延迟和带宽变得可以与磁盘带宽相比，否则我预计当前的 shared-nothing 架构会继续存在。