关系型数据库和非关系型数据库19668.pdf

《关系型数据库和非关系型数据库19668.pdf》由会员分享，可在线阅读，更多相关《关系型数据库和非关系型数据库19668.pdf（11页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、-.z.关系型数据库和非关系型数据库 自 1970 年，埃德加科德提出关系模型之后，关系数据库便开场出现，经过了 40 多年的演化，如今的关系型数据库具备了强大的存储、维护、查询数据的能力。但在关系数据库日益强大的时候，人们发现，在这个信息爆炸的“大数据时代，关系型数据库遇到了性能方面的瓶颈，面对一个表中上亿条的数据，SQL 语句在大数据的查询方面效率欠佳。我们应该知道，往往添加了越多的约束的技术，在一定程度上定会拖延其效率。在 1998 年，Carlo Strozzi 提出 NOSQL 的概念，指的是他开发的一个没有 SQL 功能，轻量级的，开源的关系型数据库。注意，这个定义跟我们现在对 N

2、oSQL 的定义有很大的区别，它确确实实字如其名，指的就是“没有 SQL的数据库。但是 NoSQL 的开展慢慢偏离了初衷，CarloStrozzi也觉察，其实我们要的不是nosql，而应该是norelational，也就是我们现在常说的非关系型数据库了。在关系型数据库中，导致性能欠佳的最主要因素是多表的关联查询，以及复杂的数据分析类型的复杂 SQL 报表查询。为了保证数据库的 ACID 特性，我们必须尽量按照其要求的式进展设计，关系型数据库中的表都是存储一些格式化的数据构造，每个元组字段的组一样，即使不是每个元组都需要所有的字段，但数据库会为每个元组分配所有的字段，这样的构造可以便于表与表之间

3、进展连接等操作，但从另一个角度来说它也是关系型数据库性能瓶颈的一个因素。非关系型数据库提出另一种理念，他以键值对存储，且构造不固定，每一个元组可以有不一样的字段，每个元组可以根据需要增加一些自己的键值对，这样就不会局限于固定的构造，可以减少一些时间和空间的开销。使用这种方式，用户可-.z.以根据需要去添加自己需要的字段，这样，为了获取用户的不同信息，不需要像关系型数据库中，要对多表进展关联查询。仅需要根据 id 取出相应的 value 就可以完成查询。但非关系型数据库由于很少的约束，他也不能够提供想 SQL 所提供的 where 这种对于字段属性值情况的查询。并且难以表达设计的完整性。他只适合

4、存储一些较为简单的数据，对于需要进展较复杂查询的数据，SQL 数据库显得更为适宜。目前出现的NoSQL(Not only SQL，非关系型数据库)有不下于25种，除了Dynamo、Bigtable 以外还有很多，比方 Amazon 的 SimpleDB、微软公司的 AzureTable、Facebook 使用的 Cassandra、类 Bigtable 的 Hypertable、Hadoop 的 HBase、MongoDB、CouchDB、Redis 以及!的 PNUTS 等等。这些 NoSQL 各有特色，是基于不同应用场景而开发的，而其中以 MongoDB 和 Redis 最为被大家追捧。以

5、下是 MongoDB 的一些情况：MongoDB 是基于文档的存储的而非表，是一个介于关系数据库和非关系数据库之间的产品，是非关系数据库当中功能最丰富，最像关系数据库的。他支持的数据构造非常松散，是类似 json 的 bjson 格式，因此可以存储比拟复杂的数据类型。模式自由(schema-free)，意味着对于存储在 MongoDB 数据库中的文件，我们不需要知道它的任何构造定义。如果需要的话，你完全可以把不同构造的文件存储在同一个数据库里。Mongo 最大的特点是他支持的查询语言非常强大，其语法有点类似于面向对象的查询语言，几乎可以实现类似关系数 据库单表查询的绝大局部功能，而且还支持对数

6、据建立索引。Mongo 主要解决的是海量数据的访问效率问题。因为 Mongo 主要是支持海量数据存储的，所以 Mongo 还自带了一个出色的分布式文件系统 GridFS，可以支持-.z.海量的数据存储。由于 Mongo 可以支持复杂的数据构造，而且带有强大的数据查询功能，因此非常受到欢送。关系型数据库的特点 1.关系型数据库 关系型数据库，是指采用了关系模型来组织数据的数据库。简单来说，关系模型指的就是二维表格模型，而一个关系型数据库就是由二维表及其之间的联系所组成的一个数据组织。常见的关系型数据库有 Oracle、Mysql、sql server 等等。2.关系型数据库瓶颈高并发读写需求的用

7、户并发性非常高，往往到达每秒上万次读写请求，对于传统关系型数据库来说，硬盘 I/O 是一个很大的瓶颈海量数据的高效率读写每天产生的数据量是巨大的，对于关系型数据库来说，在一包含海量数据的表中查询，效率是非常低的高扩展性和可用性在基于 web 的构造当中，数据库是最难进展横向扩展的，当一个应用系统的用户量和访问量与日俱增的时候，数据库却没有方法像 web server 和 app server 那样简单的通过添加更多的硬件和效劳节点来扩展性能和负载能力。对于很多需要提供 24 小时不连续效劳的来说，对数据库系统进展升级和扩展是非常痛苦的事情，往往需要停机维护和数据迁移。对来说，关系型数据库的很多

8、特性不再需要了：事务一致性关系型数据库在对事物一致性的维护中有很大的开销，而现在很多 web2.0 系统对事物的读写一致性都不高读写实时性对关系数据库来说，插入一条数据之后立刻查询，是肯定可以读出这条数据的，但是对于很多 web 应用来说，并不要求这么高的实时性，比方发一条消息之后，过几秒乃至十几秒之后才看到这条动态是完全可以承受的复杂 SQL，特别是多表关联查询任何大数据量的 web 系统，都非常忌讳多个大-.z.表的关联查询，以及复杂的数据分析类型的复杂 SQL 报表查询，特别是 SNS 类型的，从需求以及产品阶级角度，就防止了这种情况的产生。往往更多的只是单表的主键查询，以及单表的简单条

9、件分页查询，SQL 的功能极大的弱化了在关系型数据库中，导致性能欠佳的最主要原因是多表的关联查询，以及复杂的数据分析类型的复杂 SQL 报表查询。为了保证数据库的 ACID 特性，我们必须尽量按照其要求的式进展设计，关系型数据库中的表都是存储一个格式化的数据构造。每个元组字段的组是一样，即使不是每个元组都需要所有的字段，但数据库会为每个元组分配所有的字段，这样的构造可以便于标语表之间进展等操作，但从另一个角度来说它也是关系型数据库性能瓶颈的一个因素。非关系型数据库NoSQL 2009 年初，Johan Oskarsson 举办了一场关于开源分布式数据库的讨论，Eric Evans在这次讨论中提

10、出了 NoSQL 一词，用于指代那些非关系型的，分布式的，且一般不保证遵循 ACID 原则的数据存储系统。Eric Evans 使用 NoSQL 这个词，并不是因为字面上的“没有 SQL的意思，他只是觉得很多经典的关系型数据库名字都叫“*SQL,所以为了表示跟这些关系型数据库在定位上的截然不同，就是用了“NoSQL“一词。注：数据库事务必须具备 ACID 特性，ACID 是 Atomic 原子性，Consistency 一致性，隔离性，Durability 持久性。非关系型数据库提出另一种理念，例如，以键值对存储，且构造不固定，每一个元组可以有不一样的字段，每个元组可以根据需要增加一些自己的键

11、值对，这样就不会局限于固定的构造，可以减少一些时间和空间的开销。使用这种方式，用户可以根据需要去添加自己需要的字段，这样，为了获取用户的不同信息，不需要像关系型数据库中，要对-.z.多表进展关联查询。仅需要根据 id 取出相应的 value 就可以完成查询。但非关系型数据库由于很少的约束，他也不能够提供像 SQL 所提供的 where 这种对于字段属性值情况的查询。并且难以表达设计的完整性。他只适合存储一些较为简单的数据，对于需要进展较复杂查询的数据，SQL 数据库显的更为适宜。关系型数据库与非关系型数据库的区别关系型数据库的最大特点就是事务的一致性：传统的关系型数据库读写操作都是事务的，具有

12、 ACID 的特点，这个特性使得关系型数据库可以用于几乎所有对一致性有要求的系统中，如典型的银行系统。但是，在网页应用中，尤其是 SNS 应用中，一致性却不是显得则重要，用户 A 看到的容和用户 B 看到同一用户 C 容更新不一致是可以容忍的，或者说，两个人看到同一好友的数据更新的时间差则几秒是可以容忍的，因此，关系型数据库的最大特点在这里已经无用武之地，起码不是则重要了。相反地，关系型数据库为了维护一致性所付出的巨大代价就是其读写性能比拟差，而像微博、facebook这类SNS的应用，对并发读写能力要求极高，关系型数据库已经无法应付(在读方面，传统上为了克制关系型数据库缺陷，提高性能，都是增

13、加一级 memcache 来静态化网页，而在 SNS 中，变化太快，memchache 已经无能为力了)，因此，必须用新的一种数据构造存储来代替关系数据库。关系数据库的另一个特点就是其具有固定的表构造，因此，其扩展性极差，而在 SNS 中，系统的升级，功能的增加，往往意味着数据构造巨大变动，这一点关系型数据库也难以应付，需要新的构造化数据存储。于是，非关系型数据库应运而生，由于不可能用一种数据构造化存储应付所有的新的需求，因此，非关系型数据库严格上不是一种数据库，应该是一种数据构造化存储方法的集合。必须强调的是，数据的持久存储，尤其是海量数据的持久存储，还是需要一种关系数据库。-.z.1.关系

14、型数据库 关系型数据库，是指采用了关系模型来组织数据的数据库。关系模型是在 1970 年由 IBM 的研究员博士首先提出的，在之后的几十年中，关系模型的概念得到了充分的开展并逐渐成为主流数据库构造的主流模型。简单来说，关系模型指的就是二维表格模型，而一个关系型数据库就是由二维表及其之间的联系所组成的一个数据组织。关系模型中常用的概念：关系：可以理解为一二维表，每个关系都具有一个关系名，就是通常说的表名 元组：可以理解为二维表中的一行，在数据库中经常被称为记录 属性：可以理解为二维表中的一列，在数据库中经常被称为字段 域：属性的取值围，也就是数据库中*一列的取值限制 关键字：一组可以唯一标识元组

15、的属性，数据库中常称为主键，由一个或多个列组成 关系模式：指对关系的描述。其格式为：关系名(属性 1，属性 2，.，属性 N)，在数据库中成为表构造 关系型数据库的优点：容易理解：二维表构造是非常贴近逻辑世界的一个概念，关系模型相对网状、层次等其他模型来说更容易理解 使用方便：通用的 SQL 语言使得操作关系型数据库非常方便 易于维护：丰富的完整性(实体完整性、参照完整性和用户定义的完整性)大大减低了数据冗余和数据不一致的概率-.z.2.关系型数据库瓶颈 高并发读写需求 的用户并发性非常高，往往到达每秒上万次读写请求，对于传统关系型数据库来说，硬盘 I/O 是一个很大的瓶颈 海量数据的高效率读

16、写 每天产生的数据量是巨大的，对于关系型数据库来说，在一包含海量数据的表中查询，效率是非常低的 高扩展性和可用性 在基于 web 的构造当中，数据库是最难进展横向扩展的，当一个应用系统的用户量和访问量与日俱增的时候，数据库却没有方法像 web server 和 app server 那样简单的通过添加更多的硬件和效劳节点来扩展性能和负载能力。对于很多需要提供 24 小时不连续效劳的来说，对数据库系统进展升级和扩展是非常痛苦的事情，往往需要停机维护和数据迁移。对来说，关系型数据库的很多特性不再需要了：事务一致性 关系型数据库在对事物一致性的维护中有很大的开销，而现在很多 web2.0 系统对事物

17、的读写一致性都不高 读写实时性 对关系数据库来说，插入一条数据之后立刻查询，是肯定可以读出这条数据的，但是对于很多 web 应用来说，并不要求这么高的实时性，比方发一条消息之后，过几秒乃至十几秒之后才看到这条动态是完全可以承受的 复杂 SQL，特别是多表关联查询-.z.任何大数据量的 web 系统，都非常忌讳多个大表的关联查询，以及复杂的数据分析类型的复杂 SQL 报表查询，特别是 SNS 类型的，从需求以及产品阶级角度，就防止了这种情况的产生。往往更多的只是单表的主键查询，以及单表的简单条件分页查询，SQL 的功能极大的弱化了 在关系型数据库中，导致性能欠佳的最主要原因是多表的关联查询，以及

18、复杂的数据分析类型的复杂 SQL 报表查询。为了保证数据库的 ACID 特性，我们必须尽量按照其要求的式进展设计，关系型数据库中的表都是存储一个格式化的数据构造。每个元组字段的组是一样，即使不是每个元组都需要所有的字段，但数据库会为每个元组分配所有的字段，这样的构造可以便于标语表之间进展等操作，但从另一个角度来说它也是关系型数据库性能瓶颈的一个因素。3.NoSQL NoSQL 一词首先是 Carlo Strozzi 在 1998 年提出来的，指的是他开发的一个没有SQL 功能，轻量级的，开源的关系型数据库。这个定义跟我们现在对 NoSQL 的定义有很大的区别，它确确实实字如其名，指的就是“没有

19、 SQL的数据库。但是 NoSQL 的开展慢慢偏离了初衷，我们要的不是“no sql，而是“no relational，也就是我们现在常说的非关系型数据库了。2009 年初，Johan Oskarsson 举办了一场关于开源分布式数据库的讨论，Eric Evans在这次讨论中再次提出了 NoSQL 一词，用于指代那些非关系型的，分布式的，且一般不保证遵循 ACID 原则的数据存储系统。Eric Evans 使用 NoSQL 这个词，并不是因为字面上的“没有 SQL的意思，他只是觉得很多经典的关系型数据库-.z.名字都叫“*SQL,所以为了表示跟这些关系型数据库在定位上的截然不同，就是用了“No

20、SQL“一词。注：数据库事务必须具备 ACID 特性，ACID 是 Atomic 原子性，Consistency 一致性，Isolation 隔离性，Durability 持久性。非关系型数据库提出另一种理念，例如，以键值对存储，且构造不固定，每一个元组可以有不一样的字段，每个元组可以根据需要增加一些自己的键值对，这样就不会局限于固定的构造，可以减少一些时间和空间的开销。使用这种方式，用户可以根据需要去添加自己需要的字段，这样，为了获取用户的不同信息，不需要像关系型数据库中，要对多表进展关联查询。仅需要根据 id 取出相应的 value就可以完成查询。但非关系型数据库由于很少的约束，他也不能够

21、提供像 SQL所提供的 where 这种对于字段属性值情况的查询。并且难以表达设计的完整性。他只适合存储一些较为简单的数据，对于需要进展较复杂查询的数据，SQL 数据库显的更为适宜。4.关系型数据库 V.S.非关系型数据库 关系型数据库的最大特点就是事务的一致性：传统的关系型数据库读写操作都是事务的，具有 ACID 的特点，这个特性使得关系型数据库可以用于几乎所有对一致性有要求的系统中，如典型的银行系统。但是，在网页应用中，尤其是 SNS 应用中，一致性却不是显得则重要，用户 A看到的容和用户 B 看到同一用户 C 容更新不一致是可以容忍的，或者说，两个人看到同一好友的数据更新的时间差则几秒是

22、可以容忍的，因此，关系型数据库的最大特点在这里已经无用武之地，起码不是则重要了。-.z.相反地，关系型数据库为了维护一致性所付出的巨大代价就是其读写性能比拟差，而像微博、facebook 这类 SNS 的应用，对并发读写能力要求极高，关系型数据库已经无法应付(在读方面，传统上为了克制关系型数据库缺陷，提高性能，都是增加一级 memcache 来静态化网页，而在 SNS 中，变化太快，memchache 已经无能为力了)，因此，必须用新的一种数据构造存储来代替关系数据库。关系数据库的另一个特点就是其具有固定的表构造，因此，其扩展性极差，而在SNS 中，系统的升级，功能的增加，往往意味着数据构造巨

23、大变动，这一点关系型数据库也难以应付，需要新的构造化数据存储。于是，非关系型数据库应运而生，由于不可能用一种数据构造化存储应付所有的新的需求，因此，非关系型数据库严格上不是一种数据库，应该是一种数据构造化存储方法的集合。必须强调的是，数据的持久存储，尤其是海量数据的持久存储，还是需要一种关系数据库这员老将。5.非关系型数据库分类 由于非关系型数据库本身天然的多样性，以及出现的时间较短，因此，不想关系型数据库，有几种数据库能够一统江山，非关系型数据库非常多，并且大局部都是开源的。这些数据库中，其实实现大局部都比拟简单，除了一些共性外，很大一局部都是针对*些特定的应用需求出现的，因此，对于该类应用，具有极高的性能。依据构造化方法以及应用场合的不同，主要分为以下几类：面向高性能并发读写的 key-value 数据库：-.z.key-value 数据库的主要特点即使具有极高的并发读写性能，Redis,Tokyo Cabinet,Flare 就是这类的代表 面向海量数据访问的面向文档数据库：这类数据库的特点是，可以在海量的数据中快速的查询数据，典型代表为MongoDB 以及 CouchDB 面向可扩展性的分布式数据库：这类数据库想解决的问题就是传统数据库存在可扩展性上的缺陷，这类数据库可以适应数据量的增加以及数据构造的变化