Redis-01-NoSql介绍

01，Mysql技术的演进

1.1，单机MySQL架构

• DAL：Data Access Layer（数据存取层）

特点：

• 在90年代，一个网站的浏览量一般都不大，用单个数据库完全可以轻松应付， 在那个时候，更多的都是静态网页，动态交互类型的网站不多。

问题：

• 当数据量太大一个机器放不下是怎么办？
• 当数据索引(B+ Tree)一个机器的内存放不下时怎么办？
• 当浏览量(读写混合)大到一个实例不能承受时怎么办？

1.2，Memcached(缓存)+MySQL+垂直拆分架构

• 随着网站浏览量的增多，几乎大部分使用单机MySQL架构的网站在数据库方面都开始出现了性能问题

特点：

• web程序不再仅仅专注在功能业务，同时也在追求性能。
• 程序员们开始大量的使用缓存技术来缓解数据库的压力，优化数据库的结构和索引，开始比较流行的是通过文件缓存来缓解数据库压力

问题：

• 当浏览量继续增大的时候，并且文件缓存不能共享，大量的小文件缓存也带了了比较高的IO压力
• 拆分之后，不同的数据库存储不同的信息，例如上图中的用户信息和其他信息的存储在不同的数据库

1.3，Mysql主从读写分离

• 由于数据库的写入压力增加，Memcached 只能缓解数据库的读取压力，读写集中在一个数据库上让数据库不堪重负。

特点

• 大部分网站开始使用主从复制技术来达到读写分离，以提高读写性能和读库的可扩展性，
• Mysql的master-slave模 式成为这个时候的网站标配

1.4，分表分库+水平拆分+mysql集群

• 在Memcached的高速缓存，MySQL的主从复制， 读写分离的基础之上，这时MySQL主库的写压力开始出现瓶颈，而数据量的持续猛增，由于MyISAM使用表锁，在高并发下会出现严重的锁问题，大量的高并发MySQL应用开始使用InnoDB引擎代替MyISAM。

特点

• 分表分库来缓解写压力和数据增长的扩展问题

1.5，今天是什么样子？

02，MySQL的扩展性瓶颈

MySQL数据库也经常存储一些大文本字段，导致数据库表非常的大，在做数据库恢复的时候就导致非常的慢，不容易快速恢复数据库。比如1000万4KB大小的文本就接近40GB的大小， 如果能把这些数据从MySQL省去，MySQL将变得非常的小。关系数据库很强大，但是它并不能很好的应付所有的应用场景。MySQL的扩展性差(需要复杂的技术来实现)，大数据下IO压力大，表结构更改困难，正是当前使用MySOL的开发人员面临的问题。、

03，NoSQL

3.1，什么是NoSql

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

3.2，Nosql的特点

• 对于NoSQL并没有一个明确的范围和定义，但是他们都普遍存在下面一些共同特征：

1，易扩展

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

2，大数据量，高性能

• NoSQL数据库都具有非常高的读写性能，尤其在大数据量下，同样表现优秀。这得益于它的无关系性，数据库的结构简单。
• 一般MySQL使用Query Cache。NoSQL的Cache是记录级的，是一种细粒度的Cache，所以NoSQL在这个层面上来说性能就要高很多

3，灵活的数据模型

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

4，高可用

• NoSQL在不太影响性能的情况，就可以方便地实现高可用的架构。比如Cassandra、HBase模型，通过复制模型也能实现高可用。

3.3，NoSql VS RDBMS

RDBMS：关系型数据库管理系统

• 高度组织化结构化数据
• 结构化查询语言(SQL)
• 数据和关系都存储在单独的表中
• 数据操纵语言，数据定义语言
• 严格的一致性
• 基础事务

NoSQL

• 代表着不仅仅是SQL
• 没有声明性查询语言
• 没有预定义的模式
• 键-值对存储，列存储，文档存储，图形数据库
• 最终一致性，而非ACID属性
• 非结构化和不可预知的数据:
• CAP定理
• 高性能，高可用性和可伸缩性

3.4，NoSql数据库种类

• Memcached
• Redis
• MongDB

3.4，补充

NoSql的使用：

• KV：键值对
• Cache：缓存
• Persistence：持久化

现代数据的特点以及访问的特点：3V + 3高

• 大数据时代的3V：

  • 海量Volume
  • 多样Variety
  • 实时Velocity

• 互联网需求的3高：

  • 高并发
  • 高可括
  • 高性能

04，NoSQL数据模型简介

以一个电商客户、订单、订购、地址模型来对比关系型数据库和非关系型数据库

• 统关系型数据库如何设计：
  关系型数据库表与表之间的关系有：一对一，一对多，多对多，多对一
  
• NOSQL如何设计：
  BSON ()是一种类json的一种二进制形式的存储格式，简称Binary JSON，它和JSON一样，支持内嵌的文档对象和数组对象

{	"customer":{
	"id":1136,
	"name":"AISMALL",
	"bilingAddress":[{"city":"henan"}],
	"orders":[
	{
		"id":17,
		"customerId":1136
		"orderItems":["productId":27,"price":77.5,"productName":"doll"],
		"shippingAddrss":[{"city":"henan"}],
		"orderPayment":[{"ccinfo":"111-222-333","txnid":"asdafd123","bilingAddress":{"city":"henan"}}]
		}
	]
		}
	}
}

• 通过上面的观察NoSql对多数据源的处理更加方遍，相比于关系型数据库来说，非关系型数据库更加易拓展

聚合模型：KV，BSON，列族，图形

• KV
• BSON
• 列族，顾名思义，是按列存储数据的。最大的特点是方便存储结构化和半结构化数据，方便做数据压缩，对针对某一 列或者某几列的查询有非常大的IO优势
  
• 图形
  

05，NoSQL数据库的四大分类

1，KV

• 新浪：BerkeleyDB + Redis
• 美团：Redis + tair
• 阿里、百度：memcache + Redis

2，文档型数据库（BSON格式比较多）

• CouchDB
• MongoDB
  MongoDB是一个基于分布式文件存储的数据库。由C++语言编写。旨在为WEB应用提供可扩展的高性能数据存储解决方案。
  MongoDB是一个介于关系数据库和非关系数据库之间的产品，是非关系数据库当中功能最丰富，最像关系数据库的。

3，列存储数据库

• Cassandra、HBase
• 分布式文件系统

4，图关系数据库

• 它不是放图形的、放的是关系比如：朋友圈社交网络、广告推荐系统
• 社交网络、推荐系统。专注于构建关系图谱
• Neo4j、InfoGrid

四者对比：

06，分布式数据库CAP原理：CAP+BASE

关系型数据库回顾

关系型数据库遵循ACID规则，事务在英文中是transaction，和现实世界中的交易很类似，它有如下四个特性：

• A (Atomicity) 原子性
• C (Consistency) 一致性
• I (Isolation) 独立性
• D (Durability) 持久性
• 1、A (Atomicity) 原子性 原子性很容易理解，也就是说事务里的所有操作要么全部做完，要么都不做，事务成功的条件是事务里的所有操作都成功，只要有一个操作失败，整个事务就失败，需要回滚。比如银行转账，从A账户转100元至B账户，分为两个步骤：1）从A账户取100元；2）存入100元至B账户。这两步要么一起完成，要么一起不完成，假如只完成第一步，第二步失败，A账户的钱会莫名其妙少了100元，而B账户没收到钱，结果可想而知。
• 2、C (Consistency) 一致性 一致性也比较容易理解，也就是说数据库要一直处于一致的状态，事务的运行不会改变数据库原本的一致性约束。
• 3、I (Isolation) 独立性 所谓的独立性是指并发的事务之间不会互相影响，如果一个事务要获取的数据正在被另外一个事务修改，只要另外一个事务未提交，它所获取的数据就不受未提交事务的影响。比如现有有个交易是从A账户转100元至B账户，在这个交易还未完成的情况下，如果此时B查询自己的账户，是看不到新增加的100元的，
• 4、D (Durability) 持久性 持久性是指一旦事务提交后，它所做的修改将会永久的保存在数据库上，即使服务器出现宕机也不会丢失。

数据库的CAP

• 虽然分布式数据库是数据库发展的方向，但并不是说一定要用分布式
• 很多NoSQL都是分布式的，但是很多中小型系统的都没用用到分布式的特性

CAP：

• C:Consistency（强一致性）
• A:Availability（可用性）
• P:Partition tolerance（分区容错性）

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

而由于当前的网络硬件肯定会出现延迟丢包等问题，所以分区容忍性是我们必须需要实现的。所以我们只能在一致性和可用性之间进行权衡，没有NoSQL系统能同时保证这三点。

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

注意：使用分布式架构的时候必须做出取舍。

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

一致性与可用性如何选择 ？：

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

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

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

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

• 总结：综上面所述，就可以推出为什么大多数网站选择AP型结构（高可用+分区容错性）的原因了，因为一致性的需求并不是那么高，能实现最终一致性即可，下面的BASE就是这种原理的体现，解决由于高一致性而引起的高可用性降低的问题。

经典CAP图：

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

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

• CA ：单点集群，满足一致性，可用性的系统，通常在可扩展性上不太强大。
• CP ：满足一致性，分区容忍必的系统，通常性能不是特别高。
• AP ：满足可用性，分区容忍性的系统，通常可能对一致性要求低一些

BASE

BASE就是为了解决关系数据库强一致性问题而引起的可用性降低而提出的解决方案。

BASE其实是下面三个术语的缩写：

• 基本可用（Basically Available）
• 软状态（Soft state）
• 最终一致（Eventually consistent）

它的思想是通过让系统放松对某一时刻数据一致性的要求来换取系统整体伸缩性和性能上改观。为什么这么说呢，缘由就在于大型系统往往由于地域分布和极高性能的要求，不可能采用分布式事务来完成这些指标，要想获得这些指标，我们必须采用另外一种方式来完成，这里BASE就是解决这个问题的办法

分布式+集群简介

分布式系统（distributed system）：

• 由多台计算机和通信的软件组件通过计算机网络连接（本地网络或广域网）组成。
• 分布式系统是建立在网络之上的软件系统。正是因为软件的特性，所以分布式系统具有高度的内聚性和透明性。
• 因此，网络和分布式系统之间的区别更多的在于高层软件（特别是操作系统），而不是硬件。
• 分布式系统可以应用在在不同的平台上如：PC、工作站、局域网和广域网上等。

简单来讲：

• 分布式：不同的多台服务器上面部署不同的服务模块（工程），他们之间通过Rpc/Rmi之间通信和调用，对外提供服务和组内协作。
• 集群：不同的多台服务器上面部署相同的服务模块，通过分布式调度软件进行统一的调度，对外提供服务和连接。