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

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

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

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