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的功能被极大的弱化了。