关系型数据库和非关系型数据库

￡神魔★判官ぃ 2022-08-18 11:49 233阅读 0赞

转自：[http://blog.csdn.net/robinjwong/article/details/18502195][http_blog.csdn.net_robinjwong_article_details_18502195]

# 1. 关系型数据库 #

关系型数据库，是指采用了关系模型来组织数据的数据库。

关系模型是在1970年由IBM的研究员E.F.Codd博士首先提出的，在之后的几十年中，关系模型的概念得到了充分的发展并逐渐成为主流数据库结构的主流模型。

简单来说，关系模型指的就是二维表格模型，而一个关系型数据库就是由二维表及其之间的联系所组成的一个数据组织。

关系模型中常用的概念：

*  关系：可以理解为一张二维表，每个关系都具有一个关系名，就是通常说的表名
 *  元组：可以理解为二维表中的一行，在数据库中经常被称为记录
 *  属性：可以理解为二维表中的一列，在数据库中经常被称为字段
 *  域：属性的取值范围，也就是数据库中某一列的取值限制
 *  关键字：一组可以唯一标识元组的属性，数据库中常称为主键，由一个或多个列组成
 *  关系模式：指对关系的描述。其格式为：关系名(属性1，属性2， ... ... ，属性N)，在数据库中成为表结构

关系型数据库的优点：

*  容易理解：二维表结构是非常贴近逻辑世界的一个概念，关系模型相对网状、层次等其他模型来说更容易理解
 *  使用方便：通用的SQL语言使得操作关系型数据库非常方便
 *  易于维护：丰富的完整性(实体完整性、参照完整性和用户定义的完整性)大大减低了数据冗余和数据不一致的概率

# 2. 关系型数据库瓶颈 #

*  高并发读写需求

网站的用户并发性非常高，往往达到每秒上万次读写请求，对于传统关系型数据库来说，硬盘I/O是一个很大的瓶颈

*  海量数据的高效率读写

网站每天产生的数据量是巨大的，对于关系型数据库来说，在一张包含海量数据的表中查询，效率是非常低的

*  高扩展性和可用性

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

对网站来说，关系型数据库的很多特性不再需要了：

*  事务一致性

关系型数据库在对事物一致性的维护中有很大的开销，而现在很多web2.0系统对事物的读写一致性都不高

*  读写实时性

对关系数据库来说，插入一条数据之后立刻查询，是肯定可以读出这条数据的，但是对于很多web应用来说，并不要求这么高的实时性，比如发一条消息之后，过几秒乃至十几秒之后才看到这条动态是完全可以接受的

*  复杂SQL，特别是多表关联查询

任何大数据量的web系统，都非常忌讳多个大表的关联查询，以及复杂的数据分析类型的复杂SQL报表查询，特别是SNS类型的网站，从需求以及产品阶级角度，就避免了这种情况的产生。往往更多的只是单表的主键查询，以及单表的简单条件分页查询，SQL的功能极大的弱化了

在关系型数据库中，导致性能欠佳的最主要原因是多表的关联查询，以及复杂的数据分析类型的复杂SQL报表查询。为了保证数据库的ACID特性，我们必须尽量按照其要求的范式进行设计，关系型数据库中的表都是存储一个格式化的数据结构。每个元组字段的组成都是一样，即使不是每个元组都需要所有的字段，但数据库会为每个元组分配所有的字段，这样的结构可以便于标语表之间进行链接等操作，但从另一个角度来说它也是关系型数据库性能瓶颈的一个因素。

# 3. NoSQL #

NoSQL一词首先是Carlo Strozzi在1998年提出来的，指的是他开发的一个没有SQL功能，轻量级的，开源的关系型数据库。这个定义跟我们现在对NoSQL的定义有很大的区别，它确确实实字如其名，指的就是“没有SQL”的数据库。但是NoSQL的发展慢慢偏离了初衷，我们要的不是“no sql”，而是“no relational”，也就是我们现在常说的非关系型数据库了。

2009年初，Johan Oskarsson举办了一场关于开源分布式数据库的讨论，Eric Evans在这次讨论中再次提出了NoSQL一词，用于指代那些非关系型的，分布式的，且一般不保证遵循ACID原则的数据存储系统。Eric Evans使用NoSQL这个词，并不是因为字面上的“没有SQL”的意思，他只是觉得很多经典的关系型数据库名字都叫“\*\*SQL”,所以为了表示跟这些关系型数据库在定位上的截然不同，就是用了“NoSQL“一词。

注：数据库事务必须具备ACID特性，ACID是Atomic原子性，Consistency一致性，Isolation隔离性，Durability持久性。

非关系型数据库提出另一种理念，例如，以键值对存储，且结构不固定，每一个元组可以有不一样的字段，每个元组可以根据需要增加一些自己的键值对，这样就不会局限于固定的结构，可以减少一些时间和空间的开销。使用这种方式，用户可以根据需要去添加自己需要的字段，这样，为了获取用户的不同信息，不需要像关系型数据库中，要对多表进行关联查询。仅需要根据id取出相应的value就可以完成查询。但非关系型数据库由于很少的约束，他也不能够提供像SQL所提供的where这种对于字段属性值情况的查询。并且难以体现设计的完整性。他只适合存储一些较为简单的数据，对于需要进行较复杂查询的数据，SQL数据库显的更为合适。

# 4. 关系型数据库  V.S.  非关系型数据库 #

关系型数据库的最大特点就是事务的一致性：传统的关系型数据库读写操作都是事务的，具有ACID的特点，这个特性使得关系型数据库可以用于几乎所有对一致性有要求的系统中，如典型的银行系统。

但是，在网页应用中，尤其是SNS应用中，一致性却不是显得那么重要，用户A看到的内容和用户B看到同一用户C内容更新不一致是可以容忍的，或者说，两个人看到同一好友的数据更新的时间差那么几秒是可以容忍的，因此，关系型数据库的最大特点在这里已经无用武之地，起码不是那么重要了。

相反地，关系型数据库为了维护一致性所付出的巨大代价就是其读写性能比较差，而像微博、facebook这类SNS的应用，对并发读写能力要求极高，关系型数据库已经无法应付(在读方面，传统上为了克服关系型数据库缺陷，提高性能，都是增加一级memcache来静态化网页，而在SNS中，变化太快，memchache已经无能为力了)，因此，必须用新的一种数据结构存储来代替关系数据库。

关系数据库的另一个特点就是其具有固定的表结构，因此，其扩展性极差，而在SNS中，系统的升级，功能的增加，往往意味着数据结构巨大变动，这一点关系型数据库也难以应付，需要新的结构化数据存储。

于是，非关系型数据库应运而生，由于不可能用一种数据结构化存储应付所有的新的需求，因此，非关系型数据库严格上不是一种数据库，应该是一种数据结构化存储方法的集合。

必须强调的是，数据的持久存储，尤其是海量数据的持久存储，还是需要一种关系数据库这员老将。

# 5. 非关系型数据库分类 #

由于非关系型数据库本身天然的多样性，以及出现的时间较短，因此，不想关系型数据库，有几种数据库能够一统江山，非关系型数据库非常多，并且大部分都是开源的。

这些数据库中，其实实现大部分都比较简单，除了一些共性外，很大一部分都是针对某些特定的应用需求出现的，因此，对于该类应用，具有极高的性能。依据结构化方法以及应用场合的不同，主要分为以下几类：

*  面向高性能并发读写的key-value数据库：

key-value数据库的主要特点即使具有极高的并发读写性能，Redis,Tokyo Cabinet,Flare就是这类的代表

*  面向海量数据访问的面向文档数据库：

这类数据库的特点是，可以在海量的数据中快速的查询数据，典型代表为MongoDB以及CouchDB

*  面向可扩展性的分布式数据库：

这类数据库想解决的问题就是传统数据库存在可扩展性上的缺陷，这类数据库可以适应数据量的增加以及数据结构的变化

转载自：[http://blog.sina.com.cn/s/blog\_4c6e822d0102e50m.html][http_blog.sina.com.cn_s_blog_4c6e822d0102e50m.html]

**关系型数据库与Key-value型数据库Mongodb模式设计对比**

MongoDb相比于传统的SQL关系型数据库，最大的不同在于它们的模式设计（Schema Design）上的差别，正是由于这一层次的差别衍生出其它各方面的不同。

我们可以简单的认为关系型数据库由数据库、表（table）、记录（record）三个层次概念组成，而在构建一个关系型数据库的时候，工作重点和难点都在数据库表的划分与组织上。一般而言，为了平衡提高存取效率与减少数据冗余之间的矛盾，设计的数据库表都会尽量满足所谓的第三范式。相对的，可以认为MongoDb由数据库、集合（collection）、文档对象（Document-oriented、BSON）三个层次组成。MongoDb里的collection对应于关系型数据库里的表。当然，不要期望collection会满足所谓的第三范式，因为它们根本就不在同一个概念讨论之内。类似于表由多条记录组成，集合也包含多个文档对象，虽然说一般情况下，同一个集合内的文档对象具有相同的格式定义，但这并不是必须的，即MongoDb的数据模式是自由的（schema-free、模式自由、无模式）。

以一实例来说，假设我们需要设计一个小型数据库来存储“学生、地址、科目、成绩”这些信息，那么关系型数据库的设计如图1所示，而Key-value型数据库的设计则可能如图2所示。

![关系型数据库与Key-value型数据库Mongodb模式设计对比][Key-value_Mongodb]

图1、关系型的数据库设计

![关系型数据库与Key-value型数据库Mongodb模式设计对比][Key-value_Mongodb 1]

图2、Key-value型的数据库设计（直接借用的mongodb官方图）

对比图1和图2，在关系型的数据库设计里划分出了4个表，而在Key-value型的数据库设计里却只有两个集合。如果说集合与表一一对应的话，那么图2中应该也有4个集合才对，为什么可以把本应该是集合的address和scores直接合入了集合students中？原因就在于在Key-value型的数据库里，数据模式是自由的。

以scores来说，在关系型的数据库设计中将其单独成一个表是因为student与score是一对多的关系，如果将score合入student表，那么就必须预留最多可能的字段，这会存在浪费，并且当以后新增一门课程时扩展困难，因此一般都会将score表单独出来。而对于Key-value型的数据库就不同了，其scores字段就是一个BSON，该BSON可以只有一个for\_course，也可以有两个、三个、任意个for\_course，其固有的模式自由特性使得它可以将score包含在内而无需另建一个score集合。

对于与student为一对一关系的address表也可以直接合入student，无需担心address的扩展性，当以后需要给address新增一个province字段，直接在数据插入时加上这个值即可。

当然，对于与student成多对多关系course表，为了减少数据冗余，可以将course建立为一个集合，同关系型的数据库设计中类似。

对比于关系型的数据库，在Key-value型的数据库里将数据合入一起有几大好处：首先，数据检索时没有了进行表间连接（join）的巨大开销（虽然目前MongoDb中没有join的概念）；其次，合入一起的数据在磁盘上的存放也更容易在一起，因此数据的读取/写入都更快速。另外，无需担心扩展性问题，Key-value型数据库的自身特性使得字段的增删改十分容易。

[http_blog.csdn.net_robinjwong_article_details_18502195]: http://blog.csdn.net/robinjwong/article/details/18502195
[http_blog.sina.com.cn_s_blog_4c6e822d0102e50m.html]: http://blog.sina.com.cn/s/blog_4c6e822d0102e50m.html
[Key-value_Mongodb]: /images/20220731/e0e0b86b81b447018c1eb01cbde754b6.png
[Key-value_Mongodb 1]: /images/20220731/9f46646e4b374b1ca8cc8a03f6ba76fe.png