【视频】数据库系统概述 | 学习笔记

开发者学堂课程【从0到1数据库内核实战教程：【视频】数据库系统概述】学习笔记，与课程紧密连接，让用户快速学习知识。

课程地址：https://developer.aliyun.com/learning/course/1083/detail/16068

【视频】数据库系统概述

内容介绍：

一、课程介绍

二、数据库系统概述

在开始分享之前分享一个小的插曲，OceanBase 是去年6月1号开源的，开源以来，我们在社区做了很多的培训和分享，有 OBCA 的培训，有 OBCP 的培训，有OceanBase 部门与实战的培训，也有深入浅出的 OceanBase 培训，但是一直没有出现面向开发者的培训，社区的很多小伙伴们就会经常过来，询问我们什么时候能够出一个面向开发者的培训。正好我们最近正在举办数据库或大赛，也就OceanBase 数据库大赛，从0到1打造0的数据库大赛，为了更好的让大家能够参与到这次大赛，我们特意举办了这次从0到1实战数据库内核的培训。

本次分享主要是关于数据部系统概述，这门课其实很多时候是源自大学里数据库实现的课程，但是我们是来自工业界，我们对数库的理解可能实战的部分会更多一点，相对大学的老师来说，相对大学的课程来说，我们理论部分可能会偏少一点，会加入更多我们自己对数据库的一些理解，而且希望也能够从实战的角度，更多的去解读数据库。

一、课程介绍

1.为什么选择这门课程？

今天的分享分为两大块，第一块就是课程介绍，第一个就是为什么选择这门课程，第二个是课程的安排，第二大块就是数据库系统概述，会介绍到数据库历史的发展，数据库系统分类以及数据库系统的概述。

刚才我们介绍了为什么举办这次从0到1实战数据库内核这门培训，但是从另外一个角度，其实也要需要回答一个问题，为什么推荐来学习数据库内核？我想答案是这样，如果是 DBA 出身的，从事 DBA 的相关工作，推荐大家去学数据库内核，第一个就是说，帮助大家更好的了解底层基础原理；第二点，当大家遇到问题的时候，可以紧急去救护，然后去寻找一些解决方案，知道问题点大概在什么地方。如果大家是学生或者是程序员的时候，我们也非常推荐大家来学习数，因为数据库是三大技术软件之一，三大基础软件包括操作系统、数据库，编译器。

这三大技术软件有一个特点，就是它的系统会非常的庞大，而且是一个面向对程序员非常友好的职业，因为它的系统会非常庞大，需要程序员不断的工作，工作中不断的沉淀，不断的积累，而且不会是像过去很多人说的，程序员是一个份吃青春饭的工作。其实不是，在数据库这个领域，资历越深就越具有优势，所以就是说数据库是一个职业生涯更好更长的工作。另外，最近国家大力的发展技术软件，解决卡磨损问题，相对而言，数据库也是一个非常热的领域，所以可以帮助大家更好的找到一份比较好的工作，这就是为什么推荐大家学习数据库内核的原因。

回答第二个问题，很多人会问 MySQL 有200万行的内核代码，OB 有大概400万行的数据库内核代码，Oracle有两千万行数据库内核代码，而且刚才又介绍了数据库是三大技术软件之一，会不会数据库入门太难？针对这个问题，其实也是今天举办这个培训最重要的目的，就是帮助更好更轻松的入门，而且在这里可以说数据库的入门比想象中要容易很多，而且在整个 OceanBase 数据库部门，其实有很多之前不是从事数据库相关研发工作的，也是来到 OceanBase 之后才开始数据研发工作。

在这里推荐两个系统来帮助大家更好的入门数据库，第一个是 MiniOB，第二个是 Sqlite，为什么会推荐这两个系统？当然还有很多的数据库系统，比如开源的 MySQL 或 grace，这些数据库系统要么非常的庞大，要么就是学习起来非常费力。而 MiniB 有一个最大的优势，就是它只有2万行的代码，它类似于Linux0.1，代码量非常少，适合学生去学习，而且它具备所有的模块的功能，就是大家如果学习这个 MinOB，基本上就可以知道数据库是怎么工作的，强烈推荐大家来学习 MiniOB。另外一个系统叫Sqlite，Sqlite是一个已经发展有十多年的数据库系统，而且是一个工业的数据库系统，所以它的质量，稳定性是达到一定程度的，它的代码量也非常小，大概是22万行代码，如果学习Sqlite就可以知道一个工业数据库大概的一个框架是多少，大概会有哪些功能，在哪些点上需要一些特别的处理。

在书籍上，我推荐两本，一本是数据库系统实现，另外一本是数据库系统概念，这两本书都是正统的数据库的课程，而且是国外非常经典的数据库课程的推荐书籍，推荐经常去看。

2.课程设计

回到整个从0到1实战数据库内核的课程设计上，分为两个阶段，第一个阶段是入门的课程，第二阶段是进阶的课程。入门的课程大概是三块，第一块是理论的课程，理论课程就相当于整个数据库实现这门课的理论教学；第二块是我们结合MiniOB会做一些实战的培训，然后在这些实战培训当中会有一些课后的作业，能够帮助更好的学习丰富，比如OceanBase大赛，推荐参加OceanBase大赛，另外一个是OceanBase训练营。OceanBase训练营就是，有很多OceanBase的题目，可以参与做这些题目来更好的巩固自己的学习。在进阶阶段，会做OceanBase的培训，会对源码进行分析、讲解。另外，会在Github上配套一些小任务来帮助大家更好的去理解和学习OceanBase，能够让大家真正的上手实操OceanBase。

3.《从0到1实战数据库内核》—入门级

从0到1实战数据库内核的入门课程理论篇，分为七个章节，数据库系统概述、数据库存储结构，数据库索引结构，数据库SQL引擎上、下，数据库事物引擎，数据库基础模块。在实战篇，我们会介绍MiniOB概述和编译环境搭建，MiniOB存储结构源码分析，如何实现Drop Table in MiniOB，MiniOBSQL引擎源码分析，如何实现自定义解析器in MiniOB以及MiniOB并发框架

在实战篇我们也有很多的培训和介绍，帮助大家更好的理解MiniOB，理解数据库的实现。

4.《从0到1实战数据库内核》—进阶级

在进阶阶段，大概有八个课程，第一个是OceanBase架构及目录结构，第二个是如何搭建OceanBase研发环境，第三个是OceanBase存储引擎介绍上，第四个是OceanBase存储引擎介绍下，第五个是OceanBase SQL优化器，第六是OceanBase SQL执行器，第七是OceanBase 内存和线程模型，第八个是OceanBase测试系统。大概整个进阶阶段的视频培训是七个小时。

二、数据库系统概述

回到数据库的系统概述章节，可能会从更多的实战模块来介绍整个数据库的系统概述，理论的部分推荐去看《数据库系统实现》这本书，然后这里会做一些讲解，大概分为三大块，第一个是数据库历史发展，第二个是数据库系统分类，第三个是数据库系统概述。

首先，在讲解数据库历史之前，必须先回答一个问题，就是在没有数据库时是怎么解决应用需求的？在20世纪60年代时，面对科学计算就必须要解决这个问题，第一个如何实现一个持久化，如何解决当故障出现时从故障中恢复，这是第一个问题。第二个问题是如何实现并发？第三个是如何定义数据的格式？第四是如何定义数据的访问接口？

在数据库还没有出来的时候，在文件系统已经差不多出来的时候，这一段时间就基本上是应用程序直接来操作底层的文件，它首先就是说来解决持久化，第一个就是利用文件系统将数据持久化，第二个问题就是自己去设计并发控式，第三个自己去设计故障恢复，怎么来解决出现故障时候将数据恢复出来，第四个是要自己定义文件格式和访问方式，设计数据的逻辑结构、设计数据、物理存储、物理结构、存储结构，还有存储方式，以及输入输出的方式等等，这所有的问题全部依赖应用程序来解决，也就是逻辑层、物理层，全部要应用层来解决，而且非常容易出问题，这是第一点。第二点，就是如果想做迁移，或者是说从一个系统挪到另外一个系统，或者是说做一些小的改动都会非常痛苦。如果从一个系统挪到另外一个系统内部，可能很多工作都需要做一些变更，所以是非常容易出问题的。

其实这个问题最大的根底在于它没有做一个很好的抽象，在所有的大型系统当中，尤其是数据库、操作系统甚至编辑器等等所有的系统当中，大型系统都需要思考一个问题，就是接口是什么，实现是什么？在数据库里面它的接口就是它的数据操作语言，数据要具备三个语言，第一个是定义语言，定义数据的格式，DDL;第二个是数据的查询语言，怎么查询这个数据,SQL;第三是数据操作语言怎么来操作？增删改查，DML。当接口层定义好了，那其实很多时候接口层就已经非常固化，然后就可以非常方便应用开发者根据这些接口层去进行数据的读取，这样它会脱离物理层，然后跟物理层做一个隔绝，这样方便应用程序可以从a系统迁移的b系统，而且就是说更多的关注自己的业务，而不是去关注一些底层的实现。站在实现的角度，第一个要实现接口层，也就是实现DDL，DML，SQL；第二点是要解决持久化，尤其是海量数据的时候；第三个是故障恢复能力，当出现问题时怎么从故障中恢复出来；第四个是并发控程和事务管理，具备隔理性和原则性。

这四个能力是《数据库实现》这本书上介绍的数据库需要具备的四个基础能力，如果不具备这四个基础能力，其实不能称之为数据库。

1.数据库历史发展

（1）早期数据库管理系统

层次模型、网状模型

缺点：没有高级查询语言、操作复杂

在早期的时候，出现了数据库的一些模型，数据库的管理系统，他们也能够支撑这个四个能力模型，比如最早60年代提出的层次模型，层次模型类似于今天的树状模型，也就是说任何一个节点会有一个副节点，除了它的根节点以外，任何一个节点都会有一个副节点。层次模型非常适合于关联的，就是类似于树状的这种查询，但是在离开树状查询之外，它的应用场景会非常的受局限。而网状模型，网状模型就是任何一个节点，它可能会有一个或多个副节点，并且一个节点可能也会有一个到多个的子节点，这就是网状模型。

但这两种模型其实在今天来看都没有最后成为主流，没有流行起来，其实他们出现的时间比关系模型更长，究其原因，有两个原因，第一个就是它整个描述世界的方式是非常受限的，比如像层次模型，它就仅仅适合于树状模型，而网状模型，仅仅适合于网状模型，它并不能描述一个更自由的模型。第二点，也是最痛的一点，它整个接口层际上是非常局限的，它无法提供一个很抽象的查询语言，对于业务方来说，怎么去操纵数据，这套接口当而是非常痛苦，它不够抽象、不够简单、不够容易学习，这也是它没有流行下来的最根本原因。

（2）关系数据库系统

1970年Edgar F. Codd的论文:

. A relational model for large shared data banks

. SQL(结构化查询语言)

·优点

建立在严格的数学概念的基础上,有理论基础

数据模型清晰--所有模型都使用关系来表示

接口非常清晰,逻辑层和物理层非常清晰的剥离

1970年Codd提出了一个关系论文，然后提出了A relational model for large shared data banks这篇论文，然后提出了关系模型，并且他还提出了一个结构化的查询语言，SQL，那这个模型有哪些优点？第一个就是它有理论基础，它的SQL，接口是建立在关系代数上，是有严格的数学逻辑，数学概念的，并且它是一个闭包，就是说关系模型可以相互转换，并且不会发生语义的丢失。第二点是数据模型非常的清晰，刚才介绍了所有模型都可以用关系来表示。第三点是它的接口非常清晰，它的逻辑层，物理层非常容易做一个切分；它的逻辑概念也是非常清晰的，用关系来说；另外物理层用关系模型存储下来也会非常的清晰，这也就是为什么关系模型最后成为数据库的主流的模式一直延续到今天，今天主流的数据库系统基本上是关系模式，当然还有一些其他的。

（3）NoSQL数据库

Bigtable. Bigtable: A Distributed Storage System for Structured Data (AwardedBest Paper!).OSDI 2006:205-218

NoSQL数据存储系统

·API访问

·不需要预定义模式

·分布式支持

·对象存储

NoSQL数据库其实是在2006年时候，Google提出的三架马车，就是其中一篇关于big table的论文介绍了这个NoSQL数据库。NoSQL数据库是用来解决过去传统老的数据库最大的一个问题，就是存储能量不能够线性扩张。然后这个时候NoSQL数据库，它提出了一个分布式的支持，数据可以无限的线性故障，这是第一个功功能点；第二个就是说，它的底层的结构不一定要求是关系模型，它主要是KB的模型，而且不需要是结构化的模型，就是不需要是预定义的模式；第三它可以支持对象存储，因为在KV里面非常容易实现对象存储；第四个是他为了更高效的存储，然后它提供API的一些访问机制。

（4）数据库领域的图灵奖

数据库：按照数据结构来组织、存储和管理数据库的仓库。

数据库领域基本上是整个计算机领域中拿到图灵奖最多的领域。

最早的Bachman，他是网状数据库的奠基人，在1973年拿到了图灵奖；刚才我们介绍的Edgar F. Codd，他在1979年提出关系模型，在1981年拿到了图灵奖；第三个是Jim Gray，他是提出了事务模型整套理论的大师，而且他基本上奠定了整个数据库的基础，在1998年拿到了图灵奖；第四位是Michael Stonebraker，Stonebraker对整个今天的数据库影响非常的显著，他有非常多的有代表性的数据库产品，其中包括Ingres，Ingres今天影响的非常多的数据库，比如postgres、informix。

（5）数据库简史

来看一下数据库的简史大概是怎样的，从1970年到2000年，这个时候还是一个单机数据库，并且是一个关系数据库，比如整个数据库的鼻祖，IBM System R，今天很多论文都受到了System R系统的影响，包括后面的ORACLE和IBM DB 2；第二个非常有影响力的是ORACLE，第三个是IBM DB 2；今天在开源界最流行的数据库叫MySQL，是1995年由Monty研发出来的。还有刚才提到的Microsoft SQL server，其实SQL server整个内核是非常powerful的，而且它在存储上是有非常多的见解和和创新性；最后一个是postgreSQL，历史也非常悠久，它取源于ingress，ingress在08年，09年时候还做了一个内存的数库，叫Berkeley DB。

到了2010年的时候，涌现了更多的关系型数据库、存储系统，有分布式的。另外一个很大的显著特征就是出现了大数据领域，然后出现了NoSQL、Google的三架马车，Google File System，MapReduce，还有Bigtable，基本上开启了大数据、分布式和NoSQL整个时代的序幕，然后从那之后整个开源界出现了海多果生态，而且海多果生态来实现Google的三驾马车。对应的就是海多果文件系统实现了MapReduce，Big table等等等等。另外在计算层，过去最早的是MapReduce，MapReduce坦白讲整个并行计算是非常落后的，因为非常落后，后面就出现了SAP，HANA能够将整个计算变得更加容易。与此同时也出现了Greenplum，还有Dynamo DB，redis，redis是一个KB的内存数据库，然后还有Mongodb，Mongodb在json上解决非常好。

2010年到现在，又出现了更多的数据库类型，有In-memory，NewSQL，HTAP，比如OceanBase可以认为是一个NewSQL的数据库，并且也是个HTAP库，包括Google Spanner。Google Spanner是一个非常典型的NewSQL数据库，而且是一个分布式的数据库，特别是偏向一个orTP的。另外是有一个非常著名的数据库系统，叫做Amazon Aurora，Aurora实际上是一个云上的系统，是一个特别适合云的数据库系统，它的上层实际是MySQL，下层是用他们自己修改了一些纯粹引擎以及结合了云存储，然后做了一个非常适合云特点的一个数据库，就特别适合于云上弹性的升降级，类似的有polar。另外，在SAP有一个HANA的数据库，HANA数据库是一个内存的数据库，它是所有的数据会放在内存中，并且可以支持orTP，也可以支持orap，而且有非常好的性能及兼入性去支持SAP的CRM系统等等等等，另外，还有TiDB和CockroachDB，TiDB最早的是借鉴Cockroach来发展的一个面向MYSQL生态的分布式系统。还有polar-X，polar-X是一个类似于基于分库分表的一个解决方案，最后对用户体验来说，是类似于一个分布式数据库的系统。

2.数据库架构

数据库大概分为三个部分，一个是SQL引擎，一个是存储引擎，另外一个是事务引擎，当数据库接受到一个SQL的时候，首先会经过parser，parser会先做词法分析和语法分析。词法分析，就是说将整个SQL拆成一个词，然后语法分析会根据语法规则生成一个语法树，然后将语法树会扔到query result cache，query result cache通常情况下是直接对SQL进行硬解析，因为SQL硬解析性能是最快的。如果发现命中，它马上就会返回结果给应用方，跳过下面所有的过程。

第三步会做resolver，resolver会对整个SQL语法树中的部分变量做一个替换，或者是做一些其他类似的操作，然后会生成一个语法树，这个语法树还不是真正最后的执行计划，只是一个语法树。这个语法树会扔到plan cache中做匹配，如果plan cache匹配命中，那plan cache会直接拿出它的物理执行计划扔到执行器中执行，真正运行起来。如果命中失败，会扔到优化器里，优化器里第一步会做transformer，通常优化器大概分为两个步骤，一个叫做逻辑优化，一个叫做物理优化，逻辑优化就是根据一些逻辑规则对整个语法树做一些优化，比如做一些计算下推projection，就不需要数据库在代价上做一些判断，优化。

另外，在Optimizer会做一些代价优化，就是根据一些代价去从众多的物理计划中选取一个相对优的执行计划。其实在工业界，逻辑优化跟物理计划优化并不是完全切分的，很多时候他们是掺杂在一起，就是揉在一起去做各种优化，能够不断的进行迭代来生成一个相对而言比较优的执行计划。这个地方特别要介绍是相对而言比较优的执行计划，因为，假设有七张表进行join，那生成的执行计划就可能有2的70方个后选执行计划，如果每一个执行计划都去计算他的代价，可能在优化阶段它会非常耗时。所以，站在业务的角度、优化器的角度，选择一个比较不是最优的执行计划，但是是一个相对比较优、可以计算非常迅速的一个执行计划。然后会汇总到执行器中，执行器里面可能会做Code generator， Code generator就是将多个算子加到一起，可能会生成一个更高效的算子，这样叫Code generator。

以上是在整个SQL层要做的一些事情，然后往下就进入了事务层和存储层。事务层跟存储层在真实的工业界中并不是切分的这么干净，很多时候是相互交错在一起。事务管理器里面基本上有几个部分，第一个是日志恢复，是所有的SQL在对磁盘进行操作的时候都会写一些日志，有物理日志、逻辑日志，并且会提供一些恢复功能。另外一点就是并发控制，怎来控制对数据的事务，并发控制有锁、mvcc。另外在存储层，会有Buffer Pool，不会直接从底层的磁盘中将数据捞出来，是经过Buffer Pool，Buffer Pool会去查询Catalog，然后从Catalog中拿到所有的源数据信息再去操作，发请求给存储管理器，存储管理器最后发送到存储，然后从存储中将数据拿取出来。

关系数据库=存储+事务+SQL

也就是说整个关系数据库大概分为三大块，一个是存储，一个是事物，一个是SQL。

存储：关系数据库的数据结构

事务：关系数据库的算法

SQL：关系数据库的描述语言

存储：关系数据库的数据结构

工业界中两种基础数据结构

哈希表：O（1），支持put/get,不支持范围scan

B+树：O（logn），支持put/get，也支持范围scan

数据库存储：面向磁盘设计的一颗B+树

事务:关系数据库的算法

转账: Alice给Bob转账，要么成功，要么失败，不允许出现Alice成功转出而Bob转入失败的情况

事务的ACID

·原子性(A）:事务操作要么全部成功,要么全部失败

·一致性（C):一个事务只能使数据库从一个一致的状态跳转到另一个一致的状态

·隔离性I):多个并发事务互相不影响，就如同多个事务串行执行一般

·持久性（D): 一旦事务成功提交，它对数据库的影响是永久的

SQL：关系数据库的操作语言

sql就相当于关系数据库的操作语言，它其实就是一层接口，而且一层基于关系代数的接口，是非常有理论基础。在数据库内容里，有专门一个模块，SQL引擎来实现这套接口。