代码家：简明数据库史

Posted 2021-08-21 思否编辑部

本文作者：代码家，资深开发者，热衷于开源社区，GitHub 20K 的 Star，15K 的 Follower；数字货币信奉者，热爱二级市场交易（股票+数字货币）；目前在真格基金做投资。

如果你想与代码家交流，可以加他的微信：daimajia（著名来源和身份），如果你在创业，或者有想法创业，也欢迎投递 BP 或者和代码家邮件交流： [e-mail]

在工业时代，煤炭和钢铁的使用量是一个国家发达程度的指标。而到了信息时代，数据量将是新的发达程度指标，几乎所有行业竞争本质上都是数据的竞争。支撑数据增长的背后，是一代又一代不断演化的数据库引擎，在真格基金的投资工作中，不断的开始有中国团队尝试挑战数据库领域海外的垄断地位，打造新一代的数据库引擎。业余时间，对整个数据库发展史做了个简单的总结。

整个数据库大致经历了四个发展阶段。

第一阶段：非关系型数据库

在现代意义的数据库出来之前（20 世纪 60 年代），文件系统（File system）可以说是最早的数据库，程序员们读取文本文件，并通过代码提取文件中的关键数据，在脑海中尝试构造数据与数据之间的关系。当年能流行起来的编程语言，往往都有很强的文件和数据处理能力（比如 Perl 语言）。随着数据量的增长，数据维度的多元化，以及对于数据可信和数据安全的要求不断提升，简单的将数据存储在 txt 文本中，成为极其具有挑战的事情。

随后，人们开始提出数据库管理系统（Database Management System, DBMS）的概念。数据库的演进抽象来看是人们对 数据结构 和 数据关系 这两个维度展开的思考和优化。

层次模型和网络模型（1960）

第一阶段的数据库模型（Database model) 是层次模型（Hierarchical Databases）。

图 1：一个表达学校结构的层次模型数据库

层次模型是最早的数据库模型。随着早期 IBM 大型机逐渐推广开来。这个模型相对于文本文件管理数据，是个巨大的提升，但也有很多问题。

问题：

• 尽管能比较好的表达 一对一 ( one to one) 结构，但在 多对多（many to many) 结构上难以表达

  • 如：图中能较好的表达一个系有多个老师，但很难表达一个老师可能属于多个系。

• 层次结构不够灵活

  • 如：添加一个新的数据库关系有可能对整个数据库结构带来巨大变化，以至于在真正的开发中带来巨大的工作量
• 查询数据需要脑海中随时有最新的结构图，且需要遍历树状结构做推导

而后在层次模型的基础之上，人们提出了优化方案，即：网络模型（Network Model)。

图 2：网状模型的数据库

网络模型是关系型数据库出来之前最为流行的数据库模型。很好的解决了数据的多对多的问题。但依然存在以下问题：

问题：

• 难以从代码层面实现和维护
• 查询数据需要脑海中随时有最新的结构图

第二阶段：关系型数据库

模型初期（1970）

关系模型（ Relational Model) 是相对网络模型的巨大飞跃。在网络模型中，不同类型的数据总是会依赖另一类数据，如图 1 中，Teachers 从属于 Departments，这是层次模型和网络模型在真实设计和开发中痛苦的根源（因为你总是要在脑海中记录当前的网络结构，想象一下一个拥有几千张表的复杂系统）

关系模型一大创新就是拆掉了表和表之间的链接，将关系只存储在当前表中的某一个字段中（fields），从而实现不同的表之间的相对独立。如下表：当你只看 Table2 的时候，你就知道 Product_code 会指向一个 产品的具体细节，Table2 和 Table1 在保持相对独立的同时，又自然而然的连接了起来。

图 3：关系型数据库
Table2 中的 Product_code 列指向了 Table1 中对应的数据，从而建立 Table2 和 Table1 的关系

1970年，当 E.F.Codd 开发出这个模型时，人们认为是难以实现的，正如上面的例子一般，当你检索 Table2 时，遇到 Product_code 列，就需要再去 Table1 遍历一遍。受限于当时的硬件条件，这种检索方法总是会让机器难以负载。但很快，大家质疑的问题，在摩尔定律加持下，已经不再是问题。大家如今所听说的 IBM DB2, Ingres, Sybase, Oracle, Informix, mysql 就是诞生在这个时代。

至此数据库领域诞生了一个大的分类：联机事务处理 OLTP（on-line transaction processing），代指一类专门用于日常事务的数据库，如银行交易用的增删改查数据库。后面还会提到另一类数据库，专门用于从大量数据中发现决策的辅助数据库 On-Line Analytical Processing – OLAP（联机分析处理）数据库。

数据仓库（1980s）

随着关系型数据库的发展，不同业务场景数据化，人们开始有了汇集不同业务场景数据，并尝试进行数据分析并辅助业务决策的想法（Decision Support System)。在此需求之上，诞生了数据仓库（ Data warehouse）的概念。

如下图：一个企业往往把不同的业务场景数据存在不同的数据库中，在没有成熟的数据仓库产品之前，数据分析师往往需要自己做大量的前期准备工作来汇集自己所需的数据。而数据仓库本质上就是解决数据分析和挖掘的业务场景。

图 4：数据仓库

解释：ETL 是 Extract(提取)，Transform(转换)，Load（加载）的缩写。因为数据在不同的数据库或者系统中，可能存在格式不统一，单位不统一等等情况。需要做一次数据的预处理。

数据仓库是一个面向主题的、集成的、非易失的、随时间变化的用来支持管理人员决策数据集合。

OLAP（联机分析处理）

1980 年代有了数据仓库的概念和实现后，人们尝试在此基础上做数据分析。但分析的过程出现一些新的问题。最明显的是效率问题。因为之前的关系型数据库并不是为数据分析而打造。数据分析师想要的是一个支持多维的数据视图和多维数据操作的引擎。

如下面