一文读懂数据库发展史

本文力求以简单易懂的语言描述出数据库发展史，尽量避免出现复杂的概念介绍。数据库演进史如图1所示：

图1 数据库演进

一、穿孔纸带和文件系统

　　在现代意义的数据库出现之前(20世纪60年代)，人们通过人工和文件系统的方式来存储、管理数据。在人工管理时期，人们常使用穿孔纸带来管理数据（图2），虽然穿孔纸带因不具备电子化特征、不能被称为数据库，但其代表着人们在数据存储结构上思考和实践的结果，有必要单独提及。

图2 穿孔纸带

　　随着数据量的增多以及计算机技术、存储技术的快速发展，穿孔纸带这一纸质存储媒介很快就被磁盘、磁鼓（图3）等磁性存储设备所取代。在软件方面，操作系统中也出现了专门管理数据的软件，被称为文件系统（例如我们电脑里的C,D,E盘）。

　　文件系统可以说是最早的数据库了，操作系统提供的文件管理方法使得程序可以通过文件名来访问文件中的数据，不必再寻找数据的物理位置。相比较手工处理的方式，文件系统使得管理数据变得简单一些，使用者不需要再翻来覆去地查找文件的位置，但是文件内的数据仍然没有组织起来，程序员需要在脑海中尝试构造出数据与数据的关系，再编写代码才能从文件中提取关键数据。除过数据结构和数据关系不完整的问题外，此时的数据只面向某个应用或者某个程序，数据的共享性也有着一定的问题。

图3 磁鼓（长12英寸，每节可存储不到10k数据）

　　随着数据量的增长以及企业对数据共享的要求越来越高，人们开始提出数据库管理系统（Database Management System, DBMS）的概念，对数据模型展开了更深层次的思考。

二、数据模型

　　通俗地讲数据模型就是对现实世界的模拟，是对现实世界数据特征的抽象。这个抽象的过程并不是一蹴而就的，事物的抽象存在多个层次，需要用到不同的模型来进行描述。在前辈们的不断探索中，数据模型被划分为三个层次，第一个层次为概念模型（又称信息模型）；第二层次为逻辑模型；第三层次为物理模型。

　　概念模型中就是从现实世界中抽取出事物、事物特征、事物间的联系等信息，并通过概念精确地加以描述。在这个层次进行数据建模时，有一些概念必须要知道，分别是实体、属性和联系。在现实世界中客观存在的事物或事件被称为实体，例如一只羊，一名学生，一张单据，甚至一份“用餐记录”等。实体具有的某方面特性叫做属性，例如学生的属性有姓名、年龄等。现实世界中事物彼此的联系在概念模型中反映为实体之间的联系。联系有以下几种（图4）

图4 实体间联系

逻辑模型是按照计算机系统的观点对数据进行建模，用于DBMS的实现。而物理模型则用于描述数据在磁盘或系统中的表示方式和存取方法。

三、层次模型与网络模型

　　通用电气的工程师CharlesW.Bachman领导开发了全球第一个数据库管理系统-网状数据库管理系统（IDS），并于1964年正式推出。IDS采用网状结构，很好地模拟了现实世界中事物间的多种联系。

网状结构有多种表现形式（图5）

图5 网状结构表现形式举例

为便于读者理解，举一个例子加以说明

图6 教务系统网状结构

　　同时期为解决“阿波罗登月”计划处理庞大数据量的需求，北美航空公司(NAA)开发出 GUAM(Generalized Update Access Method)软件。其设计思想是将多个小组件构成较大组件，最终组成完整产品。这是一种倒置树的结构，也被称之为层次结构，层次结构仅能表示一对多的关系。随后IBM加入NAA，将 GUAM 发展成为 IMS(Information Management System)系统并发布于1968年。

为便于读者理解，举一个例子加以说明（图7、8）。

图7 “系-教研室/学生教职工”层次数据库模型

图8 “系-教研室/学生教职工”层次数据库模型的一个值

　　相比较于文件系统来说，层次数据库和网状数据库实现了数据和程序的分离，但是缺乏理论基础，而且也不方便使用。原因在于使用者在查找一个数据时，总要先在脑海中构建出当前的层次结构或网络结构，接着才能按照从属关系编码再查找。若在一个系统中有上千个实体的话，这就是人力所不能及的了。

四、关系模型的发展及完善

　　1970年， IBM 实验室的Edgar Frank Codd 发表了一篇题为《大型共享数据库数据的关系模型》论文，提出基于集合论和谓词逻辑的关系模型，为关系型数据库技术奠定了理论基础。关系模型最大的创新点是拆掉了表与表之间的联系，将这种关系只存储在表中的一个字段中，从而实现了表与表之间的独立（图9）。

图9 “系-教研室/学生教职工”关系数据库模型

　　若采用关系结构对上述的“系-教研室/学生-教职工”进行建模，建成的模型将会成为这样。例如在提取教研室的数据时，碰到系编号这个字段，就会自然而然地连接到系的具体数据中。

　　当时Codd提出这个模型后，受限于当时的硬件条件，这个模型遭到了很多批评，人们认为这种模型是难以实现的。正如上述这个例子，当在检索教研室这个表的数据时，碰到系编号这个字段时就需要再去遍历一遍这张表的数据，这种提取数据的方式让当时的机器难以承受。但是在摩尔定律的加持下，这些问题迎刃而解，这种建立在严格数学概念上的关系模型很快就得到了学术界和工业界的青睐。

　　从数据关系理论到架构一个真实的关系数据库系统之间还有很长的一段路要走，在这个过程中，有很多公司、学者都贡献出了自己的成果，共同推动着数据库领域的发展。1973年，IBM启动了验证关系型数据库系统的项目System R，同年伯克利大学的Michael Stonebraker等人启动了关系数据的研究项目 Ingres（interactive graphics andretrieval system）。

　　1974 年，Ingres 诞生，为后续大量基于其源码开发的PostgreSQL、Sybase、Informix 、Tandem和Sql Server等著名产品打下坚实基础。1976年，P.P.Chen提出了实体-联系模型（简称E-R模型），这种模型常被用来描述、抽象概念数据模型（详细解释可阅读这篇文章https://zhuanlan.zhihu.com/p/356216273）。
　　1979年，Oracle诞生，从诞生之日起，Oracle就一直是数据库领域处于领先的产品。1983年，经过长达十年的开发与测试，IBM发布了Database2，这标志着DB2的正式诞生。

　　1985年，为存储、表达更为复杂的数据结构（例如嵌套表、非结构化数据等），人们提出了面向对象的数据模型，这种模型吸收了层次、网状和关系数据库等各类数据模型的特点，并借鉴了面向对象的设计方法。面向对象的数据模型将所有事物都看作是一个对象，每个对象的定义包括状态和行为两个方面，其中状态由一组属性组成，行为由一组方法组成，具有相同属性和方法的对象构成一个对象类。（详细解释可阅读这篇文章https://blog.51cto.com/nu1l/2834178）

　　虽然面向对象的数据模型很早就被提出来了，但是真正结果还得等到20多年之后，在当时来说，仍然还是关系型数据库的天下。1986 年，美国国家标准局(ANSI)数据库委员会批准SQL作为数据库语言的美国标准并公布标准 SQL 文本。1987 年，国际标准化组织(ISO)也做出了同样决定，对 SQL 进行标准化规范并不断更新，使得 SQL 成为关系型数据库的主流语言。此后相当长的一段时间内，不论是微机、小型机还是大型机，不论是哪种数据库系统，都采用SQL 作为数据存取语言，各个公司纷纷推出各自支持SQL的软件或接口。

　　1988年SQL Server诞生。微软、Sybase等公司合作，在Sybase的基础上生产出了在OS/2操作系统上使用的SQL Server 1.0。各大公司在关系数据库管理系统(RDBMS)的实现和产品开发中，都遇到了一系列技术问题，主要是在数据库的规模愈来愈大，数据库的结构愈来愈复杂，又有愈来愈多的用户共享数据库的情况下，如何保障数据的完整性(Integrity)、安全性(Security)、并行性(Concurrency)，以及一旦出现故障后，数据库如何实现从故障中恢复(Recovery)。这些问题如果不能圆满解决，无论哪个公司的数据库产品都无法进入实用阶段，最终不能被用户所接受。

　　在当时争论纷繁的数据库学术大战中，Jim Gray将数据库研究转向底层，同时思考各种数据库都面临的并发和故障恢复等基本问题。最终，Jim Gray理清了事务的基本概念以及开创性的提出了目前数据库事务处理机制的基础ACID属性，并且给出来许多具体的实现机制，他的研究成果反映在他发表的一系列论文和研究报告之中，最后结晶为一部厚厚的专著《Transaction Processing：Concepts andTechniques》。这不仅为数据库事务处理的发展奠定了夯实的基础，而且确保了现今电子化的商业和金融系统的可靠运行。

事务处理

五、数据库能力的拓展

　　随着关系型数据库的发展以及不同业务场景的数字化，人们逐渐产生通过数据监控业务发展，并通过数据分析来辅助业务发展的想法。在此想法之上，1988年，数据仓库的概念被正式提出。数据仓库是一个面向主题的、集成的、非易失的、随时间变化的用来支持管理人员决策的数据集合。

　　单从概念来说，很难理解数据仓库究竟是一个什么东西。举个例子，一个企业不同业务的数据存放在不同的数据库中，若没有数据仓库这个产品，数据分析师或业务分析人员就必须从各个业务数据库中拉取自己所需要的数据，而各个数据库的命名规则、存取规则、格式可能都各不相同，这就造成业务分析人员必须做大量工作来整理自己所需要的数据，而且这一结果不能被复用，需要做大量重复的工作。数据仓库就解决了这些问题。

　　尽管当时的人们已经有了数据仓库的概念，但是对于数据仓库的实现方式，一直争论不休。直到1991年Bill Inmon出版了《Buildingthe Data Warehouse》（建立数据仓库）这本书，数据仓库实现方法的争论才告一段落。在这本书中，Inmon不仅对数据仓库提出了更精确的定义- 数据仓库是在企业管理和决策中面向主题的、集成的、与时间相关的、不可修改的数据集合，而且提出了范式建模的数据仓库建设方法。尽管后来范式建模受到了维度建模的挑战（可以详见这篇文章：
https://segmentfault.com/a/1190000006255954），但因Inmon的巨大影响力，他被尊称为“数据仓库之父”。

构建数据仓库

　　在有了数据仓库概念和具体实现方法后，人们尝试在此基础上做数据分析，但在分析过程中，人们发现使用关系数据库对多维数据进行分析时效率非常低。原因在于关系数据库并不是专为数据分析而打造的，要想提升分析效率，人们还需要一个支持多维数据的处理引擎。1993年，关系型数据库创始人Edgar F. Codd提出联机分析处理（OLAP）的概念，目标是为了满足决策支持、报表展示以及多维数据查询的需求。

六、开源成果涌现

　　到目前为止，数据库只覆盖了少数业务领域，数据库使用者局限在大型商超、金融机构、学术研究机构等业务机构中。且当时的数据库也被IBM、Oracle等公司垄断着，数据库仍然是一个比较小众的软件。但在同一时期互联网开始进入了寻常百姓家，互联网行业迎来了快速发展，涌现出了大量的网页、网站和互联网公司。人们需要数据库来存储网页的相关数据，但当时的商业数据库又太贵或者因查询性能不足而无法满足人们的需求，Stonebraker等人的努力在此时开枝散叶，由于他将Ingres的源码公布在网上，教会了很多人如何架构数据库，从而在一定程度上促进了当时数据库开源运动的兴起，其中最著名的两个成果就是1996年发布的MySQL和PostgreSQL。

PostgreSQL与MySQL

七、NoSQL（Not Only SQL）时代

　　而随着互联网和移动互联网的蓬勃发展，接入互联网的用户逐渐增多，用户的需求越来越多以及数据的不断提升，传统单机关系型数据库已经无法满足人们的需求了。人们在数据库领域开始寻求新的出路，其中有两个值得提起的分支，一个分支是探索多种数据模型和存储介质的数据库，早期比较有影响力的项目是Memcached，这个项目采用了键值模型来建立数据模型；另外一个分支就是分布式数据库，人们希望用多台机器形成集群来存储、处理数据，其中最具影响力和代表性的事件是Google于2003年至2006年发布的三篇论文，分别是Google File System、Google Big table和Google MapReduce，奠定了分布式数据系统基础。

三驾马车

　　由于传统基于集中式数据库在应对海量数据及复杂分析处理时，存在数据库的横向扩展能力受限、数据存储和计算能力受限、不能满足业务瞬时高峰的性能等根本性的架构问题。利用分布式计算和内存计算等新技术设计的分布式数据库能够解决上述遇到的性能不足等问题。分布式数据库的数据分散在网络上多个互联的节点上，数据量、写入读取的负载均衡分散到多个单机中，集群中某个节点故障时整个集群仍然能继续工作，数据通过分片、复制、分区等方式实现分布存储。

　　2007年，Hbase诞生，其理论基础正是Google在2006年所提出的Big table。它是以分布式存储作为基础的数据库，底层存储基于分布式文件系统具备了分片或者分区存储的能力，扩大了普通存储设备的存储系统的上限。同年Amazon发表了Dynamo论文，这篇论文第一次在非关系型数据库领域引入了数据库的底层特性，奠定了后续NoSQL数据库领域的部分基础特性。

　　2008年9 月，美国《自然》（Nature）杂志专刊——The next google,第一次正式提出“大数据”概念。这个概念的真正意义在于，数据被认为是人类认知世界的一种新型方法，人们可以通过数据来了解、探索、观察、研究世界。

　　关系型数据库不能较好地处理高并发读写、多结构化数据存储等情景。为应对这一问题，数据库供应商和开源社区都提出了各种解决方案，例如通过分库、分表、加缓存等方式来提升性能，但底层的关系设计仍然是性能天花板的根本原因。此时NoSQL数据库应运而生，它扩展了诸多数据模型，在不同场景下使用不同的数据模型来进行处理。其代表成果是2009推出的文档数据库Mongdb、2010年推出的键值数据库Redis和2010年推出的图数据库Neo4j。这类NoSQL数据库极大地扩展了人们存储、使用数据的方式。

八、NewSQL时代

　　这种NoSQL数据库虽然解决了高并发读写、多结构化数据存储等问题，但其设计思路是牺牲事务处理、一致性以及牺牲SQL换来的。而SQL、事务的重要性让人们开始反思怎么样才能在解决前述问题的基础上保留SQL和事务的能力。Google 于2012年发布了Spanner的论文，这篇文章创新性地提出了TrueTime的概念，它在第一代 NoSQL 系统的基础之上引入了 SQL 和分布式事务，保证了强一致性。（也正是这篇论文，宣布了NoSQL时代的结束，数据库发展来到了NewSQL的阶段）

　　这篇文章在工业界和学术界都有着巨大的反响，截止2022年4月，对其开源实现最好的产品是于2015年诞生的CockroachDB和TiDB（可阅读
https://www.zhihu.com/question/60686555/answer/1531192635）。和Spanner及它的追随者不同的是，Amazon在面对这一问题时，选择了完全不同的路径，Amazon 发布的Aurora 是一个存储计算分离的系统，运行在公有云之上，它的设计思想很巧妙，它把存储与计算分离使得可以非常简单得实现存储能力的可扩展。并于2017年在SIGMOD上发表了《Amazon Aurora: Design Considerations for High Throughput Cloud-NativeRelational Databases》这篇论文，披露了Aurora的一些技术实现细节。

九、未来展望

　　大数据时代，数据量不断爆炸式增长，数据存储结构也越来越灵活多样，日益变革的新兴业务需求催生数据库及应用系统的存在形式愈发丰富，这些变化均对数据库的各类能力不断提出挑战，推动数据库的不断演进。总的来说可能会有四个方向，第一个方向是垂直领域的数据库，例如工业数据库、财经数据库等。

　　截止目前为止，数据库都是“通才“，企图囊括所有领域，而并非深耕某一垂直领域。第二个方向是分布式数据库，通过“分布式”解决水平扩展性与容灾高可用两个问题，并且有融合OLAP的潜力。第三个方向是云原生数据库，云原生数据库能够随时随地从前端访问，提供云服务的计算节点，并且能够灵活及时调动资源进行扩容，助力企业降本增效。以亚马逊AWS、阿里云、Snowflake等为代表的企业，开创了云原生数据库时代。第四个方向是数据安全领域，在如今这样一个什么都可以量化的年代，数据是很多企业的生命线，而第三方服务商并非真正中立，谁愿意自己的命根被掌握在别人手里呢？在未来，隐私计算和区块链技术可能会帮助数据库发展得更好，共同解决数据安全的问题。

参考文献：

[1]中国信息通信研究院，数据库发展研究报告（2021 年）

[2]Spanner: Google’s Globally-DistributedDatabase

[3]Amazon Aurora: Design Considerations for High Throughput Cloud-NativeRelational Databases

[4]中国人民大学信息学院，数据库系统概论

[5]Google File System、Google Bigtable 和 Google MapReduce

[6]吴鹤龄.关系数据库的标准语言——SQL[J].计算机研究与发展,1989(06):7

 

注：

欢迎转载，但请在文章末尾或文章开头注明来源