Video在线视频

各位朋友大家好

欢迎来到我们的课堂

那么在之前的课程当中

我们介绍了大数据

这个计算的一些常用的模式

包括mapreduce

和这种in memory的data processing

我们介绍了大数据的

这个存储的模式

包括这种分布式的文件系统

那么在今天的课程中

我们会介绍一种新的

这种数据存储和计算的方法

叫做NoSql

那么NoSql的全名叫做Not Only SQL

大家知道Sql是数据库的一个概念

那么它是一个数据库的查询语言

能够让不能够编写代码的

这种数据分析师

通过一些抽象和高级的语言

进行数据的这个处理

今天我们会通过下面的

这几个模块来给大家介绍

在大数据的这个背景下

大家设计大数据的数据库

使用的一些基本的思路

以及我们通过一些流行系统

来给大家介绍NoSql

它的一些基本原理

和它的设计上的一些挑战

那么我们的课程的安排是这样的

我们会先介绍NoSql

或者说大数据的这种数据库

它起源的这样一个背景

以及它面临的挑战

和我们怎么样对这个问题

进行认识的

然后我们会介绍这个典型的

NoSql它设计的一些原则

我们会通过Google的

一个Big Table

来对一个真实的这种

大数据的数据库进行介绍

那么数据库的这个概念

其实已经有了几十年的时间

那么数据库来存储结构化的信息

然后给用户提供高效这种一致

然后比较复杂的

这种数据查询的一个方法

那么它数据库的一个概念

从最开始

几十年前的这样一个提出到今天

实际上已经发生了

比较大的这样一个演化

今天的数据库已经可以

处理更为复杂

它超越了原来的这种结构化

或者说这种schema要求的这样

一个数据的处理的这样一个要求

达到了今天对各种各样类型

数据处理的一个能力

同时它也能够横跨很多的

这个数据处理的节点

达到可扩展性

那么关系数据库它得到蓬勃发展

实际上也和web技术的

这个发展有关

尤其是处理Transaction

这种和交易和这种规划

相关的这种数据

带来了关系数据库的

一个迅速的一个发展

那么今天的关系数据库

又和其它的子系统进行了整合

比如说和前端的这个内存

和后端的这个分布式文件系统

进行有效的整合

实现了非常复杂的

这种数据处理的一个

数据库的一个模式

那么数据库在最开始设计的时候

实际上它的思路和我们

在很早以前提到过的

这种scale out

它的概念是匹配的

我们希望搭一个非常非常大的

一个系统

这个系统是一个完整

是一个单机的

那么在这样一个很大的系统

它拥有很多的这个C P U

很大的这个内存

那这样一个一致性可以

有效得到保证的一个环境下

我们去做sql的

这样一个支撑

这种思路底下随着数据

计算的复杂性

对分布式要求越来越高的

这样一个趋势下

实际上数据库面临的

一个核心的挑战

就是它怎么样去做这个扩容

怎么样使它能够在更多的机器

或者更多的设备上去运行

他不得不回到scale out的

这样一个思路之下

怎么样通过更多的服务器

使得原来的这个数据库

运行的范围更大

处理的数据的规模也更大

传统对关系数据库

它的这个scalability进行扩展

使用的技术通常可以划分成两类

第一类就是我们对整个架构

进行扩容

通过一个master slave的方式

我们通过中心的节点

进行关键性的控制

slave的节点进行

进行大规模请求的一个响应

或者我们对数据进行一个扩展

通过sharding或者是

partition的方式

我们能够将原来我们打算放在

一个数据库里的这些数据

把它切分成若干小的这个数据

放在不同的数据库里面

这些不同的数据库

可能在物理上就可以

得到天然的一个切分

我们来看看这些方法

那么基于master slave

我们对关系数据库

进行一个切分

会是什么样的一个情况

它通常的思路是这样的

我们会非常的重视一致性

关系数据库

我们会将写的过程给通过

master进行一个同步

这是设计的一个一般性的思路

而在数据库里面

我们更多的一个请求

可能是读的请求

我们会将读

把它这个distribute

到所有的这个slave节点上

使得读的响应

可以从原来的一台机器的容量

扩大到n台机器的一个容量

由于把读和写

进行了这样一个切分

master这样的切分

实际上我们必然会面临一次性的

一个困扰

比如说我们数据没有写

没有写完

那这时候发生的读

我们应该怎么样去处理

或者说我们这个写和读

并不是写很少而读很多

而是写和读的这个比例

差不多的时候

我们的这种切分到底还管不管用

那这是在master slave

底下我们面临的一些问题

当然我们还可以在数据上进行

这个可扩展性的一个操作

我们可以对数据进行

partition使得数据

能够备份到很多的服务器上

使得数据可以分割到

很多的这个服务器上

partition它的一个

原本的思路

就是要将用户不去考虑的

这种数据的独立性

在系统中体现出来

那我们来看它怎么做的

它可以很好的支持读

很好的支持写

因为本质上

也是把原来的一个大数据库

变成了很多的小的数据库

我们需要程序去知道

我们做了这样的切分

因为你如果程序不知道的话

或者是你的service

不知道这个过程的话

实际上

它没法在每个小的数据库访问到

它可能想要的另外一个数据库的

这个数据

然后对于数据库和数据库

之间的操作

在这样的一个模式下可能做不到了

比如说join

我们想对两个数据库

进行数据的这个联合的操作

那这是我们做不到的

所以它的优点是能够在小范围

单一数据库上

很好的支持原来的操作

但是在大范围上

我们缺失了很多的这个功能

那这是master slave和sharding两种方式

对关系数据库

它存在的优点和缺点

我们当然在这个数据库的

这样一个发展历程中

还有一些其他的方法

也对这个可扩展进行了这个提升

比如说我们可以在

这个master slave

的框架底下

进一步提出了multi master

这样一个概念

当master

单一的master

出现问题的时候

我们可以通过其他备份的这个master

得到对系统的一个支撑

当然在这里面

我们也同样会面临一系列

它的这个缺陷

这是我们在数据库的

这个场景底下

主要了解它在支持大数据的

这个历程里面

经历了哪一些这个发展

到今天为止

实际上依然有

很多的数据库的专家

在研究怎么样将数据库进行扩容

使数据库能够支撑

更大规模的数据

更复杂的请求以及更简单的操作

那么他的思路已经从原来的master slave

或者是数据的partition扩展到

更多其它的这种方法上

但是也有另外的一个思路

就是说我们放弃一些关系数据库

里面对数据的这种严格的要求

而把它变成类似于hadoop

或者是mapreduce

这种操作能够从这个scalability

本质对它进行一个提升

那么nosql就是

在这样的一个背景下产生的

它希望借助已经有的

分布式文件系统

已经有的这种大数据处理的框架

mapreduce或者是spark

来提供到类似于原来

关系数据库的这种数据查询

数据分析的一个方法

那么sql它的全称

Not Only Sql

我刚刚已经说过

那么它是在非关系的这种

数据库上搭建了一个存储系统

它的本质是一个存储系统

那么在它存储系统上

我们模拟出了很多sql的操作

通常它并不需要

一个数据的schema

也就是说它不需要一个

结构化的这种数据的描述

它可以是一系列

比如说在hadoop里面的这种

key value的一个

数据存储的一个模式

当然它也不能够支持

我们在关系数据库里面提到的

这种严格的basic的

这个属性一致性

然后它的完整性

它的数据的这种准确性

那么在nosql里面

这些特性是没有得到

没有办法得到完全的保障

那么在nosql的

这个发展中

实际上大家分析了

我们刚刚所说到的

当我们想要保证它的一致性

我们需要保证它的这个原子操作

然后我们需要保证它的这个

availablitity

以及它的这种

partition的特性的时候

实际上做这种nosql研究的人员

在这里面实际上对这几种属性进行了分析

那我们来看这里面比较出名的

这个CAP定理

那么这个定理

它描述的是这样一件事情

在我们要对数据进行切分

切分到不同的服务器上的时候

那么CAP我们是

没有办法同时保证的

那么C代表的是数据的一致性

A代表的是数据的可用性

P代表的是我们需要对整个系统

进行切分

那我们来举个例子

看看这个是为什么

会造成这样的一个结果

假设我们要对数据进行切分

这是我们最本质的一个scalability

要求的一个前提

那我们来看C和A

为什么是矛盾的

当我们需要数据有高的可能性

也就是说当一个读的请求

到达的时候

要给它这个数据满足的时候

实际上我们的C是

没有办法得到保证的

比如说我们现在

正在有两个并发的这个请求

一个是需要对数据进行修改

另外一个是对数据进行读取

那么修改它不可能同时在

这个我们集群中的

所有服务器上达到

那么它必须是从服务器到服务器

有一个逐渐或者说

接近完成的这样一个过程

那在这个过程中

不管什么时候发生

只要这个过程没有完成

当用户需要去保护数据的时候

他获得的数据可能

就会产生不一致性

那么当你要保证

这个数据的可用性的时候

那么你数据的一致性

就没有办法得到保证

所以C和A在我们的这个例子中

是很难得到保证

那么当然我们还可以通过

其他例子去证明

CAP中的AP或者是CP

它其实也很难得到同时的保证

那么这是nosql它天然

不能去解决的一个问题

但是设计nosql工程人员和科研人员

实际上就把nosql里面

我们能提供到的优势

或者说我们的特性进行了relax

得到了一个新的一组

它能保证的这样一个好处

那么我们把它叫做eventual的consistency

我们保证了可用性

那我们来看它的一致性是怎么样

慢慢的能够达得到的

那么这个过程

就像我们刚刚描述的

你的对整个系统的修改

实际上它是可以不断的

在系统中进行扩散的

比如说在HDFS

分布式文件系统中

我们对一个数据进行协助的时候

大家可以回想我们使用pipeline机制

那么这个数据让用户开始对一个

replica进行填充的时候

那么这个server会将数据收到

然后发送给下一个需要存的

replica的节点

然后进一步传到第三个节点

假设系统中的容量是三的

replication的容量是三的话

那么这个过程始终会完成的

因为它会得到namenode的监管

以及这3个服务器

它对自身数据的一个验证

所以这个数据最终会

扩散到系统当中

那么所谓的eventual就是说

在今天分布式文件系统的

这样一个背景下

实际上数据最终会被提交到

所有的节点上

用户只要能够等足够长的时间

它最终能够看到系统给它提供

最新的这样一个数据的拷贝

这只是nosql它底层的

这样一个理论的知识