Skip to main content

第 1 章 背景（Background）

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

导读：Michael Stonebraker

选读论文​

  • Joseph M. Hellerstein and Michael Stonebraker. “What Goes Around Comes Around.” Readings in Database Systems, 4th Edition (2005).
  • Joseph M. Hellerstein, Michael Stonebraker, James Hamilton. “Architecture of a Database System.” Foundations and Trends in Databases, 1, 2 (2007).

这两篇论文居然只是在大约十年前写成的，我对此感到惊讶。对于那篇数据库体系结构论文，令我惊讶的是，仅仅几年之后，许多细节就已经发生了巨大变化。对于那篇数据模型论文，令我惊讶的是，人类似乎从来不会真正从历史中学到什么。我们先谈数据模型那篇论文。

十年前，XML 是热门话题。厂商们急于把 XML 加入自己的关系数据库引擎。行业分析师，以及相当多的研究人员，都在宣称 XML 是“下一件大事”。十年后，它成了一个小众产品，整个领域已经继续向前。在我看来，正如那篇论文所预测的，XML 败给了以下几个因素的组合：

  • 过度复杂，复杂到没人能理解。
  • 对关系引擎进行复杂扩展，而这些扩展看起来性能并不理想。
  • 缺少一个被广泛接受、足够有说服力的使用场景。

有点讽刺的是，那篇论文曾预测，某个 X 会因为成功简化 XML 而获得图灵奖。这个预测完全错了！最终结果是：关系模型赢了，XML 输了。

当然，这并没有阻止“新手们”继续重复发明轮子。现在轮到 JSON 了，而 JSON 可以从三种角度来看：

  • 作为一种通用层次化数据格式。任何觉得这是好主意的人，都应该阅读那篇数据模型论文里关于 IMS 的部分。
  • 作为稀疏数据的表示。以员工属性为例，假设我们希望记录爱好数据。对于每种爱好，需要记录的数据会不同，而爱好本质上是稀疏的。这在关系 DBMS 中很容易建模，但会导致非常宽、非常稀疏的表。对于基于磁盘的行存储来说，这是灾难；但在列存储中则表现良好。对于前一种情况，JSON 是“hobbies”这一列的合理编码格式，若干 RDBMS 最近也已经加入了对 JSON 数据类型的支持。
  • 作为“读时模式”的机制。实际上，模式非常宽、非常稀疏，而基本上所有用户都只想看到这个模式的某个投影。从宽而稀疏的模式中读取时，用户可以在运行时说明想看到什么。从概念上说，这不过是一次投影操作。因此，“读时模式”只是对 JSON 编码数据执行的一种关系操作。

总之，对于稀疏数据，JSON 是一个合理选择。在这个语境下，我预期它会有相当长的生命力。另一方面，如果把它当成通用层次化数据格式，那就是一场正在酝酿的灾难。我完全预期 RDBMS 会把 JSON 吸收为系统中的一种普通数据类型。换句话说，它是编码稀疏关系数据的一种合理方式。

毫无疑问，下一版《红宝书》还会批判某种新的层次化格式；这种格式会由那些踩在前人脚趾上、而不是站在前人肩膀上的人发明出来。

过去十年中另一个引发大量关注的数据模型是 MapReduce。它由 Google 专门为支持自己的 Web 爬取数据库而构建。几年之后，Google 停止在这个应用中使用 MapReduce，转而迁移到 Bigtable。现在，世界其他人正在看到 Google 更早已经弄明白的事情：MapReduce 并不是一种具有广泛规模适用性的架构。相反，MapReduce 市场已经转变为 HDFS 市场，并且看起来准备进一步变成关系 SQL 市场。例如，Cloudera 最近推出了 Impala，这是一个构建在 HDFS 之上的 SQL 引擎，并不使用 MapReduce。

更近一些，在 HDFS 领域还有另一个值得讨论的方向，即“数据湖”。对 HDFS 集群的一种合理用法，是把它作为已摄取数据文件的队列；到现在，大多数企业已经投资了 HDFS 集群，并希望找到一些有用的事情让它们来做。随着时间推移，企业会弄清楚哪些文件值得投入清理成本，也就是进行数据整理；本书第 12 章会讨论这个主题。因此，在这段时间里，数据湖只是一个存放文件的“杂物抽屉”。此外，我们还会在第 5 章更多讨论 HDFS、Spark 和 Hadoop。

总结来说，过去十年里，似乎没有人真正吸取 “What Goes Around Comes Around” 中的教训。新的数据模型被发明出来，却最终演变成基于表的 SQL。层次结构被重新发明，而失败也是预料之中的结果。如果下一个十年仍然如此，我并不会感到意外。人类似乎注定要重复发明轮子！

再谈那篇体系结构论文。仅仅十年之后，我们就可以看到 DBMS 构造方式已经发生了相当大的变化。因此，细节确实变了很多，但论文描述的整体架构仍然基本正确。论文描述的是大多数遗留 DBMS，例如 Oracle、DB2 的工作方式；十年前，这是主流实现方式。现在，这些系统已经成了历史遗物；几乎什么方面都不算优秀。例如，在数据仓库市场中，列存储已经取代了论文中描述的行存储，因为它们快了 1 到 2 个数量级。在 OLTP 世界中，带有非常轻量事务管理的主内存 SQL 引擎正在迅速成为常态。本书第 4 章记录了这些新发展。现在已经很难找到遗留行存储仍然有竞争力的应用领域。因此，它们应该被送进“退休软件之家”。

很难想象“一种架构适合所有场景”会再次成为主导架构。因此，那些“大象”面临严重的“创新者困境”问题。在 Clayton Christensen 的经典著作中，他认为，遗留技术厂商很难在不失去客户群的情况下转向新的构造方式。不过，这些大象会如何尝试，已经很明显。例如，SQL Server 2014 至少包含两个引擎：Hekaton 这个主内存 OLTP 系统，以及传统 SQL Server 这个遗留行存储；二者统一在一个公共解析器之下。因此，Microsoft 的策略显然是在遗留解析器下面加入新引擎，然后支持把数据从疲惫的旧引擎迁移到更现代的引擎，同时不打扰应用程序。这个策略能有多成功，还有待观察。

不过，这些新系统的基本架构仍然遵循论文中描述的解析器、优化器、执行器结构。同时，线程模型和进程结构在今天仍然和十年前一样相关。因此，读者应该注意：并发控制、崩溃恢复、优化、数据结构和索引等细节正在快速变化，但 DBMS 的基本架构仍然保持完整。

此外，这些遗留系统还需要很长时间才会消亡。事实上，生产环境中仍然有大量 IMS 数据在使用。因此，任何数据库领域的学生都应该理解这些曾经在一段时间内占据主导地位的系统的架构。

再进一步，随着计算架构演进，这篇论文的某些方面未来可能会变得更加相关。例如，即将到来的 NVRAM 可能为新的架构概念，或者旧概念的重新出现，提供机会。