OceanBase 从0到1数据库内核实战教程学习笔记 - 1.数据库系统概述

今天跟大家分享一下 OceanBase 社区这边举办的《从0到1数据库内核实战教程》培训系列活动，这个活动的主要目的是给刚入门的同学们提供一个学习和了解数据库内核的机会，并通过活动培养大家对数据库的热情。

今天我学习和分享的内容来自于 OceanBase 开源负责人封仲淹老师（花名：纪君祥）的开篇介绍：数据库系统概述。

OceanBase 是一款从于2021年开源的 NewSQL/HTAP 数据库。在开源一年多的时间里，举办了很多的活动，也有很多社区的小伙伴参与到社区的学习和建设中来，但是在源代码学习方面，社区还没有做太多的工作，为了补足这个短板，社区也是借着举办第二次 OceanBase 大赛的机会，给大家安排了一系列的数据库内核学习培训。

本系列课程，适合任何想要从实战角度了解数据库的同学、DBA、数据库研发从业者。可以类比为大学的数据库专业课程，但是本套课程更偏向于实战角度。

可能有很多同学觉的“数据库入门是不是太难了？”，因为 MySQL 有200万行代码、OceanBase 有400万行代码、Oracle 有2000万行代码，学习起来代码量太过于庞大。不过大家不用担心，OceanBase 社区特别为大家设计了一款入门数据库 MiniOB，MiniOB 只有 2万行代码，可以帮助大家更好更轻松的入门。

• MiniOB - https://github.com/oceanbase/miniob
• Sqlite - https://github.com/sqlite/sqlite

另外，也推荐大家去学习一下两本很好的书：《数据库系统概念》、《数据库系统实现》。

1.数据库历史发展

首先 在讨论数据库发展历史之前，我们**思考一个问题，在没有数据库的时间里，如何解决这些潜在的数据库需求呢？**在20世纪60年代时，就必须解决这些问题。比如：

• 怎么实现持久化？- 从故障中恢复
• 怎么实现并发？
• 怎么定义数据格式？
• 怎么定义数据访问接口？

在数据库出现之前，通常采用应用程序直接操作底层数据，利用文件系统实现数据持久化，自己设计并发控制，自己设计故障恢复，自己定义数据格式和访问接口。这些所有的问题全部依赖应用程序来实现。应用开发时，特别头大。系统之间做迁移时成本特别高，很容易出问题。

这一个阶段出现这么多问题的主要原因就是没有在数据层做很好的抽象工作。这也是做任何大型系统需要考虑的两个点：接口和实现。

然后 在早期的数据库发展阶段，也出现了各种数据库管理系统模型。也能支持到上面提到的四个问题点。最主要的有以下两种：

• 层次模型 - 层次模型类似于今天的树状模型，也就是除了最终子节点以外，任何一个节点都有它的父节点。层次模型适合于树状的查询，离开了树状查询后它的应用场景局限性特别大。

• 网状模型 - 任何一个节点可以有一个或多个父节点，也可能会有一个或多个子节点。

现在看这两种数据库模型都没有流行起来，总结起来可能有两个原因：一是因为业务场景单一，无法适应多种使用场景；二是不能抽象出统一的访问接口，使用起来复杂度太高。

然后 我们看一下关系数据模型。关系数据库系统是起源于1970年 Edgar F. Codd 的论文《A relational model for large shared data banks》。并且他还提出了一个结构化查询语言SQL。

关系数据模型存在以下三个优点：

• 建立在严格的数学概念的基础上，有理论基础
• 数据模型清晰，所有的模型都使用关系来表示
• 接口清晰，逻辑层和物理层非常清晰的剥离

下面 我们介绍一下 NoSQL 数据库。NoSQL 数据库起源于 2006 年 Google 分享的论文《Bigtable: A Distributed Storage System for Structured Data》。

NoSQL 数据库的出现主要是为了解决传统的数据库不能线性扩张存储容量、计算性能等问题。因此它提出了数据分布式存储的功能点，底层存储不必非要结构化存储，可以采用 KV 的方式，也提供 API 的灵活访问方式。

需要强调的是，数据库领域是计算机科学领域里面获得图灵奖最多的，一共产生了4位图灵奖获得者：

• Charles W. Backman - 是网状数据库奠基者
• Edgar F. Codd - 提出了关系数据库模型
• Jim Gray - 提出了事务模型整套理论的大师
• Michael Stonebraker - 对当今数据库影响特别大，Ingres影响到了 PostgreSQL、Informix、SQL Server等

2.数据库系统分类

我们通过下图来回顾一下数据库的历史，了解一下不同数据库的分类：

• 1970～2000年阶段，是单机关系数据库时代，比如数据库鼻祖 IBM System R，Oracle 和 DB2 受它的影响也很大。开源领域名气最大的要属 MySQL，是1995年出现的；另外还有内核强大的 SQL Server 数据库，它在优化器和存储上也有很多创新性；最后就是起源于 Ingres 的 PostgreSQL。
• 2000～2010年阶段，开始出现大数据、分布式等概念，也随之产生了很多NoSQL数据库。比如 Google 三驾马车，GFS、MR和BigTable；还有解决MR并行计算能力的Spark和HBase；还有专门针对一些特别场景的：OLAP-Greenplum、内存KV-Redis、文档JSON-MongoDB等。
• 2010至今，开始出现NewSQL/In-Memory/HTAP等概念数据库产品。比如 OceanBase、Google Spanner；云上数据库系统 Amozon Aurora/Polar，它们上层是 MySQL 计算引擎，底层是自己开发的存储引擎；SAP HANA 内存数据库，很好的 HTAP 数据库；还有 TiDB 和 CockroachDB，TiDB 最早是借鉴 CockroachDB 发展起来的面向 MySQL 生态的 NewSQL 数据库。

3.数据库系统概述

最后一个章节，我们还是通过纪老师分享的一张图，来概述一下数据库系统各个部分的功能：

数据库大概分为三个部分：SQL引擎、存储引擎和事务引擎。

3.1 SQL 层的执行逻辑如下：

1. 当数据库接受 SQL 以后，它会首先经过 parser，parser 会先做词法分析和语法分析，拆分词并生成语法树；
2. 接着将语法数传给 Query result cache，query result cache 通常对 SQL 进行性能最快的硬解析，然后如果发现命中了，它会马上返回给访问应用，忽略后面所有的操作；
3. 如果没有命中，就要走到 resolver，它会对语法树中部分变量进行替换，生成新的语法树，并把这个语法数传给 plan cache进行匹配；
4. 如果 plan cache 命中的话，会从 plan cache 中拿出它的物理执行计划，直接交给 Executor 执行器进行执行；
5. 如果 plan cache 命中失败，它会扔到优化器，优化器大概分为两个部分：逻辑优化（Transformer）和物理优化（Optimizer），逻辑优化是根据一些逻辑规则进行一些优化，在不考虑代价的前提下，比如计算下推、Sub Query、Join变换等；物理优化会在 Optimizer 部分进行一些基于代价的优化，选择最优的执行计划；二者之间不断迭代，形成一个相对而言比较优的执行计划；
6. 接下来会扔给执行器，在执行器中可能会做一个 Code Generator 的操作，以生成更高效的算子。
   

3.2 事务层

1. 事务管理器主要分为两部分，第一部分为日志与恢复，所有的数据库在执行SQL操作底层过程中都要写一些日志，有物理日志（Bin log）和逻辑日志（Redo log）另种，并且还会提供一些恢复功能；第二部分为并发控制，怎么控制锁和MVCC；
2. 在存储层有 Buffer Pool，所有的数据不会直接从存储捞出来，很多时候都要经过 Buffer Pool，Buffer Pool 会去查询 Catalog，然后从 Catalog 中拿到所有的元数据信息，然后再发请求给存储管理器，存储管理器从存储中取对应的数据。

事务具有以下四个特点：

3.3 存储层

存储在工业界基本有两种基础数据结构，一种是 O(1) 的哈希表，它的 put/get 性能特别快，唯一的缺点是不支持范围 scan。另外一种是关系数据库用的特别多的 B+ 树，它是一个平衡的二叉树，读写性能都比较均衡。

最近十几年，有一个比较有名的 LSM-Tree，它更适合于写多读少的场景。它的特点是有一个数据批量合并刷盘的操作，可以减少随机写入的代价。

3.4 三者之间的关系与区别

最后的最后，如果大家感兴趣，可以多关注和参与 OB 的活动：https://ask.oceanbase.com/t/topic/35601006。