大数据 二

一  CAP+BASE

 

CAP

· C:Consistency（强一致性）

· A:Availability（可用性）

· P:Partition tolerance（分区容错性）

CAP的3选2原则

· CAP理论在分布式存储系统中,最多只能实现亮点.

现在存在的问题是:网络硬件会出现延迟丢包等问题,所有分区容忍行(分区容错性)是必须要实现的.因此我们只能在一致性(C)和可用性(A)之间权衡,**没有NoSQL系统能同时保证CAP这3点.

· CA:传统Oracle数据库

· AP:大多数网站架构的选择

· CP:Redis.Mongodb

注意:分布式架构的时候必须做出取舍. 
要在一致性(C)和可用性(P)之前取一个平衡点,现在大多数Web应用,其实并不需要强一致性.因此舍强一致性(C),取分区容错性(P),这是目前分布式数据库产品的方向.

一致性(C)与可用性(A)的决择

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

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

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

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

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

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

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

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

BASE

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

· 基本可用（Basically Available）

· 软状态（Soft state）

· 最终一致（Eventually consistent）

为什么使用BASE?

它的思想:是通过让系统减压,对某时刻数据一致性的要求来换取系统整体伸缩性和性能上改观。原因就在于大型系统往往由于地域分布和极高性能的要求，不可能采用分布式事务来完成这些需求.

分布式+集群简介

· 分布式系统（distributed system） 

由多台计算机和通信的软件组件通过计算机网络连接（本地网络或广域网）组成。分布式系统是建立在网络之上的软件系统。正是因为软件的特性，所以分布式系统具有高度的内聚性和透明性。因此，网络和分布式系统之间的区别更多的在于高层软件（特别是操作系统），而不是硬件。分布式系统可以应用在在不同的平台上如：Pc、工作站、局域网和广域网上等。 
简单来讲： 
1. 分布式：不同的多台服务器上面部署不同的服务模块（工程），他们之间通过Rpc/Rmi之间通信和调用，对外提供服务和组内协作。 
2. 集群：不同的多台服务器上面部署相同的服务模块，通过分布式软件进行统一的调度，对外提供服务和访问。

  二 副本策略

 分布式存储系统中，文件/对象，多采用副本的方式，提高数据的可靠性以及读数据的io throughput。系统中副本在节点间的分布策略，对于快速定位数据的位置，以及整个系统的网络流量、节点间io负载均衡，非常重要。副本分布策略，大致分为三种：

    1.基于统计和监控的副本分布策略；

    2.基于一致性hash的副本分布策略；

    3.基于伪随机算法的副本分布策略；

基于统计和监控的策略：

      这种策略在传统的，有中心（MDS metadata server）的架构中比较常见。全局统一的元数据服务器中，记录了当前系统中每个数据节点的存储空间使用率，可以监控到每个节点当前网络、blockio的负载。metadata sever相当于一个全能节点，时刻洞察到系统中变化。元数据服务器基于这些统计、监控信息，综合多种的负载均衡策略（例如空间使用率最低，机架位置选择，网络raid10、节点状态等）来为新增的blcok选取数据节点的位置。采用这种策略的分布式存储系统有Googlefs，HDFS，Moosefs。

这种策略的缺点是，当元数据服务器存在多个时，统计和监控的压力增加，多个中心节点的决策很难协调。例如新上线一个节点，根据空间使用率原则，这个节点需要优先分配，但是同时，也不能所有的新数据都向这个节点上写；如果只有一个元数据服务器，比较简单，可以设法规避新数据热点。如果多个元数据服务器，就很难协调。

 基于一致性hash的副本策略：

     这种策略是去中心架构的核心技术。有了一致性hash的副本选择策略，任何一个client，都可以根据少量的元数据映射关系（virtual nnode到physical node），计算出每个objectID/fileID对应的物理位置。详细算法不在详细赘述，有兴趣的同学可以研究下aws Dynamo和openstack swift的副本分布策略。

这种策略的明显的优势是可以去掉元数据服务器，这个很容易成为瓶颈的系统组成部分（hot sopt）。数据定位的速度更快了，是算出来的，而不是去一个服务器查询出来的。不足之处是：1.扩容的时候很难完全自动化，目前swift扩容时还是需要人工参与。2.需要提前规划好virtual node的数据量。

  基于伪随机算法的副本分布策略：

     采用这种策略的分布式系统比较少。简单的随机分配算法，可以解决给分布分配节点时的多个元数据服务器冲突的问题。例如一个metadata server集群中，任意一个MDS都可以从集群中随机选择一个节点为副本所在位置。简单的随机选择算法有两个问题：

     一、因为是完全随机选择，client不能简单的根据ID计算得出位置，还是需要元数据服务器 记录下来位置信息供后续查询；

     二、扩容之后，数据如何rebalance，比较困难。

     目前比较热门的分布式存储系统ceph，采用了一个名为crush的 算法，很好的 解决了以上两个问题。cursh算法其实也是先要计算objectID取hash值，hash值再乘以节点的权重，然后所有节点中这个乘积的最大节点，为选择节点。objectID是确定的，如果每个节点权重也确定，那么hash值不变，位置也是固定的。当节点发生变化后，变动比较小的情况下，发生位置变化的objec的数量也是比较小的。具体的数据对比和分析，可以考虑sage weil的crush论文http://ceph.com/papers/weil-crush-sc06.pdf

     这种算法也有一个局限性，就是随机算法只有在数据量比较大的情况下，才能达到较好的随机性和均匀性。ceph的设计思想，决定了它天生是web-scale的分布式存储系统，适合大集群，规模越大越好。但是对于一个可以预见性的小规模集群来说，随机算法效果不见得好，一致性hash是一个更好的选择。

     apache ignite采用的Rendezvous hash本质上也是一种伪随机算法，跟ceph的crush有相通之处。

三数据分割

 数据分割是指把逻辑上是统一整体的数据分割成较小的、可以独立管理的物理单元进行存储，以便于重构、重组和恢复，以提高创建索引和顺序扫描的效率。数据分割使数据仓库的开发人员和使用者具有更大的灵活性。

优点

编辑

对当前细节数据进行分割的总体目的就是把数据划分成小的物理单元，为操作者和设计者在管理数据时提供更大的灵活性。小物理单元具有容易重构、自由索引、顺序扫描、容易重组、容易恢复和容易监控等优点。数据仓库的本质之一就是灵活地访问数据，大块数据达不到这个目的。

标准

编辑

数据分割的标准可以根据实际情况来确定，通常可选择按日期、地域、业务领域或组织单位等来进行分割，也可以按多个分割标准的组合来进行，但一般情况下，分割标准应包括日期项。

例如，数据分割的标准是由开发人员选择的，在数据仓库中按日期总是必需的。

层次

编辑

分割的层次一般分为系统层和应用层。系统层的分割由数据库管理系统和操作系统完成；应用层的分割由应用系统完成，在应用层上的分割更有意义。 [2]  

分割方法

编辑

水平分割

水平分割(Horizontal Splitting)就是把全局关系的元组分割成一些子集，这些子集被称为数据分片或段(Fragment)。数据分片中的数据可能是由于某种共同的性质(如地理、归属)而需要聚集一起的。通常，一个关系中的数据分片是互不相交的，这些分片可以选择地放在一个站点上，也可以通过副本被重复放在不同的站点上。 [1]  

垂直分割

垂直分割(Vertical Splitting)就是把全局关系按着属性组(纵向)分割成一些数据分片或段(Fragment)。数据分片中的数据可能是由于使用上的方便或访问的共同性而需要聚集一起的。通常，一个关系中的垂直数据分片问只在某些键值上重叠，其他属性是互不相交的。这些垂直分片可以放一个站点上，也可以通过副本被重复放在不同的站点上。 [1]