第 4 章 新的 DBMS 架构（New DBMS Architectures）
原文：Readings in Database Systems, Fifth Edition (2015)，Chapter 4: New DBMS Architectures，Introduced by Michael Stonebraker。原书文本采用 CC BY-NC-SA 4.0 许可；本译文按同一许可发布。
导读：Michael Stonebraker
选读论文
- Mike Stonebraker, Daniel J. Abadi, Adam Batkin, Xuedong Chen, Mitch Cherniack, Miguel Ferreira, Edmond Lau, Amerson Lin, Sam Madden, Elizabeth O'Neil, Pat O'Neil, Alex Rasin, Nga Tran, Stan Zdonik. “C-store: A Column-oriented DBMS.” SIGMOD, 2005.
- Cristian Diaconu, Craig Freedman, Erik Ismert, Per-Ake Larson, Pravin Mittal, Ryan Stonecipher, Nitin Verma, Mike Zwilling. “Hekaton: SQL Server's Memory-optimized OLTP Engine.” SIGMOD, 2013.
- Stavros Harizopoulos, Daniel J. Abadi, Samuel Madden, Michael Stonebraker. “OLTP Through the Looking Glass, and What We Found There.” SIGMOD, 2008.
DBMS 格局中发生的最重要事情，可能就是“一种架构适合所有场景”的死亡。直到 21 世纪初，传统的基于磁盘的行存储架构仍然无处不在。实际上，商业厂商手里只有一把锤子，于是把一切都当成钉子。
过去十五年里，发生了几次重大剧变，我们逐一讨论。
首先，社区意识到，在数据仓库市场中，列存储显著优于行存储。数据仓库最早在面向客户的零售环境中被接受，并很快扩展到一般的面向客户数据。仓库记录客户交易的历史信息。实际上，它记录的是每次客户交互的 who、what、why、when、where。
传统观点是围绕一个中央事实表（Fact table）来组织数据仓库，事务信息记录在其中。围绕它的是维度表，这些维度表记录可以从事实表中分解出来的信息。在零售场景中，会有 Stores、Customers、Products 和 Time 的维度表。结果就是所谓的星型模式 [96]。如果门店被分组到区域中，那么可能存在多层维度表，从而形成雪花模式。
关键观察是，事实表通常很“胖”，往往包含一百个或更多属性。显然，它们也很“长”，因为有非常多事实需要记录。一般来说，面向数据仓库的查询混合了重复请求，例如按门店生成月度销售报告，以及 ad hoc 请求。例如，在零售仓库中，人们可能想知道暴风雪发生时东北部什么商品卖得好，或者飓风期间大西洋沿岸什么商品卖得好。
此外，没人会运行 select * 查询来获取事实表中的所有行。相反，他们总是指定某个聚合，从表中的 100 个属性里取出大约半打属性。下一个查询会取出另一组属性，而过滤条件之间几乎没有局部性。
在这个使用场景中，很明显，列存储从磁盘移动到主内存的数据量会比行存储少 16 倍，也就是 6 列对比 100 列。因此，它具有不公平的优势。进一步考虑一个存储块。在列存储中，一个块上只有一个属性，而行存储会有 100 个属性。压缩显然会在一个属性上比在 100 个属性上效果更好。此外，行存储在每条记录前都有头部，在 SQL Server 中显然是 16 字节。相比之下，列存储会小心避免这种头部。
最后，基于行的执行器有一个内层循环，用来检查一条记录是否对输出有效。因此，内层循环的开销相当可观，并且要对每条被检查的记录支付一次。相比之下，列存储的基本操作是取出一列并挑出符合条件的项。因此，内层循环开销是按被检查的每列支付一次，而不是按被检查的每行支付一次。这样，列执行器在 CPU 时间上高效得多，从磁盘取回的数据也少得多。在大多数真实环境中，列存储比行存储快 50 到 100 倍。
早期列存储包括 20 世纪 90 年代出现的 Sybase IQ [108] 和 MonetDB [30]。不过，这项技术可以追溯到 20 世纪 70 年代 [25, 104]。21 世纪头十年，C-Store/Vertica 作为资金充足的初创公司出现，并提供了高性能实现。在接下来的十年里，整个数据仓库市场从行存储世界转变为列存储世界。可以说，如果 Sybase 更积极地投资这项技术，并完成多节点实现，Sybase IQ 本可以更早做到同样的事情。文献 [30] 有力地讨论了列执行器的优势，尽管它非常深入细节，读起来并不容易。
第二次重大剧变是主内存价格急剧下降。当前，人们也许可以用 25,000 美元买到 1 TB 内存，而一个带有几 TB 内存的高性能计算集群可能只需约 10 万美元。关键洞察是，OLTP 数据库其实并没有那么大。1 TB 是一个非常大的 OLTP 数据库，并且已经是主内存部署的候选对象。正如本节 “looking glass” 论文中指出的，当数据能放进主内存时，人们并不想运行基于磁盘的行存储，因为开销实在太高。
实际上，OLTP 市场正在变成主内存 DBMS 市场。再次强调，传统基于磁盘的行存储根本没有竞争力。为了运行良好，并发控制、崩溃恢复和多线程都需要新的解决方案；我预计 OLTP 架构会在未来几年继续演化。
我目前最好的猜测是，没有人会使用传统两阶段锁。基于时间戳排序或多版本的技术很可能占据优势。本节第三篇论文讨论 Hekaton，它实现了一种最先进的 MVCC 方案。
崩溃恢复也必须处理。一般而言，被提出的解决方案是复制和在线故障转移，这由 Tandem 在二十年前开创。传统智慧是写日志，把日志通过网络传送出去，然后在备份站点向前滚动。这种主动-被动架构在文献 [111] 中被证明比主动-主动方案差 3 倍；在主动-主动方案中，事务只是简单地在每个副本上运行。如果运行主动-主动方案，就必须确保事务在每个副本上以相同顺序运行。不幸的是，MVCC 不会做到这一点。这促使人们关注确定性并发控制方案；在端到端系统中，它们很可能比 MVCC 快得多。
无论如何，OLTP 将转向主内存部署，而一类新的主内存 DBMS 正在展开，以支持这个使用场景。
第三个已经展开的现象是 “NoSQL” 运动。本质上，大约有 100 个左右的 DBMS 支持各种数据模型，并具有以下两个特点：
- “开箱即用”体验。程序员很容易开始使用它们，并做出有生产力的事情。相比之下，RDBMS 非常重量级，需要预先定义模式。
- 支持半结构化数据。如果每条记录都可以为不同属性提供值，那么传统行存储会有非常非常宽的元组，而且会非常稀疏，因此效率低下。
这给商业厂商敲响了警钟：要构建更容易使用、并支持 JSON 等半结构化数据类型的系统。总体上，我预计随着 RDBMS 对上述两点做出反应，NoSQL 市场会随时间与 SQL 市场合并。
第四次剧变是 Hadoop/HDFS/Spark 环境的出现，这将在第 6 章讨论。