当前位置:文档之家› 关系型与非关系型数据库(1)

关系型与非关系型数据库(1)

关系型与非关系型数据库(1)胡经国本文作者的话本文是根据有关文献和资料编写的《漫话云计算》系列文稿之一。

以此作为云计算学习笔录,供云计算业外读者进一步学习和研究参考。

希望能够得到大家的指教和喜欢!下面是正文一、云计算时代对数据库技术的新需求随着云计算时代的到来,各种类型的互联网应用层出不穷,对数据模型、分布式架构、数据存储等数据库相关技术指标提出了新的要求。

虽然传统的关系型数据库已在数据存储方面占据了不可动摇的地位,但是由于其天生的限制,已经越来越无法满足云计算时代对数据扩展、读写速度、支撑容量以及建设和运营成本的要求。

云计算时代对数据库技术提出了新的需求,主要表现在以下几个方面:⑴、海量数据处理对类似搜索引擎和电信运营商级的经营分析系统这样大型的应用而言,需要能够处理PB级的数据,同时需要应对百万级流量。

⑵、大规模集群管理大规模集群管理使分布式应用可以更加简单地部署、应用和管理。

⑶、低延迟读写速度快速的响应速度能够极大地提高用户的满意度。

⑷、建设及运营成本云计算应用的基本要求是希望在硬件成本、软件成本以及人力成本方面都有大幅度的降低。

链接:互联网应用互联网应用是指搜索引擎、聊天室和讨论组以及实用软件(公用软件、共享软件、自由软件)等。

宽带上网催生了一系列新的互联网应用,比较流行的如网络游戏、博客、微博、播客、互联网电视、互联网金融、流媒体(边传边播的媒体)、即时通信(如QQ)、网络电话(Voip)、电子商务等等。

链接:数据扩展数据扩展是由一组连续的数据块构成的,是数据库逻辑存储分配单位。

而数据表的数据段则是由一个或多个数据扩展构成。

当一个数据段己有空间用完时,关系数据库管理系统(Oracle)自动为这个数据段分配新的数据扩展。

当用户创建数据表时,Oracle为此数据表的数据段分配一个包含若干数据块的初始数据扩展。

虽然此时数据表中还没有数据,但是在此初始数据扩展中的数据块己经为插入新数据做好了准备。

如果一个数据段的初始数据扩展的数据块都己装满,而且有新的数据要插入时,Oracle会自动为这个数据段分配一个增量数据扩展。

链接:集群(Cluster)技术集群(Cluster)技术定义为:一组相互独立的服务器在网络中表现为单一的系统,并以单一系统的模式加以管理。

该单一系统为客户工作站提供高可靠性的服务。

在大多数模式下,集群中所有的计算机拥有一个共同的名称,在集群内任一系统上运行的服务可以被所有的网络客户所使用。

Cluster必须可以协调管理各分离的组件的错误和失败,并可透明地向Cluster中加入组件。

一个Cluster包含多台(至少二台)拥有共享数据存储空间的服务器。

任何一台服务器运行一个应用时,应用数据被存储在共享的数据空间内。

每台服务器的操作系统和应用程序文件存储在其各自的本地储存空间内。

Cluster内各节点服务器通过一个内部局域网相互通信。

当一台节点服务器发生故障时,这台服务器上所运行的应用程序将在另一节点服务器上被自动接管。

当一个应用服务发生故障时,应用服务将被重新启动或被另一台服务器接管。

当以上的任一故障发生时,客户都将能够很快地连接到新的应用服务上。

链接:分布式应用分布式应用(Distributed Application,DA),是指应用程序分布在不同计算机上,通过网络来共同完成一项任务的工作方式。

链接:低延迟延迟是一个现代词语,意思是推迟到较后的时间。

低延迟的需求,很大程度上来自于证券市场上高频交易比例的迅猛增长。

在证券产品可以在多家交易所进行交易的情况下,能够更快处理订单、更快反馈行情的交易所,显然更能吸引采用高频交易策略的机构投资者。

例如,2010年,纳斯达克(NASDAQ)应用INET(电子交易平台技术)处理延迟小于250微秒,每秒可处理100万笔订单,是当时世界上处理速度最快的交易所。

二、关系型数据库SQL1、关系型数据库概述关系型数据库是建立在数据关系模型基础上的数据库。

关系模型是指二维表格模型。

因而,一个关系型数据库就是由二维表及其之间的联系组成的一个数据组织。

关系模型由关系数据结构、关系操作集合、关系完整性约束三部分组成。

在现实世界中,各种实体以及实体之间的各种联系均用关系模型来表示。

现如今,虽然对关系模型有一些批评意见,但是它还是数据存储的传统标准。

SQL(Structured Query Language,结构化查询语言),是一种标准数据查询语言,一种通用的、功能极强的关系型数据库语言,同时也是数据库脚本文件的扩展名。

SQL是一种数据库查询和程序设计语言,执行对关系型数据库中数据的检索和操作,用于存取数据以及查询、更新和管理关系型数据库系统。

它是1974年由Boyce和Chamberlin提出的一种介于关系代数与关系演算之间的结构化查询语言。

当前,主流的关系型数据库有Oracle、DB2、Postgre SQL、Microsoft SQL Server、Microsoft Access、MySQL、浪潮K-DB等。

2、关系型数据库数据表关系型数据库的数据表,是以行和列的形式组织起来的数据集合。

一个数据库包括一个或多个数据表。

例如,可能有一个有关作者信息的名为authors 的数据表。

每列都包含有关特定作者的一类信息,如作者的姓氏;每行都包含有关特定作者的所有信息:姓名、住址等等。

在关系型数据库当中一个数据表就是一个关系,一个关系数据库可以包含多个数据表。

3、关系型数据库的特点和问题关系型数据库成为主流技术已经超过20年。

这是有它的道理的。

它把数据存储在磁盘中,人们可以通过最标准化的语言SQL来对数据进行各种操作。

它的事务性(transactional)能够有效地提供用户并发访问控制,并为应用程序的数据调用提供一致性。

而且,由于关系型数据库主要存储结构化数据,因而它的数据模型和标准化更加适用于报表(Report)的生成。

但是,关系型数据库的最大问题在于:它的设计初衷是要运行在单一的服务器上。

因此,在进行Scale-Out(水平扩展)的时候,很可能会遭遇巨大的瓶颈。

Scale-Up(纵向扩展),就是利用现有的存储系统,通过不断增加存储容量来满足数据增长的需求,就是你买更大的机器来跑数据库;而Scale-Out(水平扩展),就是用多个普通服务器组成集群,让数据库分布在这个集群的节点当中。

集群(Cluster)的概念,就是用更多的服务器来做一件事;其中如果一个服务器宕机,其它的机器还可以继续运行,因此整个集群也能够正常工作。

链接:宕机、宕掉宕机,音译即down机。

服务器宕机是指服务器压力死机或需要重启;数据库宕掉是指数据库压力导致响应需要重启。

4、关系型数据库的劣势分析随着Web2.0的发展,传统的关系型数据库在应对超大规模和高并发的SNS(Social Network Site,社交网站)类型的网站方面,暴露了许多难以克服的问题,主要表现在以下方面:⑴、高并发读写速度慢这种情况主要发生在数据量达到一定规模时。

由于关系型数据库的系统逻辑非常复杂,使得其非常容易发生死锁等并发问题,导致其读写速度下降非常严重。

例如,Web2.0网站,要根据用户个性化信息来实时生成动态页面、提供动态信息,所以基本上无法使用动态页面静态化技术。

因此,数据库并发负载非常高,往往要达到每秒上万次读写请求。

关系型数据库勉强可以应付上万次SQL查询,而硬盘I/O则往往无法承担上万次的SQL写数据请求。

⑵、支撑容量有限类似Facebook、Twitter这样的SNS网站,用户每天产生海量的用户动态,每月会产生几亿条用户动态。

对于关系型数据库来说,在一张有数亿条记录的数据表里面进行SQL查询,效率是极其低下甚至是不可忍受的。

⑶、扩展性差在基于Web的架构当中,数据库是最难进行横向扩展的。

当一个应用系统的用户量和访问量与日俱增的时候,传统的关系型数据库却没有办法像Web Server(Web服务器)那样,简单地通过添加更多的硬件(服务器)和服务器节点,来扩展性能和负载能力。

对于很多需要提供不间断服务的网站来说,对数据库系统进行升级和扩展是非常痛苦的事情,往往需要停机维护和数据迁移。

因此,迫切需要关系型数据库也能够通过不断添加服务器节点来实现横向扩展。

⑷、建设和运维成本高企业级数据库的价格很高,并且随着系统的规模增大而不断上升。

高昂的建设和运维成本,无法满足云计算应用对数据库的需求。

关系型数据库遇到上述难以克服的瓶颈。

与此同时,它的很多主要特性,在云计算应用中,却往往无用武之地。

例如:数据库事务一致性、数据库的写实时性和读实时性、复杂的SQL查询特别是多数据表关联查询。

因此,传统的关系型数据库,已经无法独立应付云计算时代的各种应用。

链接:事务一致性事务执行的结果必须是使数据库从一个一致性状态转变到另一个一致性状态。

保证数据库事务一致性,是指当事务完成时,必须使所有数据都具有一致的状态。

在关系型数据库中,所有的规则必须应用到事务的修改上,以便维护所有数据的完整性。

保证数据库事务一致性是数据库管理系统的一项功能。

比如,有两个数据表(员工/职位)。

在员工表中有员工代码、姓名、职位代码等属性;在职位表中有职位代码、职位名称、职位等级等属性。

你在其中员工表中进行了插入操作,你插入了一个新员工的信息;而这个新员工的职位是公司新创建的一个职位。

如果没有事务一致性的保证,那么就会出现有这么一个员工,但是不知道他到底担当什么职责!这个只是它的一个小小方面。

2016年12月22日编写于重庆2019年2月11日修改于重庆。

相关主题