浅析数据库的进化史,看似简单的轮回

原创
数据库
数据库在变迁,这个变迁你是否注意到了呢?你是否跟着这个变迁的轨迹前进呢?有人说数据库的变迁就像是一个轮回,你信吗?你又是怎么看待这个变迁的呢?

数据库在变迁,这个变迁你是否注意到了呢?你是否跟着这个变迁的轨迹前进呢?有人说数据库的变迁就像是一个轮回,你信吗?你又是怎么看待这个变迁的呢?

一、总体说说数据库

从数据管理与应用逻辑的角度来讲,“File”时期的数据管理和应用逻辑是混在一起的,数据的管理完全由应用本身来完成;再来看关系型数据库的时期,在这个时期数据管理和应用逻辑实现了分离,应用可以不关心数据的管理工作,甚至有一部分逻辑都可以放到数据库中来实现;而如果我们再看一下NoSQL时期,数据的存储方式大部分都是Key/Value方式,在这种方式之下,应用又要关心数据的管理了,因为很多NoSQL没有像关系型数据那样强大的SQL查询功能。

二、过去的数据库

数据库过去是什么样子的?让我们一起来回顾一下吧!在数据库技术诞生之前,数据主要是以File形式存储的,数据的管理也是由具体的应用自身来完成的,所以这个时期的数据管理和应用逻辑是混在一起的。

直到40年前***代数据库技术的诞生,才实现了数据管理与应用逻辑的分离,采用层次结构来描述数据,我们称之为层次型数据库(IMS)。

至于我们常说RDBMS,其实是第二代数据库技术,上世纪70年代,来自IBM的E.F Codd博士提出的关系型理论以及SQL语言的发明。实现了数据建模和数据操作处理的标准化,关系型数据库在其后的20多年的时间取得了长足的发展,得到了广泛的应用,关系型数据库似乎已经成为了一种宗教式的信仰,数据相关的所有理论问题似乎都已经解决。

三、面对新的挑战

历史的发展总是在我们不经意间产生转折,所有重大技术的产生及发展都有其生存的土壤。在过去的20多年里,IT领域发生了重大的变化和一系列技术及理念的创新。数据库所生存的外部土壤随着Internet以及Web2.0甚至是Web3.0技术的发展,对结构化数据存储与管理技术提出了新的挑战。

首先,数据的复杂性和灵活性(Complicated &Flexible );

其次,高性能的并发读写(High Performance);

再次,海量数据的高效率存储和访问(Huge Storage);

***,高可扩展性(High Scalability)。

四、它有点儿吃不消

面对以上挑战,关系数据库的很多优秀特性却往往无用武之地,甚至成为一种负担。

比如,关系数据库严格的数据定义与数据的复杂性和灵活性产生了激烈的对抗,关系数据库的核心E-R模型本质上是一个二维的模型,通过一系列二维关系的组合来描述复杂实体对象,每个表所代表的所有实体在建模设计时没有差异性,即使只有一个实体拥有某种属性,也必须为其建立一个字段。因而在很多系统中,我们经常可以看到一张表有数百个字段,而对于每条记录,大多数字段都是空的。

同时,随着IT系统进入社会生活的各个方面,信息不仅日益复杂,而且其需求内容和结构随着时间的推移也不断地产生变化.现实世界要求信息技术具有越来越高的灵活性和适应性.关系型数据理论所采用的是一种固定的建模方式,任何关系和属性一旦定义,就是固定的,难以随着需求的变化进行灵活的调整。

在高性能的并发读写方面,关系型数据库良好的事务一致性使得它很满足理高性能的并发读写需求,实际情况是对于大部分的Web应用并不要求严格的数据库事务,对读一致性的要求很低,有些场合对写一致性要求也不高。因此数据库事务管理反而成了数据库高负载下一个沉重的负担。

至于海量数据存储高效存储和访问,随着像Facebook,twitter,Friendfeed这类的SNS网站的诞生与发展,数据的增长是爆发式的,以Friendfeed为例,一个月就达到了2.5亿条用户动态,对于关系数据库来说,在一张2.5亿条记录的表里面进行SQL查询,效率是极其低下乃至不可忍受的。为了解决这个问题Friendfeed采用了schema-less的方式来解决问题,由此可见对于海量数据的高效存数和访问,如果继续以传统的关系型数据库的方式来管理数据是行不通的。

对于高可扩展性这两个方面在基于web的架构当中,数据库是最难进行横向扩展的,当一个应用系统的用户量和访问量与日俱增的时候,你的数据库却没有办法像web server那样简单的通过添加更多的硬件和服务节点来扩展性能和负载能力。对于很多需要提供24小时不间断服务的网站来说,对数据库系统进行升级和扩展是非常痛苦的事情,往往需要停机维护和数据迁移,而对于NoSQL类型的数据库这种扩展和迁移的成本却低很多。

五、它能担重任吗?

对于未来结构化数据存储技术的发展来说,NoSQL能否担当大任现在还不好说,但未来“On Fits All”方式的关系型数据库技术会越来越捉襟见肘,针对于大型Web应用的定制化的存储方案会越来越多的被采用,而在这些方案中NoSQL一定有它的用武之地,且让我们拭目以待。

六、这不是一个简单的轮回

在了解了大量的数据库发展演变之后,不知道大家是否发现一个有趣的规律,从File→RDBMS,再从RDBMS→NoSQL,就像是转了一个圈,仿若转到了起点,仿佛回到了初始之处。难道退化了吗?答案,当然是No,下面我们请我们的老师——新浪乐居的蒋宗君先生为我们一一道来。

“技术的发展会有一个周而复始,循环往复的过程,但绝不会是简简单单的画一个圈,这只是一个应用开发回归到关注数据存储与管理的一个过程,我们都知道‘数据结构+算法=程序’,未来工程师可能要对数据结构投入更多的关注,我认为这是一个‘认祖归宗,回归本源’的过程,从这个层面来考虑应用的开发和架构。我认为这不是一种退步,而是一个理性回归的过程,是一种进步,因为我们更接近了应用开发的本质。”

当记者问道,老师一直在说这是一个轮回,那么,这是一个什么样子的轮回时,蒋老师为我们解惑曰:“首先,我们要了解结构化数据存储的过程。关于这个过程,我的理解是经历过几个时期,***个时期我称之为数据库技术的史前时期,我们姑且以“File”时期来描述,第二个时期是数据库技术尤其是关系型数据库大行其道时期,而第三个时期我认为正在发展中,现在看来可能还没有成型,可能还只是一个趋势,而NoSQL我认为可算是站在这个大的趋势之上的‘弄潮儿’。所以在我看来结构化数据的存储经历了一个从“数据管理和应用逻辑混在一起”到“数据管理与应用逻辑分离”再到“应用逻辑需要重新关心数据的管理”这一样一个轮回,这不是一个具体的轮回,而是一个关于数据存储与管理的理念的轮回,当然更不会是一个简单的轮回。”

它看似简单,实则蕴含大门道......

它看似上升,又仿佛回到原点......

它看似回归,实则进步上升......

【编辑推荐】

  1. 自己动手丰衣足食,DIY SQL字符串分解函数Split
  2. Java开源NoSQL数据库大全
  3. 简单说说SQL Server上的加密术
  4. 说说SQL Server编年史
责任编辑:艾婧 来源: 51CTO
相关推荐

2018-03-23 12:20:25

数据中心网络数据

2018-08-22 17:58:01

数据平台数据仓库架构

2011-12-21 16:44:00

信息图手机进化史

2018-12-21 11:01:05

存储大数据RAID

2010-10-09 14:46:20

2013-06-24 09:18:05

2014-09-01 16:29:34

2011-09-01 09:34:21

架构

2010-07-27 14:04:52

2011-11-29 09:54:20

Google进化史

2011-11-03 15:25:07

Android

2016-02-04 09:17:59

2023-11-27 09:23:19

2022-03-25 14:01:20

元宇宙虚拟世界进化

2022-03-29 09:35:15

FirefoxUI浏览器

2010-04-07 14:54:20

Unix操作系统

2018-08-23 09:33:12

2021-04-08 09:14:24

js前端函数

2010-01-21 16:08:26

C++语言

2019-06-19 15:54:12

Redis缓存内存
点赞
收藏

51CTO技术栈公众号