Readings in Database Systems 5th(2015) 阅读笔记及补充
Readings in Database Systems 5th(2015) 阅读笔记及补充
截止2020年底，5th ver是目前网上我自己能找到的最新版。原文请网络下载英文原版或参考知乎一些翻译版。http://www.redbook.io/
本书是几位数据库领域的大佬对数据库领域的近几十年（until 2015）的发展做了一些review和反思（部分带有一定的主观倾向），其中一些关键性的论文就是大佬自己的经典著作。前面的他们称为必读的chapters是一些数据库基本领域的发展和关键理论技术review，后面部分chapters更接近工业界，更多是对当时的业界发展的描述和个人预判。
但众所周知，2015年以来，数据库和大数据领域发生了许多巨大的变化，如云数据库的蓬勃发展、HTAP的探索、AI领域的爆发、自动驾驶数据库概念的发展、异构与智能硬件计算等，这些都是本书2015版尚未提及的，期待6th版本的迭代与完善。
下文并非原文翻译，而是一些个人笔记或补充，建议原文看完后再作补充阅读。
Chapter 1 Background
第一个讲的是数据表示模型，XML与JSON之争。目前来说单纯用于数据表示，业界里JSON比XML应用相对更广泛些，一方面因为整体可读性及简洁性，另一方面更接近高级编程语言的抽象数据结构。但由于XML属性与对象的表示贴近面向对象类结构，在部分领域仍具有较强生命力，包括Java生态配置协议、HTML、早期知识图谱表示等应用领域。
后面其他内容都是对后面chapter的一个intro，此处不赘述。
Chapter 2 Traditional RDBMS Systems
简单引出了三个典型数据库：System R，Postgres，Gamma。关于System R , Stonebraker有两个吐槽点，一个是SQL语言，另一个是ODBC。
实际上SQL依然是不可代替的数据库查询语言，ORM的引入会在后续语言一章中讲到。这里不得不提近几年BI和数仓的潮流，尤其是低代码概念发展和数据分析师角色的日益重要，使得SQL地位不再是程序员查询数据库的一个方法，而是一个解耦数据存储和数据分析的有效工具，这个功能是ORM这种语言相关的概念无法替代的。但这种潮流带来的一个痛点可能就是Stonebraker所吐槽的，越来越难维护 (原文SQL is like COBOL, COBOL是个上世纪的语言，现在基本都是些很老的公司系统或金融系统还在使用，只能靠一些五六十岁程序员维护，年轻人没人学)。众所周知，SQL虽然有标准，但是众多数据库厂商为了迎合客户或增强表达，自己定义了自己的SQL dialect；而数据分析的复杂需求和低代码定制化需求的引入，使得很多分析引擎提供的SQL离标准越来越远，包括许多自定义关键字。
另一个吐槽点ODBC（大家用的更多可能是演化版JDBC），Stonebraker举了几个例子，我去扫了下Pascal-R和Ruby on rails。Pascal-R提供的是一种SQL like的嵌入式语言特性方式来查询数据库，RoR是个典型的ORM代表（Web MVC框架，典型类似的还有Java spring orm和python django等），Ruby本身就是个面向对象比较彻底的语言。实际上这里可能要替ODBC/JDBC 喊个冤，ODBC/JDBC更多是一些low-level的封装和标准的定义，正因为JDBC这样的协议标准的较早出现，现在Java去连接不同关系型数据库才能那么容易，而且后面语言一章中也会提到，JDBC更大的价值在于定义了Java数据类型到数据库类型的映射，从而使强类型语言Java操作不同关系型数据库更加自如。ORM的作用在于更加接近对象和关系的思想，对于面向对象语言更加友好；但在一些复杂查询场景下，ORM比SQL要复杂且不利于DBA调优。
Postgres一小节原文没有描述太多信息，PGSQL的优点是开源、健壮、更接近标准数据库理论实现，这些数据库领域的同学都知道了。另一个提到的是抽象数据类型ADT，ADT搭配上用户自定义函数UDF，给了数据库二次开发者许多自主改进的空间。不少人抱怨过MySQL拓展性不好，难以改动适配自身需求；而PGSQL的开放机制以及开源的优势，使得在许多新数据库厂商中，PGSQL成为了首选定制化引擎。
Gamma离我们比较遥远，不熟悉。但按Stonebraker所说，它是现如今share nothing架构 和hash join 的contributor。但最后一段基于2015年的信息，Stonebraker认为share disk/share memory的data warehouse还没出现，现今已被云数据库厂商推翻了。
Chapter 3 Techniques Everyone Should Know
本章介绍一些数据库最核心的几个概念。
查询优化
现今优化器的很多研究性工作是在处理大规模或超大规模执行计划，HyperDB SIGMOD2018的一篇论文《Adaptive Optimization of Very Large Join Queries》就是讲如何处理5000个join规模的查询。但实际上，由于目标场景不同，所以不同数据库的优化器实现也会很不一样。正如文中所说，很多数据库（尤其是一些TP型数据库）只实现了一些基础方法，包括CBO和对二元操作符（实际指JOIN，SQL关系代数里，选择和投影是一元，JOIN是二元）的处理。JOIN问题实际是JOIN的顺序重排问题，业界常见的包括贪心、启发式、动态规划等，HyperDB采取的是按照不同规模匹配策略，但也有些数据库仅实现了简单的启发式算法 ( MySQL:) )。
并发控制
Bailis在这节后半部分写得有点飞了。传奇大佬Jim Gray的论文的两个点都是现在事务实现的基础，多粒度的锁和多种隔离级别。主要就是两个大的观点：一是很多数据库事务实际更多运行在非串行化的隔离级别上（又称弱隔离，常见运行级别是含Snapshot Isolation的Repeatable Read）；二是结合性能考虑，在并发控制不存在单方面最佳的策略，本质上是因为应用场景不确定。对于更新冲突少的场景，乐观控制会有较好的性能；对于冲突较多的场景，反而是悲观控制相对乐观更能避免回滚的开销。实际操作上，云数据库会可能会有不同的产品或不同的提前配置策略来应对用户需求，而且通常用户的单个实例的读写模式相对是固定的。再开下脑洞，如果真的后续出现了复杂事务场景需求，并发控制策略的选择是否也会变成一个optimizer呢?
数据库恢复
核心就是一个算法：ARIES。在ARIES中，数据库不需要在commit时将脏页写入磁盘（No force），数据库可以在任意时间进行脏页输盘（Steal）。但ARIES原论文很长，被称作数据库大学的毕业礼或成人礼。作者推荐了Ramakrishnan和Gehrke的本科教科书和Michael Franklin的调查论文作为温和的替代。
分布式
分布式一致性在数据库中的应用主要包括（但不限于）分布式事务、选主、日志复制等。分布式事务的一个经典实现就是2PC，用2PC来保证事务的原子提交，典型的XA协议就是2PC实现。相当一部分非云原生的数据库在选主上都做得很简单，要么是自己实现简单（如简单的HA，容易带来如脑裂等问题），要么是依靠分布式协调框架（常见如Zookeeper）。引入存储计算分离概念的云原生数据库，计算实例的选主上可能会没有太大变化，但在分布式存储副本选主上会引进一些一致性决策算法的实现，比如paxos或raft或类似变种算法。这些一致性决策算法同时可以帮助解决数据库存储的分布式日志复制问题。分布式云数据库其实就是文中最后一段提到数据库和分布式计算的gap在缩小的现象的体现。
Chapter 4 New DBMS Architectures
本章讲了四个大的变革：
OLAP领域的列存。列存问题网上很多讨论很多资料，经典的可以见论文《Column-Stores vs. Row-Stores: How Different Are They Really?》，此处不展开赘述。
OLTP的主内存数据库。作者Stonebraker认为OLTP数据库一般不会达到1TB这个量级，看好像hekaton这样的内存数据库。先不讨论1TB这个数据量级预计是否正确，事实上OLTP内存化是一个趋势，哪怕是传统mysql或pgsql，主要也是靠内存缓冲池来撑起日常的读性能。但是否纯粹的内存数据库是潮流，这个从发文到现在5年也还不是个明确可以say yes的问题。对于数据库客户来说，数据冷热分离、成本等也是重要的考量因素。事实上很可能是内存和磁盘存储(含分布式的磁盘存储)并存，它们需要一个合作的机制。也许对于传统单机数据库改造的云数据库来说，先是bufferpool缓冲池的精细化定制化调整，然后再过渡到一个对查询更友好的主内存引擎（列存或行列混合maybe？），但依然共存在相同的server层之下。
NoSQL领域爆发。Stonebraker认为，随着关系型数据库对开箱即用和半结构化支持这两点NoSQL优势的反应，NoSQL市场和SQL市场会逐渐合并。目前看来，一部分确实有这个倾向，NewSQL就是这么应运而生。但NoSQL常应用的大数据领域和关系型数据库领域的目标场景还是有不少分歧的，尤其包括成本目标，所以如今2021年我依然对大佬的这个结论持有怀疑。
第四次变革是Hadoop/HDFS/Spark等大数据套件的出现，这将在后文讨论。
少了2015至今的第五次变革，云数据库的发展。😃
Chapter 5 Large-Scale Dataflow Engines
这里提到的大数据技术都离不开所有做bigdata同行都知道的Google三驾马车论文：GFS、MapReduce、BigTable，后续开源社区基于论文实现了HDFS、Hadoop、HBase，可以说这是开源大数据技术的起点。文中花了不少笔墨描写MapReduce的发展，实际上MapReduce不仅是一门技术，还是一个数据批处理流程的逻辑框架，基于此演化出了Pig、Tez、早期Hive执行器等上层计算框架。直到内存逐渐降价以及Spark的出世，内存计算才为程序员们带来了更灵活的算子可能性。逐渐地，随着技术发展和内存计算发展，数据流不再满足于非实时离线批处理了，更实时的流计算开始进入大数据工程师的视野。早期的流计算框架要么像pig依然性能不足，要么像Storm主要应用于金融领域。Spark streaming的出现一方面满足了不需要很高实时的流处理需求(10ms级delay)，另一方面和批处理计算保持了统一的技术栈，也无需另外的服务部署。这是Spark开始统治大数据领域的开始，而pig、tez等计算框架也因为spark而生不逢时。Flink近两年在国内特别火，一方面是社区运营得当，另一方面是相比Spark streaming的微批处理，Flink算是真正的流计算。
Bailis part还有两个比较有意思的点：1. “the gaps between traditional warehouses and postMapReduce systems are quickly closing”，这个是得益于Hive、SparkSQL、Flink、Calcite、ClickHouse等不同子领域项目的百花齐放，使得一个开源大数据领域的数仓解决方案变得易得。 2. “stream processing, graph processing, asynchronous programming, and general-purpose machine learning. Are these specialized systems actually required, or can one analytics engine rule them all?” 从2015到目前看来，这些特殊系统的分化是趋势所在，流处理的Flink、机器学习的TensorFlow等在各自领域大放异彩佐证了这点。
Chapter 6 Weak Isolation and Distribution
核心讲的点是弱隔离，性能原因使得众多数据库实现倾向选择弱隔离方案。关于弱隔离能用于生产环境，作者认为的一个可信服的原因是"few applications today experience high degrees of concurrency"， Facebook的一个测试是在最终一致性的场景下，只有0.0004%的数据是过时不一致的。但这种使用惯性和部分数据库对串行化实现的”偷换概念“，会麻痹了用户或开发者，让他们以为自己就是跑在一个百分百隔离的事务环境中。这点是作者希望提醒大家的。
不管是mysql提供或常说的四种隔离级别，还是新的加上skew的隔离级别，他们都只是基于现有理论场景得出的。隔离级别解的是不同的anomaly，如果未来还发现现有解不了的anomaly，可能会继续增加。但大多数数据库的实现依然是照着四种隔离级别的定义实现，最多加上一个快照隔离（本质是一种Repeatable Read）。
Chapter 7 Query Optimization
第一个讨论的点是火山模型(Volcano)以及基于火山模型的搜索优化的级联模型(Cascaded)。这两个都是Goetz Graefe的经典论文，是数据库优化器领域非常foundamental的论文。个人觉得Volcano最大的价值是从工程上奠定了一个可行的实现框架，基于这个框架理论实现了PostgresSQL、DB2、MySQL、Oracle等关系型数据库引擎以及大数据生态下的Hive、SparkSQL、Calcite等。基于此，各家数据库在理论和实现上也在不断优化火山模型和完善实现细节，包括但不限于批量读取优化、pull-based变成push-based的代码执行优化（codegen等）、向量化与SIMD等。
第二个讨论的点是自适应查询，但是作者这里列举包含的点较多，往小了说就是一个数据库引擎的动态优化（比如文中举的两个例子），即在执行中（或反复执行中）去根据执行时的一些统计结果去做重新的优化，MySQL的自适应哈希索引AHI可能是一个执行时优化的例子；往大了说就是所谓的自动驾驶数据库概念，这里面甚至包括了超出数据库引擎本身的一些概念，比如机器学习、比如资源调度等。大部分的数据库所讨论的自适应查询还是限定在动态优化的概念中。
最后，作者还”嘲讽“了下MySQL，说可能是因为MySQL作为最出名最具代表的开源数据库，它的优化器做得太简单以至于普通开发者们不信任或不理解优化器。😃
Chapter 8 Interactive Analytics
交互分析和普通的OLAP优化最大区别是，交互分析通常要求是更实时的，在部分场景下甚至可以牺牲一定的数据精确性。本文介绍了三篇论文：
第一篇亮点是预计算，同时引出cube等数仓概念。预计算到如今仍然是一些固定分析场景的杀手锏，apache kylin等开源数仓方案仍然得益于此。
第二篇讲了一个数组优化，但它的更大贡献是使得MOLAP可以处理ROLAP的场景，解耦了数据模型和查询引擎。这个解释有点抽象，可以这么理解，就是用了基于稀疏数组的某种压缩方式建了索引，使得可以用MOLAP的思路和尽量少的资源高性能地查询ROLAP/MOLAP数据。
第三篇在线聚合，从文中可以看到有两种主要的方法：一种是预计算好部分基础的指标，然后聚合，Apache Kylin是一种典型；另一种是给予一些近似抽样算法如HyperLog++等，目前很火的分布式索引（也可以看做一个NoSQL）ElasticSearch在超过一定基数和数量的聚合计算中采取的正是HyperLog++算法。
Chapter 9 Languages
ODBC和ORM的问题在Chapter 2笔记中说过了，ORM慢的问题文中也提到了。CQL和Bloom不了解，无补充。
Chapter 10 Web Data
其实不太明白为什么Web数据会是单独一个chapter，对搜索领域不熟悉，但也没听说过现有的大型成熟Web搜索引擎是基于标准数据库构建的。可能和过去几十年的应用场景受限有关。下一十年的版本，个人感觉可以把基于数据库的一些计算应用作为一个chapter，像搜索打分（ElasticSearch、Solr等）、网络分析（一些Graph Database)、地理分析（一些GIS DB或甚至PGSQL）都是基于数据库或数据库模型架构构建出来的例子，由此还能引出一些特定模型的数据库的介绍，比如图数据库、GIS等。
Chapter 11 A Biased Take on a Moving Target: Complex Analytics
本文讲的其实就是数据科学。Stonebraker的 part和Joe的part有个较明显的区别，Stonebraker更多是一个自底向上的思维，考虑相关底层技术的优劣和适用性。但Stonebraker所写的很多问题已经被今天的TensorFlow或Spark MLLib解了，同时我不记得2015年的Spark版本是否只支持内存计算，但是现今的Spark是有办法内存不足split到磁盘上的。
Joe的视角更加上层，数据领域的相关从业者哪怕不是技术人员也能理解Joe的内容。"But unlike the BI market, this is not a category where database technology currently plays a significant role." 这是文中一个重要的观点。从目前来看，导致这个现象的最重要的问题是，什么东西是这个领域通用的需求，如果他不是通用的，他就只是个数据库读写的上层应用，analytics和数据库毫无关系；但如果是通用的，一些计算应用是有机会直接做进数据库里面变成一个特定的读取接口或任务。ElasticSearch在6.x后引入了机器学习功能，举个例子，可以用机器学习方法识别时序数据中的异常数据；一些云厂商的图数据库集成了简单图分析、社区探测等网络分析算法。但通常这类通用目标的计算，也只能覆盖一些粗糙的场景；做机器学习算法的都知道，精细的算法往往都需要定制化的调优。
Chapter 12 A Biased Take on a Moving Target: Data Integration
数据集成的其中一块大的工作通俗点就是现在的大数据ETL。传统ETL就是case by case的写转换器和清理器，新型的ETL相当一部分工作是在研究如何用机器学习来辅助做采集、抽取和转换，涉及到的子领域就包括模式匹配、信息抽取，进而背后衍生出自然语言处理（绝大部分数据是文本数据）、知识图谱、聚类分类等工作。这正是期望用于解决Stonebraker所说的"The ETL vendors do this at high cost and with low scalability."。
Joe的part提了一个整个IT业界常见的一个问题：懂数据逻辑的人可能不懂大数据和ETL技术，懂技术的人不懂数据背后的逻辑（这句话把数据换成行业应用也是完全一样的，懂行业的人和懂技术的人也存在gap）。在一家BI或数据分析公司里，懂数据的人可能是数据分析师，"they want to understand the data as it is being transformed, and assess whether it is getting closer to a form that’s useful for their business problem."。和文中提到的主要依赖传统spreadsheet的不同，近几年这些数据分析师更多是依靠是是交互分析技术和机器学习环境 (pyspark with spark mllib等)来去实现对数据的变化摸索。
