关系型与非关系型数据库全文.docx
《关系型与非关系型数据库全文.docx》由会员分享，可在线阅读，更多相关《关系型与非关系型数据库全文.docx（16页珍藏版）》请在冰豆网上搜索。
关系型与非关系型数据库全文
关系型与非关系型数据库（全文）
胡经国
本文作者的话
本文是根据有关文献和资料编写的《漫话云计算》系列文稿之一。
以此作为云计算学习笔录，供云计算业外读者进一步学习和研究参考。
希望能够得到大家的指教和喜欢！
下面是正文
一、云计算时代对数据库技术的新需求
随着云计算时代的到来，各种类型的互联网应用层出不穷，对数据模型、分布式架构、数据存储等数据库相关技术指标提出了新的要求。
虽然传统的关系型数据库，已在数据存储方面占据了不可动摇的地位，但是由于其天生的限制，已经越来越无法满足云计算时代对数据扩展、读写速度、支撑容量以及建设和运营成本的要求。
云计算时代对数据库技术提出了新的需求，主要表现在以下几个方面：
⑴、海量数据处理
对类似搜索引擎和电信运营商级的经营分析系统这样大型的应用而言，需要能够处理PB级的数据，同时需要应对百万级流量。
⑵、大规模集群管理
大规模集群管理使分布式应用可以更加简单地部署、应用和管理。
⑶、低延迟读写速度
快速的响应速度能够极大地提高用户的满意度。
⑷、建设及运营成本
云计算应用的基本要求，是希望在硬件成本、软件成本以及人力成本方面都有大幅度的降低。
链接：
互联网应用
互联网应用，是指搜索引擎、聊天室和讨论组以及实用软件（公用软件、共享软件、自由软件）等。
宽带上网催生了一系列新的互联网应用，比较流行的如网络游戏、博客、微博、播客、互联网电视、互联网金融、流媒体（边传边播的媒体）、即时通信（如QQ）、网络电话（voip）、电子商务等等。
链接：
数据扩展
数据扩展是由一组连续的数据块构成的，是数据库逻辑存储分配单位。
而数据表的数据段则是由一个或多个数据扩展构成。
当一个数据段己有空间用完时，关系数据库管理系统（Oracle）自动为这个数据段分配新的数据扩展。
当用户创建数据表时。
Oracle为此数据表的数据段分配一个包含若干数据块的初始数据扩展。
虽然此时数据表中还没有数据，但是在此初始数据扩展中的数据块己经为插入（insert）新数据做好了准备。
如果一个数据段的初始数据扩展的数据块都己装满，而且有新的数据要插入时，Oracle自动为这个数据段分配一个增量数据扩展。
链接：
集群（Cluster）技术
集群（Cluster）技术定义：
一组相互独立的服务器在网络中表现为单一的系统，并以单一系统的模式加以管理。
此单一系统为客户工作站提供高可性的服务。
在大多数模式下，集群中所有的计算机拥有一个共同的名称，集群内任一系统上运行的服务可被所有的网络客户所使用。
Cluster必须可以协调管理各分离的组件的错误和失败，并可透明地向Cluster中加入组件。
一个Cluster包含多台（至少二台）拥有共享数据存储空间的服务器。
任何一台服务器运行一个应用时，应用数据被存储在共享的数据空间内。
每台服务器的操作系统和应用程序文件存储在其各自的本地储存空间上。
Cluster内各节点服务器通过一内部局域网相互通信。
当一台节点服务器发生故障时，这台服务器上所运行的应用程序将在另一节点服务器上被自动接管。
当一个应用服务发生故障时，应用服务将被重新启动或被另一台服务器接管。
当以上的任一故障发生时，客户都将能很快连接到新的应用服务上。
链接：
分布式应用
分布式应用（DistributedApplication，DA），是指应用程序分布在不同计算机上，通过网络来共同完成一项任务的工作方式。
链接：
低延迟
延迟是一个现代词语，意思是推迟到较后的时间。
低延迟的需求，很大程度上来自于证券市场上高频交易比例的迅猛增长。
在证券产品可以在多家交易所进行交易的情况下，能够更快处理订单、更快反馈行情的交易所，显然更能吸引采用高频交易策略的机构投资者。
例如，2010年，纳斯达克（NASDAQ）应用INET（电子交易平台技术）处理延迟小于250微秒，每秒可处理100万笔订单，是当时世界上最快的交易所。
二、关系型数据库SQL
1、关系型数据库概述
关系型数据库是建立在数据关系模型基础上的数据库。
关系模型是指二维表格模型。
因而，一个关系型数据库就是由二维表及其之间的联系组成的一个数据组织。
关系模型由关系数据结构、关系操作集合、关系完整性约束三部分组成。
在现实世界中，各种实体以及实体之间的各种联系均用关系模型来表示。
现如今，虽然对关系模型有一些批评意见，但是它还是数据存储的传统标准。
SQL（StructuredQueryLanguage，结构化查询语言），是一种标准数据查询语言，一种通用的、功能极强的关系型数据库语言，同时也是数据库脚本文件的扩展名。
SQL是一种数据库查询和程序设计语言，执行对关系型数据库中数据的检索和操作，用于存取数据以及查询、更新和管理关系型数据库系统。
它是1974年由Boyce和Chamberlin提出的一种介于关系代数与关系演算之间的结构化查询语言。
当前，主流的关系型数据库有Oracle、DB2、PostgreSQL、MicrosoftSQLServer、MicrosoftAccess、MySQL、浪潮K-DB等。
2、关系型数据库数据表
关系型数据库的数据表，是以行和列的形式组织起来的数据集合。
一个数据库包括一个或多个数据表。
例如，可能有一个有关作者信息的名为authors的数据表。
每列都包含有关特定作者的一类信息，如作者的姓氏；每行都包含有关特定作者的所有信息：
姓名、住址等等。
在关系型数据库当中一个数据表就是一个关系，一个关系数据库可以包含多个数据表。
3、关系型数据库的特点和问题
关系型数据库成为主流技术已经超过20年。
这是有它的道理的。
它把数据存储在磁盘中，人们可以通过最标准化的语言SQL来对数据进行各种操作。
它的事务性（transactional）能够有效地提供用户并发访问控制，并为应用程序的数据调用提供一致性。
而且，由于关系型数据库主要存储结构化数据，因而它的数据模型和标准化更加适用于报表（Report）的生成。
但是，关系型数据库的最大问题在于：
它的设计初衷是要运行在单一的服务器上。
因此，在进行Scale-Out（水平扩展）的时候，很可能会遭遇巨大的瓶颈。
Scale-Up（纵向扩展），就是利用现有的存储系统，通过不断增加存储容量来满足数据增长的需求，就是你买更大的机器来跑数据库；而Scale-Out（水平扩展），就是用多个普通服务器组成集群，让数据库分布在这个集群的节点当中。
集群（Cluster）的概念，就是用更多的服务器来做一件事；其中如果一个服务器宕机，其它的机器还可以继续运行，因此整个集群也能够正常工作。
链接：
宕机、宕掉
宕机，音译即down机。
服务器宕机是指服务器压力死机或需要重启；数据库宕掉是指数据库压力导致响应需要重启。
4、关系型数据库的劣势分析
随着Web2.0的发展，传统的关系型数据库在应对超大规模和高并发的SNS（SocialNetworkSite，社交网站）类型的网站方面，暴露了许多难以克服的问题，主要表现在以下方面：
⑴、高并发读写速度慢
这种情况主要发生在数据量达到一定规模时。
由于关系型数据库的系统逻辑非常复杂，使得其非常容易发生死锁等并发问题，导致其读写速度下降非常严重。
例如，Web2.0网站，要根据用户个性化信息来实时生成动态页面、提供动态信息，所以基本上无法使用动态页面静态化技术。
因此，数据库并发负载非常高，往往要达到每秒上万次读写请求。
关系型数据库勉强可以应付上万次SQL查询，而硬盘I/O则往往无法承担上万次的SQL写数据请求。
⑵、支撑容量有限
类似Facebook、Twitter这样的SNS网站，用户每天产生海量的用户动态，每月会产生几亿条用户动态。
对于关系型数据库来说，在一张有数亿条记录的数据表里面进行SQL查询，效率是极其低下甚至是不可忍受的。
⑶、扩展性差
在基于Web的架构当中，数据库是最难进行横向扩展的。
当一个应用系统的用户量和访问量与日俱增的时候，传统的关系型数据库却没有办法像WebServer（Web服务器）那样，简单地通过添加更多的硬件（服务器）和服务器节点，来扩展性能和负载能力。
对于很多需要提供不间断服务的网站来说，对数据库系统进行升级和扩展是非常痛苦的事情，往往需要停机维护和数据迁移。
因此，迫切需要关系型数据库也能够通过不断添加服务器节点来实现横向扩展。
⑷、建设和运维成本高
企业级数据库的价格很高，并且随着系统的规模增大而不断上升。
高昂的建设和运维成本，无法满足云计算应用对数据库的需求。
关系型数据库遇到上述难以克服的瓶颈。
与此同时，它的很多主要特性，在云计算应用中，却往往无用武之地。
例如：
数据库事务一致性、数据库的写实时性和读实时性、复杂的SQL查询特别是多数据表关联查询。
因此，传统的关系型数据库，已经无法独立应付云计算时代的各种应用。
链接：
事务一致性
事务执行的结果必须是使数据库从一个一致性状态转变到另一个一致性状态。
保证数据库事务一致性，是指当事务完成时，必须使所有数据都具有一致的状态。
在关系型数据库中，所有的规则必须应用到事务的修改上，以便维护所有数据的完整性。
保证数据库事务一致性是数据库管理系统的一项功能。
比如，有两个数据表（员工/职位）。
在员工表中有员工代码、姓名、职位代码等属性；在职位表中有职位代码、职位名称、职位等级等属性。
你在其中员工表中进行了插入操作,你插入了一个新员工的信息；而这个新员工的职位是公司新创建的一个职位。
如果没有事务一致性的保证，那么就会出现有这么一个员工，但是不知道他到底担当什么职责！
这个只是它的一个小小方面。
三、非关系型数据库NoSQL
1、非关系型数据库的定义
一些关于数据库技术发展的文章，基本都是围绕着SQL（关系型数据库）与NoSQL（非关系型数据库）的讨论来展开的。
当初在NoSQL运动刚刚起步的时候，“SaynotoSQL（对SQL说不）”的口号不绝于耳。
当然，这个口号并没有成为现实。
人们最终普遍接受了“Not-OnlySQL（不仅SQL）”的说法。
在这里，真的要给NoSQL下一个定义，还真不是件容易的事。
人们习惯把MongoDB、Redis这样的产品，作为NoSQL普遍定义。
链接：
MongoDB
MongoDB是一个分布式文档存储数据库，用C++语言编写。
它旨在为Web应用提供可扩展的高性能数据存储解决方案。
MongoDB是一个高性能、开源、无模式的文档型数据库，是当前NoSql数据库中比较热门的一种。
它在许多场景下可用于替代传统的关系型数据库。
链接：
Redis
Redis是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value（键－值）数据库，并提供多种语言的API。
从2010年3月15日起，Redis的开发工作由VMware主持。
不过，更加中肯的定义是：
凡是没有用到SQL的都算是NoSQL，即便是在传统的关系型数据库里。
也就是说，你可以把它们看作是一对好基友；你中有我，我中有你。
用软件工程师MartinFowler在一篇文章中提到的词来形容就非常贴切：
PolyglotPersistence，即“混合持久化”或者“多语言持久化”。
所以说，在未来的数据库技术领域，将很有可能打破所谓的关系型SQL和非关系型NoSQL之间的界限，用不同的工具达到不同的目的。
将各种数据库技术杂糅在一套系统中，各司其职。
因此，就像Fowler所说的，无论怎样定义NoSQL都是无用功。
2、非关系型数据库的出现和特点
在这方面，一些大型的互联网公司走在了前面。
像Google和Amazon，都运行了非常大型的服务器集群，并逐渐衍生出了云计算的概念。
他们都意识到，SQL数据库在应对服务器集群方面，出现了比较大的性能瓶颈。
因此，纷纷放弃SQL，自己开始研发出像BigTable和Dynamo这样的存储平台。
它们应该算是最早的NoSQL数据库。
于是，人们开始注意到这个问题，各种各样的NoSQL产品也不断涌现出来。
Adewale把非关系型数据库的特点归结为：
不使用关系数据模型，不使用结构化查询语言SQL；往往针对大型服务器集群设计；没有固定的模式（Schema），一条记录中可以存储任意数据；往往是开源的。
非关系型数据库主要解决的一个问题就是大数据集存储；使用NoSQL数据库的大型服务器集群可以存储PB级别的数据，并处理大量的分析数据。
而多种多样的数据模型，可以用来应对不同类型的数据，比如文档、图片、视频等非结构化数据。
3、非关系型数据库数据模型
关系型数据库越来越无法满足云计算的应用需求。
为了解决此类问题，非关系型数据库应运而生。
由于在设计上，和传统的关系型数据库相比，有了很大的不同，因而此类数据库被称为“NoSQL（NotonlySQL，不仅SQL）”系列数据库。
与关系型数据库相比，非关系型数据库非常关注数据高并发读写和海量数据的存储；在架构和数据模型方面作了简化；在扩展和并发等方面作了增强。
目前，主流的NoSQL数据库包括：
BigTable、HBase、Cassandra、SimpleDB、CouchDB、MongoDB以及Redis等。
非关系型数据库常用数据模型包括以下3种：
⑴、Column-oriented（列式）
列式主要使用Table（表）这样的模型。
但是，它并不支持多表的操作。
它的主要特点是：
在存储数据时，主要围绕着“列（Column）”,而不是像传统的关系型数据库那样根据“行（Row）”进行存储。
也就是说，属于同一列的数据会尽可能地存储在硬盘同一个页中，而不是将属于同一个行的数据存放在一起。
这样做的好处是：
对于很多类似数据仓库的应用，虽然每次查询都会处理很多数据，但是每次所涉及的列并不是很多。
使用列式数据库将会节省大量I/O。
并且，大多数列式数据库都支持ColumnFamily（列族也就是一组列）这个特性，能将多个列并为一个小组。
这样做的好处是，能将相似列放在一起存储，提高这些列的存储和查询效率。
总体而言，这种数据模型的优点是：
比较适合汇总和数据仓库这类应用。
链接：
I/O
I/O（input/output）的意思是输入/输出。
每个计算机设备都有一个专用的I/O地址，用来处理自己的输入输出信息。
CPU与外部设备、存储器的连接和数据交换，都需要通过接口（interface）设备来实现；前者被称为I/O接口，而后者则被称为存储器接口。
存储器通常在CPU的同步控制下工作，接口电路比较简单；而I/O设备品种繁多，其相应的接口电路也各不相同。
因此，习惯上说到接口只是指I/O接口。
链接：
数据仓库
数据仓库（DataWarehouse，DW或DWH），是为企业所有级别的决策制定过程，提供所有类型数据支持的战略集合。
它是单个数据存储，出于分析性报告和决策支持目的而创建。
为需要业务智能的企业，提供指导业务流程改进、监视时间、成本、质量以及控制。
数据仓库是决策支持系统（DecisionSupportSystem，DSS）和联机分析应用数据源的结构化数据环境。
数据仓库研究和解决从数据库中获取信息的问题。
数据仓库的特征在于面向主题、集成性、稳定性和时变性（后面将撰文介绍）。
链接：
联机分析处理
联机分析处理（OnlineAnalyticalProcessing，OLAP）系统是数据仓库系统最主要的应用。
它专门设计用于支持复杂的分析操作，侧重对决策人员和高层管理人员的决策支持。
可以根据分析人员的要求，快速、灵活地进行大数据量的复杂查询处理，并且以一种直观而易懂的形式将查询结果提供给决策人员，以便他们准确掌握企业（公司）的经营状况，了解对象的需求，制定正确的方案。
⑵、Key-value（键值）
虽然Key-value这种模型和传统的关系型相比，比较简单；有点类似常见的HashTable（哈希表），一个Key（键）对应一个Value（值）。
但是，它能提供非常快的查询速度、大的数据存放量和高并发操作；非常适合通过主键对数据进行查询和修改等操作。
虽然不支持复杂的操作，但是可以通过上层的开发，来弥补这个缺陷。
链接：
哈希表
哈希表（Hashtable），又叫做散列表，是根据关键码值（Keyvalue）直接进行访问的数据结构，以加快查询的速度。
链接：
主键与外键
在SQL数据库中，主键是能确定一条记录的唯一标识。
例如，一条记录包括身份证号、姓名、年龄。
其中，身份证号是唯一能确定这个人的，其它都可能有重复，所以身份证号就是主键。
外键用于与另一张表的关联，是能确定另一张表记录的字段，用于保持数据的一致性。
例如，A表中的一个字段，是B表的主键，那它就是A表的外键。
⑶、Document（文档）
在结构上，Document和Key-value是非常相似的；也是一个Key（键）对应一个Value（值）。
但是，这个Value（值）主要以JSON或者XML等格式的文档来进行存储，是有语义的。
并且，DocumentDB（文档型数据库）一般可以对Value来创建SecondaryIndex（二级索引），以方便上层的应用。
这点是普通Key-ValueDB（键值数据库）所无法支持的。
4、非关系型数据库四大类型
⑴、键值（Key-Value）存储数据库
这一类数据库主要会使用到一个哈希表，这个表中有一个特定的键和一个指针指向特定的数据。
Key-value模型对于IT系统来说，其优势在于简单、易部署。
但是，如果DBA只对部分值进行查询或更新，那么Key-value模型就显得效率低下了。
例如，TokyoCabinet/Tyrant，Redis，Voldemort，OracleBDB。
⑵、列存储数据库
这部分数据库通常是用来应对分布式存储的海量数据。
键仍然存在，但是它们的特点是指向了多个列。
这些列是由列家族（列簇）来安排的，如：
Cassandra，HBase，Riak。
⑶、文档型数据库
文档型数据库的灵感来自于LotusNotes办公软件，而且它同第一种键值存储相类似。
该类型的数据模型是版本化的文档、半结构化的文档以特定的格式存储，比如JSON等格式。
文档型数据库可以看作是键值数据库的升级版，允许之间嵌套键值。
而且，文档型数据库比键值数据库的查询效率更高。
如：
CouchDB，MongoDB。
中国国内也有文档型数据库SequoiaDB，已经开源。
⑷、图形（Graph）数据库
图形结构的数据库，同其它行列以及刚性结构的SQL数据库不同。
它是使用灵活的图形模型，并且能够扩展到多个服务器上。
NoSQL数据库没有标准的查询语言（SQL），因此进行数据库查询需要制定数据模型。
5、非关系型数据库共同特点
对于NoSQL并没有一个明确的范围和定义，但是它们都普遍具有以下一些共同特点：
⑴、不需要预定义模式
不需要事先定义数据模式、预定义表结构。
数据中的每条记录都可能有不同的属性和格式。
当插入数据时，并不需要预先定义它们的模式。
⑵、无共享架构
相对于将所有数据存储的存储区域网络中的全共享架构。
NoSQL往往将数据划分后存储在各个本地服务器上。
因为，从本地磁盘读取数据的性能往往好于通过网络传输读取数据的性能，从而提高了系统的性能。
⑶、弹性可扩展
可以在系统运行的时候，动态增加或者删除节点。
不需要停机维护，数据可以自动迁移。
⑷、分区
相对于将数据存放于同一个节点，NoSQL数据库需要将数据进行分区，将记录分散在多个节点上面。
并且，通常分区的同时还要做复制。
这样，既提高了并行性能，又能保证没有单点失效的问题。
⑸、异步复制
和RAID（RedundantArraysofIndependentDisks，磁盘阵列）存储系统不同的是，NoSQL中的复制，往往是基于日志的异步复制。
这样，数据就可以尽快地写入一个节点，而不会被网络传输引起迟延。
缺点是并不总是能保证一致性。
这样的方式在出现故障的时候，可能会丢失少量的数据。
链接：
异步复制
异步复制技术是指在写被响应到主机之前，数据必须被承诺存储在单独的一级站点而不是存储在二级站点。
当网络容量允许时，数据传向二级站点。
⑹、BASE
相对于事务严格的ACID特性，NoSQL数据库保证的是BASE特性。
BASE是最终一致性和软事务。
链接：
BASE：
最终一致性和软事务
所谓最终一致性，就是不保证在任意时刻任意节点上的同一份数据都是相同的；但是随着时间的迁移，不同节点上的同一份数据总是在向趋同的方向变化。
也可以简单的理解为：
在一段时间后，节点间的数据会最终会达到一致状态。
软事务（待查）
链接：
ACID
ACID，是指数据库事务正确执行的四个基本要素的英文的缩写，包含：
原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）。
事务（Transaction）正确执行，必需要具有这四种特性，否则在事务过程（Transactionprocessing）当中无法保证数据的正确性，交易过程极可能达不到交易方的要求。
原子性：
整个事务中的所有操作，要么全部完成，要么全部不完成，不可能停滞在中间某个环节。
事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。
一致性：
在事务开始之前和事务结束以后，数据库的完整性约束没有被破坏。
隔离性：
在隔离状态执行事务，使它们好像是系统在给定时间内执行的唯一操作。
持久性：
在事务完成以后，该事务所对数据库所作的更改便持久的保存在数据库之中，并不会被回滚。
目前主要有两种方式实现ACID：
第一种是Writeaheadlogging（预写日志），也就是日志式的方式。
第二种是Shadowpaging（影子分页）。
链接：
Write-AheadLogging
Write-AheadLogging（WAL，预写日志）技术，是数据库中一种高效的日志算法。
对于非内存数据库而言，磁盘I/O操作是数据库效率的一大瓶颈。
在相同的数据量下，采用WAL日志的数据库系统在事务提交时，磁盘写操作只有传统的回滚日志的一半左右，大大提高了数据库磁盘I/O操作的效率，从而提高了数据库的性能。
链接：
Shadowpaging
相对于WAL（writeaheadlogging）技术，ShadowPaging（SP，影子分页）技术实现起来比较简单，消除了写日志记录的开销，恢复的速度也快。
ShadowPaging的缺点就是事务提交时要输出多个块。
这使得提交的开销很大，而且以块为单位，很难应用到允许多个事务并发执行的情况——这是它致命的缺点。
NoSQL数据库并没有一个统一的架构；两种NoSQL数据库之间的不同，甚至远远超过两种关系型数据库的不同。
可以说，NoSQL各有所长。
成功的NoSQL必然特别适用于某些场合或者某些应用；在这些场合中会远远胜过关系型数据库和其它的NoSQL。
6、非关系型数据库使用范围
NoSQL数据库没有标准的查询语言（SQL），因此进行数据库查询需要制定数据模型。
许多NoSQL数据库都有REST式的数据接口或者查询API。
如：
Neo4J，InfoGrid，InfiniteGraph。
因此，NoSQL数据库在以下的这几种情况下比较适用：
⑴、数据模型比较简单；
⑵、需要灵活性更强的IT系统；
⑶、对数据库性能要求较高；
⑷、不需要高度的数据一致性；
⑸、对于给定key（键），比较容易映射复杂值的环境。
链接：
数据接口
接口可以比喻为一个通道，两个相互独立的程序，通过这个接口通道，实现数据传输，信息交流。
当然这个两个程序都必须遵守这个接口规定的一些标准，只有共同遵守这个接口标准，才能进行正常的数据传输和通信。
链接：
复杂值
Javascript（一种直译式脚本语言）的数据类型可以分为两种：
原始类型和引用类型。
原始类型也称为基本类型或简单类型；而引用类型也称为复杂类型。
与此
升级会员 