Video在线视频

我们刚才说到了nosql

它的一些背景

我们怎么样从关系数据库

切换到了nosql这样的模式

我们从原来的schema的

这种数据描述切换到了

利用分布式文件系统

进行数据承载

然后来进行这种

不能保证严格的CAP的这样

一个数据存储的一个模式

那么我们下面会来看我们使用了

这种模式之后

能够得到什么样的好处

那么第一个好处就是说

它的成本比较低

因为nosql今天的

这种开源系统

通常它基于开源的模块

基于这种可以直接购买的

这种服务器设备

以及其他的这种

硬件和软件的设备

所以它本质上是有一个开源社区

来支持的这样一个架构

成本比较低

第二它的数据可以

分散到系统中的各个节点

有一定的这种可扩展性

那么这也是由它底层的

分布式文件系统

底层的这种数据处理平台

mapreduce或者是spark

它所决定的

然后它有一定的

可分布的这种性能

那么我们之前说到mapreduce

或者是分布式文件系统

HDFS中

那么整个系统的扩展性实际上

是一个scale out的模式

也就是说当我添加新的服务器

新的硬件设备之后

它的scalability能够得到相应的扩大

那么由底层的这个系统决定

所以它上面是有一定的可扩展性

同时它有对于这种schema

并没有一个非常严的一个要求

在nosql里面

它的数据承载是一系列的文件

那么这些文件

实际上并不要求

在传统关系数据库里面

比较严格的这种表格化的

数据结构数据类型化的

这样一个数据的这样一个描述

同时它还支持一定的

叫做relax的这种CAP的

这样一个保证

也就是说

在我保证一定的数据partition

这样一个前提下

我依然能够保证一定的数据的

一致性以及数据的可用性

所以它是渐进的

逼近了这样的一个CAP的

一个保证

那么我们在nosql里面

有了刚刚说的这些优点

那到底哪一些缺点

是它目前还没有办法克服

或者说是我们使用了nosql

作为我们的这个数据仓库

数据平台之后

我们有哪一些性能

或者说哪些操作

是我们不能达到的

那么我们看看我们到底在这里面

放弃了什么东西

首先我们不能做

在关系数据库里面表格 表格

数据库数据库之间的

这个join的操作

因为它要求强的这种

schema的一个数据模型

那么我们不能做到这一点

我们不能做类似的这个groupOrderBy

那么他们也都要求

表格和表格之间进行并联

进行这个schema化的

这样一个操作

那么还有一些复杂的

这个sql的命令可能在

我们这里面也不一定

能够得到有效的支持

当然今天nosql

衍生出的产品也支持了

类似于sql或者说

更加精细的这样一个

数据查询工作

但是本质上它依然受限于

刚刚我们说到的

比如说数据的join

数据的group

数据的order

同时它的在发展之初

它的这个编程的环境

也不如sql那样友好

当然后面的这两个缺陷

这两个缺点

在今天的系统中已经得到了

多多少少的解决

那我们来看在nosql中

它提供的这个原语性的操作

包括哪些呢

我们来看它的这个原语性操作

大概可以分成四类

第一

前面的几类是和数据的

这个原始的操作是有关的

get

我们可以从nosql里面

将数据读取出来

或者put我们可以把数据塞入到

nosql的这个环境当中

我们可以从里面删除数据

那么最后一个execute

就是说我们可以对要求的这样

一个数据范围进行一些操作

进行一些计算处理

或者是分析

在典型的nosql系统中

实际上是执行了相对比较原生的

这个系统的程序和系统代码

那么当然也给了大家足够的

想象空间

可以通过execute来做到

非常复杂的这样一个查询的支持

好

那我们来看nosql

它在具体的实现当中

大概是有一些什么样的考虑

有些什么样的办法

那么大致的两类可以分成

这个Key和Value这样的一个模式

那么Key和Value对应的底层系统

是类似于分布式文件系统

GFS

HDFS

这样的一个环境底下

我们可以通过对分布式文件系统

进行一个改进

使得它原生的这个key value的模式

可以支持上层的这种

nosql数据的

一个放入和执行

那么还有一个是从这个schema

的这种角度来的

一个叫做schema list的

这样一个模式

也就是说在nosql里面

引入了一定的这个schema

的这个数据的属性

然后来进行这个数据的放置

数据的操作以及数据的这种查询

有一定的这个schema

然后它的schema

支持的并不全

不像传统关系数据那样全

但它是从量的一个角度

进行数据库的一个设计

我们来看这两种

它的这种特性到底是什么样

Key Value这种模式

它的好处有哪些呢

首先基于Key Value

它的数据的模型很简单

所以它在数据的读写

以及操作过程中会相对比较快

scalability和原来

分布式文件系统的scalability

是一致的

所以它的scalability是很好的

同时它的这个数据模型比较简单

model比较简单

那么它也能够按照

scale out的方式

进行这种可扩展

缺点就是说

它对这种数据处理任务

有一定的要求

比如说并不是所有的

这种数据处理任务

都能够平稳的转换到

这个key value这样的模式

一些相对复杂的

比如说图的这种结构

也许我们就需要

上层的开发人员有一定的

转化的能力

你才能用这种模式进行开发

否则会带来性能上的这种下降

或者说直接就不能做到

schema list的模式它的优点

我们可以看到

那么schema的data

实际上它会相对比较灵活

因为他至少支持了一定的

这种数据的描述

然后它可以保证

eventual的consistency

我们之前已经提到过

然后它也有一定的分布的

这种分布化的能力

那么已经有了一系列的系统

实际上也验证了这一点

那么它可以提供一定的

性能上的保证

那么之前做的一系列的系统

也支持了这一条

但是本质上

它的这个数据模型

还是相对比较复杂

它和NoSQL最开始设计的

这样一个原则

还是有一定的不匹配

所以在今天很多的工业界的

实际使用中

那么基于key value

就这种模式

实际上还是一个

非常重要的这种选择

那么它的缺点

那么与关系数据库相比

它还是没有办法支持的这种acid

这种transcation属性的一个保证

而与nosql相比

它可能又不是那么简单

所以大家可以理解

它处在这两者之间

那么也同时具有

这两者的缺点和优点