NOSQL简介

单机关系型数据库时代（以Mysql为例）

以前一个网站的访问量和数据量不大的时候，一个关系型数据库完全能搞定：

但是这样的架构，随着用户量/访问量的剧增，不但性能得不到保证，几乎大部分这样的单个关系型数据库基本上面临的都是宕机，崩溃不可用。

现在随着用户量的增加，人们注重功能的同时也开始追求性能。所以开始大量的使用了缓存技术来缓解数据库的压力。

刚开始的时候都采用的是文件缓存来缓解数据库的压力。但是在高并发的时候，多台服务器之间不能文件缓存共享，大量的小的缓存文件也导致了IO读写压力。在这种情况下就促使缓存服务器的出现与流行。

Memcahed：

Memcached是一个独立的分布式缓存服务器。Memcached为多个业务服务器提供一个共性能的共享缓存数据服务。后台人们又发现一个Memcached有出现了性能上的瓶颈，所以又根据hash算法来进行多台memcached缓存服务的扩展，然后又出现了hash算法来解决增加或减少缓存服务器导致重新hash带来的大量缓存失效的弊端。

数据库的主从复制，读写分离

虽然Memcacehed服务器做到了为业务服务器做了缓存读写的压力，但是读写两个操作却是集中在一个数据库上的。这让数据库既要读操作，也要写操作。这样让数据库也不堪重负。所以我们采用了主从复制的技术来达到读写分离，用来提高数据库的读写性能。数据库（mysql)的Master-slave模式成为了业务服务器的架构的标配。

分库分表，水平拆分，mysql数据库集群

随着数据量的增大，数据库，表中的数据越来越多，性能也越来越慢，所以此时又引发了一个数据库的新概念：水平拆分，分库分表，让数据哭形成集群。性能虽有欠缺，但是可靠性确实得到了保证。

mysql推出了Mysql cluster：

进阶后的服务器情况

关系型数据的扩展性局限

1.不管采取了上面的那些措施，但是最终数据都还是存储在数据中的，但是存储一些比较大数据时，如文本，如果数据库出现问题，或是做数据备份，恢复的时候非常的慢，因为受到各种关系的限制。因为关系型数据库存储大量的数据本就不是强项.

2.并且大数据的处理对io的的压力也很大。

3.后期的表结构想要做改变和扩展确实也是非常困难

4.如果要处理非常复杂关系的时候，就会很难出维护和存储。

如：小明大姑的小姨的哥哥的媳妇的妹妹的弟弟。

为什么要用NOSQL

因为随着大数据的出现，关系型数据库再也不能满足我们需求。如：我们想要对很复杂的数据抓取比并且分析，但是我们事先也不知道里面的数据结构。数据结构和分析的方向和对象都是可能随时改变的。

什么是NOSQL

nosql并不是不是sql，而是不仅仅是sql。是非关系型数据库。它可是在大数据时代，对数据结构没有特殊的标准，可以很好的横向扩展。这与大数据的挖掘和分析很是契合。这同样也是大数据所不具备的。

NOSql能干什么

1.易扩展

它的特点就是去掉了传统关系型数据库的关系。数据之间基本是没有关系关联，横向也没有限制，所以可能随时横向，纵向的扩展。

2.数据读写效率很高

因为它的数据之间是无关系限制的，所以操作数据的效率非常的高，是关系型数据库所不能比拟的。

3.数据无规则性

存储数据之前不需要像关系型数据库一样做一些规则来规定数据的格式，存储的方式，数据关联，等等。而nosql突破了这个限制。

4.RDBMS 和NOSQL的对比

RDBMS：

1.高度结构化，组织化的规则

2.使用组织化的查询语言（sql）

3.数据表之间的关系，也是用数据表存储的，操作数据表的时候，需要知道之间的关系。

4.严格的一致性

5.基础事务

6.数据库定义语言，数据库操作语言

NOSQL：

1.无规则存储方式，非结构化和不可预知

2.没有预定义数据表和格式

3.没有特定的操作规则

4.使用键值存储

5.最终一致性

6.CAP定理，高可用，高性能

大数据时代下有“3v现象”和“3高要求“

3v是指：海量（volume），实时（va'riety），多样（velocity）

3高：高并发，高性能，高扩展（高可扩）

大家都是在阿里巴巴一直都是行业内的技术标杆，我们就以淘宝看一个例子：

看看淘宝首页以女装和女包为例：

我们来看看这个架构的演变过程：

这好像没看出来和我们这次要说的nosql有什么关系？好

和我们相关的多数据源多数据类型的存储问题做做讨论：

1.商品基本信息（名称，价格，出产日期，生产厂商等）：关系型数据库mysql/oracle目前淘宝在去O化（也即拿掉Oracle),淘宝内部用的Mysql是里面的大牛自己改造过的。

为什么要去掉了IOE：

2008年，王坚加盟阿里巴巴成为集团首席架构师，即现在的首席技术官。这位前微软亚洲研究院常务副院长被马云定位为：将帮助阿里巴巴集团建立世界级的技术团队，并负责集团技术架构以及基础技术平台搭建。

在加入阿里后，带着技术基因和学者风范的王坚就在阿里巴巴集团提出了被称为“去IOE”（在IT建设过程中，去除IBM小型机、Oracle数据库及EMC存储设备）的想法，并开始把云计算的本质，植入阿里IT基因。

王坚这样概括“去IOE”运动和阿里云之间的关系：“去IOE”彻底改变了阿里集团IT架构的基础，是阿里拥抱云计算，产出计算服务的基础。“去IOE”的本质是分布化，让随处可以买到的Commodity PC架构成为可能，使云计算能够落地的首要条件。

2.商品描述，详情，评价信息（多文字类）：因为多文字描述类，IO的读写性能变差，所以使用文档数据库MongoDB数据库

3.商品的图片：使用了分布式的文件系统中（淘宝自己的TFS，Google的GFS，Hadoop的HDFS）

4.商品的关键字搜索（搜索引擎，淘宝内用）：ISearch

5.商品波段性热点信息高频信息（比如双11的时候）：内存数据库（Tair，Redis，Memecached）

6.商品的交易，价格计算，积分积累：外部系统，外部第三方支付接口 --- 支付宝

总结：总结大型互联网应用（大数据，高并发，多样数据类型）的难点和解决方案：

难点：

1.数据类型的多样性

2.数据源的多样化和变化重构

3.数据源改造而数据服务平台不需要大面积重构

解决方案：

1.淘宝采用的是UDSL

UDSL是什么？

UDSL是什么样的？

UDSL的使用：

1.映射

2.API

3.热点缓存

NOSQL数据模型的概述

枯燥说概念没意思，还是以实例来说吧！

以一个电商客户，订单，订购，地址模型来对比RDBMS和NOSQL数据库：

RDBMS设计：

1：1/1：N/N:N，主外键等：

NOSQL的设计：

使用BSON：先解释一下什么是BSON，BSON和JSON是差不多的，简单的来说是一中二进制形式的存储格式：Binary JSON,简称BSON，和json一样支持内嵌的文档对象和数组对象。

设计（BSON格式）：

{

"customer":{

"id":1136,

"name":"Z3",

"billingAddress":[{"city":"beijing"}],

"orders":[

{

"id":17,

"customerId":1136,

"orderItems":[{"productId":27,"price":77.5,"productName":"thinking in java"}],

"shippingAddress":[{"city":"beijing"}]

"orderPayment":[{"ccinfo":"111-222-333","txnid":"asdfadcd334","billingAddress":{"city":"beijing"}}],

}

]

}

}

用这样的一个BSON去描绘前面的关系型数据中的种种关系所限的存储关系和数据。也不需要提前去设计数据库和表，存储后面的数据的时候不会有前面的BSON限制。

两者对比一下，问题和难点：

为什么上述的情况可以用聚合模型（随后就说）来处理的原因：

1.高并发的操作是不太建议有关联查询的， 互联网公司用冗余数据来避免关联查询

2.分布式事务是支持不了太多的并发的

大家好好想想关系模型数据库你如何查？ 如果按照我们新设计的BSon，是不是查询起来很好呢？

聚合模型：

1.KV键值：不解释了，这相信大家都知道吧

2.BSON：BSON上面已经解释过来，就不重复了

3.列族：就是按列存储数据，最大的特点就是方便存储结构化和板结构化数据，方便做数据压缩，针对某一列和某几列的查询有非常大的IO优势。

4.图形：

NOSQL数据库的四大分类

1.KV键值

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

3.列存储数据库

4.图关系数据库

KV键值：

1.新浪：BerkeleyDB+Redis

2.美团：redis+tair

3.阿里，百度：memecached+redis

文档数据库：

1.CouchDB

2.MongoDB

列存储数据库：

1.Cassandra，HBase

2.（各大巨头的）分布式文件系统

图关系数据库：

1.首先纠正一下大家的认知：不是用来存放图形的。

2.使用用来存放的是关系，如：朋友圈的社交网络，广告推荐系统。它着重维护关系图谱。

3.Neo4J，InfoGrid

四者对比：

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

传统意义上的ACID分别是什么？

学过数据库的人可能会知道是四个特性：关系型数据库遵循ACID规则：

事务在英文中是transaction，和现实世界中的交易很类似，它有如下四个特性：

1、A (Atomicity) 原子性

原子性很容易理解，也就是说事务里的所有操作要么全部做完，要么都不做，事务成功的条件是事务里的所有操作都成功，只要有一个操作失败，整个事务就失败，需要回滚。比如银行转账，从A账户转100元至B账户，分为两个步骤：1）从A账户取100元；2）存入100元至B账户。这两步要么一起完成，要么一起不完成，如果只完成第一步，第二步失败，钱会莫名其妙少了100元。

2、C (Consistency) 一致性

一致性也比较容易理解，也就是说数据库要一直处于一致的状态，事务的运行不会改变数据库原本的一致性约束。

3、I (Isolation) 独立性

所谓的独立性是指并发的事务之间不会互相影响，如果一个事务要访问的数据正在被另外一个事务修改，只要另外一个事务未提交，它所访问的数据就不受未提交事务的影响。比如现有有个交易是从A账户转100元至B账户，在这个交易还未完成的情况下，如果此时B查询自己的账户，是看不到新增加的100元的

4、D (Durability) 持久性

持久性是指一旦事务提交后，它所做的修改将会永久的保存在数据库上，即使出现宕机也不会丢失。

前面提到了CAP大家可能有点懵吧，那CAP又是什么呢？

CAP其实就是NOSQL的三大特性：

C：Consistency（强一致性）

A：Aviailability（可用性）

P：Partition tolerance（分区容错性）

但是大数据时代下的CAP却最多只能保留两项：所以就出现了“CAP 3进2”：

CAP 3进2：

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

而由于当前的网络硬件肯定会出现延迟丢包等问题，所以

分区容忍性是我们必须需要实现的。

所以我们只能在一致性和可用性之间进行权衡，没有NoSQL系统能同时保证这三点。

=======================================================================================================================

C:强一致性 A：高可用性 P：分布式容忍性

CA 传统Oracle数据库

AP 大多数网站架构的选择

CP Redis、Mongodb

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

一致性和可用性之间取一个平衡。多余大多数web应用，其实并不需要强一致性。

因此牺牲C换取P，这是目前分布式数据库产品的方向

=======================================================================================================================

一致性与可用性的决择

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

数据库事务一致性需求

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

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

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

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

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

写了这么多文字，大家可能不太喜欢看，画个CAP图：

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

最多只能同时较好的满足两个。

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

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

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

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

BASE是什么？

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

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

基本可用（Basically Available）

软状态（Soft state）

最终一致（Eventually consistent）

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

分布式+集群

分布式系统

分布式系统（distributed system）

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

简单来讲：

1分布式：不同的多台服务器上面部署不同的服务模块（工程），他们之间通过Rpc/Rmi之间通信和调用，对外提供服务和组内协作。

2集群：不同的多台服务器上面部署相同的服务模块，通过分布式调度软件进行统一的调度，对外提供服务和访问。

未完待续........