Chapter 1: Background
Introduced by Michael Stonebraker
Readings:
让我感到震惊的是，这两篇论文居然是在短短十年前写成的！对于模型论文（anatomy paper），我惊讶的点在于仅仅几年之后的细节已经发生了很大的变化。对于数据模型论文（data model paper），我惊讶的点在于似乎从来没有人从历史中吸取经验。让我们先谈谈数据模型论文（data model paper）。
十年前，流行的都是 XML。厂商们打算将 XML 添加到他们的关系型引擎中。行业分析师（和一些科研人员）吹捧 XML 为 “下一个大事（the next big thing）”。结果十多年后它却已经变得小众，并且这个领域也已向前发展了。在我看来，（正如论文中预测的那样）导致这个结果的因素有：
过于复杂（导致没有人能够理解）
关系型引擎的复杂扩展，这似乎并不那么好，而且
没有被广泛接受的令人信服的用例
有点讽刺的是，论文中预测 X 会通过成功简化 XML 这项工作而赢得图灵奖。现实结果证明这个预测完全错误了！。 net-net （关系型）胜利了，而 XML 输了。
当然，这并没有阻止 “新人们（newbies）” 重新造轮子。现在这段时间出现是 JSON ，有三种视角方式看它：
- 一种通用的分层数据格式。认为这很好的每一个人都应该去阅读一下数据模型论文中关于IMS（Information Management System）的部分。
- 一种用于稀疏数据的表示法。考虑到关于一个雇员的属性，假设我们希望记录爱好数据。对于每个爱好，我们记录的数据将是不同的，而爱好从根本上来说是稀疏的。这在关系型数据库管理系统中是很简单的模型，但是它导致了非常宽的、非常稀疏的表。这对基于磁盘的行存储来说是灾难性的，但在列存储中却可以正常工作。在前一种情况下，JSON是 “爱好 “列的一种合理的编码格式，而且一些RDBMS最近已经增加了对JSON数据类型的支持。
- 作为一种 “schema on read” 的机制。实际上，schema 是非常宽泛和稀疏的，基本上所有的用户都会想要 schema 的一些投影（projection）。当从一个宽而稀疏的 schema 中读取时，用户可以说他在运行时想看到什么。从概念上讲，这只不过是一个投影（projection）操作。因此，”读取模式 “只是对JSON编码数据的一个关系操作。
总之，对于稀疏数据而言 JSON 是一个合理选择。在这种情况下，我希望它能够得到更多使用（I expect it to have a fair amount of “legs”）。另一方面，作为一种通用的分层数据格式，它会带来灾难。我很期待 RDBMS 们在他们的系统中把 JSON 仅仅作为一种数据类型（众多类型中的一种）。换句话说，它是一种合理的关系型数据的编码方式的备选项。
毫无疑问，下一版的 RedBook 又会将抨击一些新出现的分层格式，因为这些发明者是站在前人的脚趾上而不是肩膀上发明的。
另一个在过去十年引起广泛关注的数据模型是 Map-Reduce，它是由谷歌专门构建的，用于支持他们的网络爬行数据库。。几年后，谷歌停止将 Map-Reduce 用于该应用，转而使用 BigTable 。现在，世界上其他国家都看到了谷歌早先发现的情况；Map-Reduce 不是一个具有广泛适用性的架构。相反，Map-Reduce 市场已经演变成了 HDFS 市场，并且似乎准备成为关系型 SQL 市场。例如，Cloudera 最近推出了Impala，它是一个 SQL 引擎，建立在 HDFS 之上，而不是使用 Map-Reduce。
最近，在 HDFS 领域出现了另一个值得讨论的推动力（thrust），即 “数据湖”。HDFS集群的一个合理用途（现在大多数企业已经投资了，并希望找到一些有用的东西来做）是作为一个已经被摄入的数据文件的队列。随着时间的推移，企业会发现哪些是值得花精力去清理的（数据整理；本书第12章涉及）。因此，数据湖在这段时间里只是一个文件的 “垃圾抽屉”（“junk drawer”）。另外，关于 HDFS、Spark 和Hadoop，我们在第五章会有更多介绍。
总之，在过去的十年中，似乎没有人注意到 “来来往往 “的教训。新的数据模型已经被发明出来，但却演变成了表上的SQL。层次结构被重新发明，失败是预料之中的结果。我不会惊讶地看到未来十年会有更多相同的情况。人们似乎注定要重新造轮子!
关于 Anatomy 的论文，仅仅十年之后，我们可以注意到 DBMS 的构建方式发生了实质性的变化。因此，细节已经发生了很大的变化，但是论文中描述的整体架构仍然非常正确。这篇论文描述了大多数传统的DBMS（如 Oracle、DB2）是如何工作的，十年前，这是普遍的实现。现在这些系统已是历史文物；在各种方面都不是很好。例如，在数据仓库领域，列存储已经取代了本文所描述的行存储，因为它们的速度要快1-2个数量级。在OLTP领域，具有轻量级事务管理的 main memory SQL引擎正在迅速成为常态。本书第4章记录了这些新的发展。现在很难找到一个传统行存储仍具有竞争力的应用领域。因此，它们应该被送进 “退休软件之家”。
很难想象，”one size fits all”会再次成为主导性架构。因此，巨头们（elephants）面临着困难的 “创新者困境 “。在 Clayton Christiansen 的经典著作中，他谈到传统技术厂商很难在不失去客户群的情况下产生出新的结构。然而，巨头们要如何尝试已经很明显了。例如，SQLServer 14 至少是两个引擎（Hekaton—一个主内存OLTP系统和传统的SQLServer—一个传统的行存储）联合在一个共同的分析器下面。因此，微软的策略显然是在他们的传统解析器下增加新的引擎，然后支持将数据从一个疲惫的引擎移动到更现代的引擎，而不干扰应用程序。这将取得多大的成功，还有待观察。
然而，这些新系统的基本架构仍然遵循论文中描述的 parsing/optimizer/executor 结构。另外，线程模型和进程结构在今天和十年前一样重要。因此，读者应该注意到，并发控制、崩溃恢复、优化、数据结构和索引的细节都处于快速变化的状态，但是 DBMS 的基本架构仍然保持不变。
此外，这些传统系统还需要很长的时间才会消亡。事实上，仍然有大量的 IMS 数据在生产中使用。因此，建议该领域的任何学生都要了解（暂时占主导地位的）系统的架构。
此外，随着计算架构的发展，本文的某些方面有可能在未来变得更加相关。例如，即将到来的 NVRAM 可能为新的架构概念或旧的架构概念的重新出现提供一个机会。
若有收获，就点个赞吧
0 人点赞
