RDBMS 关系型数据库与 NoSQL 全面比较

         随着互联网的不断发展，各类类型的应用层出不穷，因此致使在这个云计算的时代，对技术提出了更多的需求，主要体如今下面这四个方面： 
         低延迟的读写速度：应用快速地反应能极大地提高用户的满意度; 
         支撑海量的数据和流量：对于搜索这样大型应用而言，须要利用PB级别的数据和能应对百万级的流量; 
         大规模集群的管理：系统管理员但愿分布式应用能更简单的部署和管理;
         庞大运营成本的考量：IT经理们但愿在硬件成本、软件成本和人力成本可以有大幅度地下降;

1、关系型数据库

         关系型数据库，是指采用了关系模型来组织数据的数据库。关系模型是在1970年由IBM的研究员E.F.Codd博士首先提出的，在以后的几十年中，关系模型的概念获得了充分的发展并逐渐成为主流数据库结构的主流模型。
         简单来讲，关系模型指的就是二维表格模型，而一个关系型数据库就是由二维表及其之间的联系所组成的一个数据组织。

关系模型中经常使用的概念

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

关系型数据库的优势

• 容易理解：二维表结构是很是贴近逻辑世界的一个概念，关系模型相对网状、层次等其余模型来讲更容易理解
• 使用方便：通用的SQL语言使得操做关系型数据库很是方便
• 易于维护：丰富的完整性(实体完整性、参照完整性和用户定义的完整性)大大减低了数据冗余和数据不一致的几率
• ACID，多表关联，复杂的数据分析类SQL查询。
• 事务处理—保持数据的一致性；
• 因为以标准化为前提，数据更新的开销很小（相同的字段基本上只有一处）；
• 能够进行Join等复杂查询

        虽然关系型数据库已经在业界的数据存储方面占据不可动摇的地位，可是因为其天生的几个限制，使其很难知足上面这几个需求 

• 扩展困难：因为存在相似Join这样多表查询机制，使得数据库在扩展方面很艰难; 
• 读写慢：这种状况主要发生在数据量达到必定规模时因为关系型数据库的系统逻辑很是复杂，使得其很是容易发生死锁等的并发问题，因此致使其读写速度下滑很是严重; 
• 成本高：企业级数据库的License价格很惊人，而且随着系统的规模，而不断上升; 
• 有限的支撑容量：现有关系型解决方案还没法支撑Google这样海量的数据存储; 

关系型数据库瓶颈

        高并发读写需求：网站的用户并发性很是高，每每达到每秒上万次读写请求，对于传统关系型数据库来讲，硬盘I/O是一个很大的瓶颈（随机I/O）；
        海量数据的高效率读写：网站天天产生的数据量是巨大的，对于关系型数据库来讲，在一张包含海量数据的表中查询，效率是很是低的；
        高扩展性和可用性：在基于web的结构当中，数据库是最难进行横向扩展的，当一个应用系统的用户量和访问量与日俱增的时候，数据库却没有办法像web server和app server那样简单的经过添加更多的硬件和服务节点来扩展性能和负载能力。对于不少须要提供24小时不间断服务的网站来讲，对数据库系统进行升级和扩展 是很是痛苦的事情，每每须要停机维护和数据迁移。
        对网站来讲，关系型数据库的不少特性再也不须要了：
        事务一致性：关系型数据库在对事物一致性的维护中有很大的开销，而如今不少web2.0系统对事物的读写一致性都不高
        读写实时性：对关系数据库来讲，插入一条数据以后马上查询，是确定能够读出这条数据的，可是对于不少web应用来讲，并不要求这么高的实时性，好比发一条消息以后，过几秒乃至十几秒以后才看到这条动态是彻底能够接受的
        复杂SQL，特别是多表关联查询：任何大数据量的web系统，都很是忌讳多个大表的关联查询，以及复杂的数据分析类型的复杂SQL报表查询，特别是SNS类型的网站，从需求以及产品阶级角度，就避免了这种状况的产生。每每更多的只是单表的主键查询，以及单表的简单条件分页查询，SQL的功能极大的弱化了
        SNS （Social Networking Services 社交网络服务）专指社交网络服务，包括了社交软件和社交网站。
        CIO （Chief Information Officer 首席信息官）
        在关系型数据库中，致使性能欠佳的最主要缘由是多表的关联查询，以及复杂的数据分析类型的复杂SQL报表查询。为了保证数据库的ACID特性，咱们 必须尽可能按照其要求的范式进行设计，关系型数据库中的表都是存储一个格式化的数据结构。每一个元组字段的组成都是同样，即便不是每一个元组都须要全部的字段， 但数据库会为每一个元组分配全部的字段，这样的结构能够便于表与表之间进行连接等操做，但从另外一个角度来讲它也是关系型数据库性能瓶颈的一个因素。

2、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数 据库显的更为合适。

为什么要使用NoSQL数据库

        NoSQL具备灵活的数据模型，能够处理非结构化/半结构化的大数据
        面对丰富多样的数据，构建的应用须要使用很是灵活的数据存储系统，可以轻松容纳新的数据类型，而且不会被第三方数据提供商内容结构的变化所累。NoSQL提供的数据模型则能很好地知足这种需求。经过这种灵活性存储数据而无需修改表或是建立更多的列。很是适合于建立原型或是快速应用，这种灵活性使得新特性的开发变得很是容易。
        NoSQL很容易实现可伸缩性（向上扩展与水平扩展）
RDBMS是中心化的，向上扩展而非水平扩展的。这使得他们不适合于那些须要简单且动态可伸缩性的应用。NoSQL数据库从一开始就是分布式、水平扩展的，所以很是适合于互联网应用分布式的特性。

动态模式

        关系型数据库须要在添加数据前先定义好模式。这对于敏捷开发模式来讲是场灾难，由于每次完成新特性时，数据库的模式一般都须要改变。

自动分片

        NoSQL数据库一般都支持自动分片，这意味着他们本质上就会自动在多台服务器上分发数据，应用甚至都不知道这些事情。数据与查询负载会自动在多台服务器上作到平衡，当某台服务器当机时，它能快速且透明地被替换掉。

复制

        大多数NoSQL数据库也支持自动复制，这意味着你能够得到高可用性与灾备恢复功能。从开发者的角度来看，存储环境本质上是虚拟化的。

易扩展

        NoSQL数据库种类繁多，可是一个共同的特色都是去掉关系数据库的关系型特性。数据之间无关系，这样就很是容易扩展。也无形之间，在架构的层面上带来了可扩展的能力。

大数据量，高性能

        NoSQL数据库都具备很是高的读写性能，尤为在大数据量下，一样表现优秀。这得益于它的无关系性，数据库的结构简单。通常MySQL使用Query Cache，每次表的更新Cache就失效，是一种大粒度的Cache，在针对web2.0的交互频繁的应用，Cache性能不高。而NoSQL的Cache是记录级的，是一种细粒度的Cache，因此NoSQL在这个层面上来讲就要性能高不少了。

灵活的数据模型

        NoSQL无需事先为要存储的数据创建字段，随时能够存储自定义的数据格式。而在关系数据库里，增删字段是一件很是麻烦的事情。若是是很是大数据量的表，增长字段简直就是一个噩梦。这点在大数据量的web2.0时代尤为明显。

高可用

        NoSQL在不太影响性能的状况，就能够方便的实现高可用的架构。好比Cassandra，HBase模型，经过复制模型也能实现高可用。

        简单的扩展：典型例子是Cassandra，因为其架构是相似于经典的P2P，因此能经过轻松地添加新的节点来扩展这个集群; 
        快速的读写：主要例子有Redis，因为其逻辑简单，并且纯内存操做，使得其性能很是出色，单节点每秒能够处理超过10万次读写操做; 
        低廉的成本：这是大多数分布式数据库共有的特色，由于主要都是开源软件，没有昂贵的License成本; 
        但瑕不掩瑜，NoSQL数据库还存在着不少的不足，常见主要有下面这几个： 
        不提供对SQL的支持：若是不支持SQL这样的工业标准，将会对用户产生必定的学习和应用迁移成本; 
        支持的特性不够丰富：现有产品所提供的功能都比较有限，大多数NoSQL数据库都不支持事务，也不像MS SQL Server和Oracle那样能提供各类附加功能，好比BI和报表等; 
        现有产品的不够成熟：大多数产品都还处于初创期，和关系型数据库几十年的完善不可同日而语; 

成熟度

        RDBMS系统由来已久。NoSQL拥护者们会说RDBMS的高龄是其衰退的标志，不过对于大多数CIO来讲，RDBMS的成熟让人放心。对于大多数状况来讲，RDBMS系统是稳定且功能丰富的。相比较而言，大多数NoSQL数据库则还有不少特性有待实现。

支持

        企业须要的是安心，若是关键系统出现了故障，他们能够得到即时的支持。全部RDBMS厂商都在竭尽全力地提供良好的企业支持。与之相反，大多数NoSQL系统都是开源项目，虽然每种数据库都有那么几家公司提供支持，不过这些公司大多都是小的初创公司，没有全球支持资源，也没有Oracle、微软或是IBM那种使人放心的公信力。

分析与商业智能

        NoSQL数据库在Web 2.0应用时代开始出现。所以，大多数特性都是面向这些应用的须要的。然而，应用中的数据对于业务来讲是有价值的，这种价值远远超出了Web应用那种CRUD。企业数据库中的业务信息能够帮助改进效率并提高竞争力，商业智能对于大中型企业来讲是个很是关键的IT问题。

管理

        NoSQL的设计目标是提供零管理的解决方案，不过当今的现实却离这个目标还相去甚远。如今的NoSQL须要不少技巧才能用好，而且须要很多人力、物力来维护。

适合使用NoSQL场景

        数据库表schema常常变化 
        好比在线商城，维护产品的属性常常要增长字段，这就意味着ORMapping层的代码和配置要改，若是该表的数据量过百万，新增字段会带来额外开销（重建索引等）。NoSQL应用在这种场景，能够极大提高DB的可伸缩性，开发人员能够将更多的精力放在业务层。
        数据库表字段是复杂数据类型
        对于复杂数据类型，好比SQL Sever提供了可扩展性的支持，像xml类型的字段。不少用过的同窗应该知道，该字段无论是查询仍是更改，效率很是通常。主要缘由是是DB层对xml字段很难建高效索引，应用层又要作从字符流到dom的解析转换。NoSQL以json方式存储，提供了原生态的支持，在效率方便远远高于传统关系型数据库。
        高并发数据库请求
        此类应用常见于web2.0的网站，不少应用对于数据一致性要求很低，而关系型数据库的事务以及大表join反而成了”性能杀手”。在高并发状况下，sql与no-sql的性能对比因为环境和角度不一样一直是存在争议的，并非说在任何场景，no-sql老是会比sql快。有篇article和你们分享下，http://artur.ejsmont.org/blog/content/insert-performance-comparison-of-nosql-vs-sql-servers
        海量数据的分布式存储
        海量数据的存储若是选用大型商用数据，如Oracle，那么整个解决方案的成本是很是高的，要花不少钱在软硬件上。NoSQL分布式存储，能够部署在廉价的硬件上，是一个性价比很是高的解决方案。

非关系型数据库分类

        因为非关系型数据库自己自然的多样性，以及出现的时间较短，所以，不想关系型数据库，有几种数据库可以一统江山，非关系型数据库很是多，而且大部分都是开源的。
        这些数据库中，其实实现大部分都比较简单，除了一些共性外，很大一部分都是针对某些特定的应用需求出现的，所以，对于该类应用，具备极高的性能。依据结构化方法以及应用场合的不一样，主要分为如下几类：

        

        面向高性能并发读写的key-value数据库：
        key-value数据库的主要特色即便具备极高的并发读写性能，Redis,Tokyo Cabinet,Flare就是这类的表明
        面向海量数据访问的面向文档数据库：
        这类数据库的特色是，能够在海量的数据中快速的查询数据，典型表明为MongoDB以及CouchDB
        面向可扩展性的分布式数据库：
        这类数据库想解决的问题就是传统数据库存在可扩展性上的缺陷，这类数据库能够适应数据量的增长以及数据结构的变化

        

3、RDBMS VS  NoSQL

        关系型数据库的最大特色就是事务的一致性：传统的关系型数据库读写操做都是事务的，具备ACID的特色，这个特性使得关系型数据库能够用于几乎全部对一致性有要求的系统中，如典型的银行系统。
        可是，在网页应用中，尤为是SNS应用中，一致性却不是显得那么重要，用户A看到的内容和用户B看到同一用户C内容更新不一致是能够容忍的，或者 说，两我的看到同一好友的数据更新的时间差那么几秒是能够容忍的，所以，关系型数据库的最大特色在这里已经无用武之地，起码不是那么重要了。
        相反地，关系型数据库为了维护一致性所付出的巨大代价就是其读写性能比较差，而像微博、facebook这类SNS的应用，对并发读写能力要求极 高，关系型数据库已经没法应付(在读方面，传统上为了克服关系型数据库缺陷，提升性能，都是增长一级memcache来静态化网页，而在SNS中，变化太 快，memchache已经无能为力了)，所以，必须用新的一种数据结构存储来代替关系数据库。
        关系数据库的另外一个特色就是其具备固定的表结构，所以，其扩展性极差，而在SNS中，系统的升级，功能的增长，每每意味着数据结构巨大变更，这一点关系型数据库也难以应付，须要新的结构化数据存储。
        因而，非关系型数据库应运而生，因为不可能用一种数据结构化存储应付全部的新的需求，所以，非关系型数据库严格上不是一种数据库，应该是一种数据结构化存储方法的集合。
        必须强调的是，数据的持久存储，尤为是海量数据的持久存储，仍是须要一种关系数据库这员老将。