背景（Background）
由 Michael Stonebraker 介绍
被选中的读物
这两篇文章写作于十年之前，真让我感到惊讶！毕竟他们深度剖析的数据模型，在短短数年之内，其细节就出现了巨大的变化，而围绕着数据模型这个领域，最让人吃惊的就是，人们似乎从来都不能够从历史当中汲取教训。因此我们首先就将围绕数据模型这方面的文章展开讨论。
十年以前，xml 是最为流行的模型。软件供应商们专注于向他们的关系型引擎中，加入xml相关的功能特性。而在工业级的数据分析人员（以及许许多多的研究人员）当中，XML 普遍被视作为“业界的下一件大事”（the next big thing）。可在十年之后，可以看到，xml已经变成了小众的产品，而领域内的目光，已然移步到其它的事情之上。就我本人（以及文章中做出的预测）来看，xml文档走向衰落，其原因归纳为如下：
- 复杂性过高（以至于没有人可以理解）
- 对于关系模型的拓展过于复杂，且在真实应用中表现并不出色
- 没有广泛的可信应用案例
而具有一点讽刺意味的是，文章中觉得的，x 将通过对 xml 文档的简化而摘下图灵奖的这个预测，如今已经被证明完全错误。关系型数据模型再次取得了胜利，而 xml 则输掉了战争。
当然，这可没有阻挡“新人们”重新发明轮子。当下的挑战者已经变成了 Json，它可以采用下面的三种方式，来进行查阅：
- 一种通用的分层数据格式。任何赞同这种观念的人，可以阅读 IMS 文章当中有关数据模型的部分
- 一种稀疏数据的表示方法。请让我们来想象一组有关雇员的属性，并假定，我们希望记录雇员们的爱好。而对于每一类爱好，我们所做的数据记录，都会有所差异，且基本上非常稀疏。尽管在关系型数据库当中，为“爱好”做出建模非常简单，然而它会导 致相当庞大的，且十分稀疏的数据表。对于基于磁盘存储的行数据而言，这种做法无疑意味着一场灾难，不过对于按列存储的数据而言，这种做法却工作良好。而在前面的那种情况下面，Json 将会成为一种可靠的，适合于记录“爱好”的数据列的选择，且最近有一些不同种类的关系型数据库也提供了对于 Json 数据类型的支持
- 一种“读取时架构”（schema on read）的机制。就生产实践而言，这种模式非常广阔也相当稀疏，而基本上所有的用户们都非常期待，可以对这种模式作一些投影。也就是，当我们从广阔的，稀疏的数据模式读取数据的时候，某个用户可以直接表达出，他希望在运行时能够查询出来的内容。就概念上而言，这无非就是一种投影的操作。所以，“读取时架构”，只是一种对于 Json 编码数据的关系型操作
总而言之，Json 是一种稀疏数据方面的可靠选择。而融合历史方面的情况来看，我期待它可以做出许多方面的拓展；但在另外一个方面，我又认为，作为一种通用的分层数据格式，Json 正在演变为一场灾难。我相当期待关系型数据库系统，能够就只把 Json 归纳为他们当中的一种数据类型。换而言之，对于编码那些备用的关系型数据而言，Json 是一条可靠的途径。
一件不容置疑的事情就是，下一版本的红皮书，必将抛弃一些仅仅只是立足于前人脚趾，而非肩膀上的人所发明出来的新分层数据格式。
在过去十年间引发了业界许多讨论的另外一种数据模型，就是 Map-Reduce，它是 Google 为顺利支持他们的互联网爬虫数据（web crawl data base）而建造出来的。然而就在几年以后，Google 选择停止为自家应用程序使用 Map-Reduce，而是使用 Big Table 来做替代。而目前，世界上许多其他地方的人，开始看到了 Google 早些时候发现到的事情： Map-Reduce 并不是一种具备广阔延伸性的应用体系架构。与之相对的，Map-Reduce 的市场已经逐渐向着 HDFS 的市场而做延伸，同时似乎计划进军关系型 SQL 市场。举例来说，Cloudera 最近就引入了 Impala，它是一种 SQL 引擎，架构于 HDFS 之上，而非 Map-Reduce。
而到了最近，在HDFS的土地上面，出现了另外一种值得一提的推动力，技即“数据湖”（data lakes）。它以一组被整合起来的数据队列的形式而作为一种合理应用 HDFS 集群的策略被使用（截至目前，绝大多数商业集团公司，已经开始在这一领域投入资源，并希望挖掘出一些对他们有用的事情来）。假以时日，商业公司将会明白，究竟哪一些部分，值得让他们进行清查与处理（数据的管理策略，我们将会在这本书的第十二章节当中，进行讨论）。因此，数据湖在这个时候，更像只是一种“垃圾抽屉”（junk drawer）一样。同样地，我们将会在第五章中，就 HDFS，Spark 与 Hadoop 展开讨论。
简单来说，已然逝去的十年之中，似乎没有人领悟到“转过头来”（comes around）的教训。新的数据模型不断诞生，然而无非就是在数据表上变形为 SQL。而分层模型的再次发明正如我们所的预测那样，走向失败。而假若在下一个十年如果同样类似的场景再度上演，我也不会感到有什么惊讶的。因为人们似乎命中注定，总是在重新发明轮子！
而对于那些就数据库展开深度剖析的文章而言；在短短十年之后，我们就已然发现，数据库的构建方式，已经发生了巨大的变化。好在，即使内部的细节变化繁多，但是文章之中描述的总体架构，依旧贴近当下的实践。由我们所选中的这篇文章，将会描述，绝大多数的历史遗留下来的数据库（如，Oracle，DB2）如何展开他们的工作。回首 十年以前，它们是当时十分流行的数据库实现方案。而再看今朝。这些数据库系统，已然变作历史的遗产；而不再一招吃遍天下。就比如，在数据仓库的市场里面，得益于1～2个数量级的性能提升，列存储对文章里面提及的行存储已经做到了完全替代。而在OLTP的世界里面，带有轻量级事务管理引擎特性的内存SQL引擎，正在迅速常态化。我们集中把这些新的变化记录在红皮书的第四章里面。到了今天，已经很难再找到一个充满活力的，行存储模式占优的应用领域。所以，他们理当要被送到“退休软件之家”去。
我们很难想象，“一招吃遍天下”（one size fits all）将会再一次成为主流的架构。大象往往存在着“革新者困境”（innovators dilemma）的糟糕问题。而 Clayton Christiansen 在他撰写的经典著作中指出，传统的软件供应商，很难在不丢失顾客的情况下，转变到新的结构中来。即便如此，大象面向未来的转变已经非常明显。例如，SQLServer 14 版本中，已经配备了至少两种引擎组件（Hekaton 是一种内存 OLTP 系统，而 SQLServer 则是一种历史遗留下来的行存储），并将他们聚合在同一个公共引擎下面。因此，微软公司的战略其实非常清晰，就是不断向常规的解析器中添加新的引擎，以支持数据在不干扰到应用程序运行的情况下，从已经过时的引擎平滑地迁移到新的引擎。不过这种战略的成功与否，依旧有待观察。
不过，这些新的系统的基本架构，持续遵循着我们在论文中提出的解析-优化-执行的结构（parsing/optimizer/executor structure）。除此之外，线程模型与处理器模型，无论是今天还是十年前，都一样地重要。所以，读者不仅仅理当注意到事务控制，故障恢复，查询优化，数据结构及索引的细节依旧处于不断变化的状态，同时也要注意到，数据库的基本结构，依旧保持不变。
除此之外，那些历史遗留系统依旧需要很长时间才可以走向灭亡。而实际上，IMS 依旧被应用到无数的生产用例之中。有鉴于此，我们建议所有数据库领域的同学们，对这款曾经独占鳌头的数据库系统的架构，做一个了解。
更进一步，伴随着计算机体系结构的发展，本文所牵涉的各个方面，很有可能会演变地更加密切相关。就比如说，即将到来的 NVRAM 很有可能为新的架构理念，或者旧结构的二次新生带来机遇。