Redis之NoSql入门和概述(二)

2. 什么是NoSQL？

   2.1 NoSQL 概述

   NoSQL(NoSQL = Not Only SQL )，意即“不仅仅是SQL”，泛指非关系型的数据库。随着互联网web2.0网站的兴起，传统的关系数据库在应付web2.0网站，特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经显得力不从心，暴露了很多难以克服的问题，而非关系型的数据库则由于其本身的特点得到了非常迅速的发展。NoSQL数据库的产生就是为了解决大规模数据集合多重数据种类带来的挑战，尤其是大数据应用难题，包括超大规模数据的存储

 2.2常用的NoSql数据库

   NoSQL数据库种类繁多，这些类型的数据存储不需要固定的模式，无需多余操作就可以横向扩展，常用的Redis、Memcache、Mongdb、Hbase等。

  2.3NoSql数据库特点

   *易扩展

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

    *大数据量高性能

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

  *多样灵活的数据模型

       NoSQL无需事先为要存储的数据建立字段，随时可以存储自定义的数据格式。而在关系数据库里，增删字段是一件非常麻烦的事情。如果是非常大数据量的表，增加字段简直就是一个噩梦

2.4NOSql数据库与关系型数据库比较

	NoSql数据库	关系型数据库
比较	- 代表着不仅仅是SQL - 没有声明性查询语言 -无预定义的模式（数据格式） -键 - 值对存储，列存储，文档存储，图形数据库 - 最终一致性，而非ACID属性 - 非结构化和不可预知的数据 - CAP定理 - 高性能，高可用性和可伸缩性	- 高度组织化结构化数据 - 结构化查询语言（SQL） - 数据和关系都存储在单独的表中。 - 数据操纵语言，数据定义语言 - 严格的一致性 - 基础事务

2.4在分布式数据库中CAP原理CAP+BASE

    2.4.1传统的ACID分别是什么？

      事务在当今的企业系统无处不在，即使在高并发环境下也可以提供数据的完整性。一个事务是一个只包含所有读/写操作成功的集合 ，一句话就是多条SQL语句，要么所有执行成功，要么所有执行失败。ACID也就是事务的四个特点（原则）

      原子性（Atomicity）

           原子性是指事务是一个不可分割的工作单位，事务中的操作要么都发生，要么都不发生。

     一致性（Consistency）

         事务前后数据的完整性必须保持一致。

     隔离性（Isolation）

        事务的隔离性是多个用户并发访问数据库时，数据库为每一个用户开启的事务，不能被其他事务的操作数据所干扰，多个并发事务之间要相互隔离。

    持久性（Durability）

      持久性是指一个事务一旦被提交，它对数据库中数据的改变就是永久性的，接下来即使数据库发生故障也不应该对其有任何影响

     2.4.2CAP原理

    CAP原则又称CAP定理，指的是在一个分布式系统中，一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）。CAP 原则指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。

    一致性（C）

     是指更新操作成功并返回客户端后，所有节点在同一时间的数据完全一致，这就是分布式的一致性。一致性的问题在并发系统中不可避免，对于客户端来说，一致性指的是并发访问时更新过的数据如何获取的问题。从服务端来看，则是更新如何复制分布到整个系统，以保证数据最终一致。

    可用性（A）

      服务一直可用，而且是正常响应时间。好的可用性主要是指系统能够很好的为用户服务，不出现用户操作失败或者访问超时等用户体验不好的情况。

  分区容错性（P）：

     即分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性或可用性的服务。分区容错性要求能够使应用虽然是一个分布式系统，而看上去却好像是在一个可以运转正常的整体。比如现在的分布式系统中有某一个或者几个机器宕掉了，其他剩下的机器还能够正常运转满足系统需求，对于用户而言并没有什么体验上的影响。

2.4.3CAP的3进2原则

     CAP理论就是说在分布式存储系统中，最多只能实现上面的两点。也就是说要么AP，要么CP，要么AC，不存在CAP，

    但是而由于当前的网络硬件肯定会出现延迟丢包等问题，所以分区容忍性是我们必须需要实现的。所以我们只能在一致性和可用性之间进行权衡，要么AP，要么CP

备注：分布式架构的时候必须做出取舍，一致性和可用性之间取一个平衡。多余大多数web应用，其实并不需要强一致性。因此牺牲C换取P，这是目前分布式数据库产品的方向

2.4.4 经典CAP图

   CAP理论的核心是：一个分布式系统不可能同时很好的满足一致性，可用性和分区容错性这三个需求，最多只能同时较好的满足两个。

  根据 CAP 原理将 NoSQL 数据库分成了满足 CA 原则、满足 CP 原则和满足 AP 原则三 大类：

   CA - 单点集群，满足一致性，可用性的系统，通常在可扩展性上不太强大。

   CP - 满足一致性，分区容忍必的系统，通常性能不是特别高。

   AP - 满足可用性，分区容忍性的系统，通常可能对一致性要求低一

 

2.4.5一致性与可用性的决择

 CA 传统Oracle数据库    AP 大多数网站架构的选择    CP Redis、Mongodb

对于web2.0网站来说，关系数据库的很多主要特性却往往无用武之地

 数据库事务一致性需求 

　　很多web实时系统并不要求严格的数据库事务，对读一致性的要求很低， 有些场合对写一致性要求并不高。允许实现最终一致性。

数据库的写实时性和读实时性需求

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

对复杂的SQL查询，特别是多表关联查询的需求 

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