HBase的引出，HBase引出

行式存储和列式存储

• 如上图,第一个行式存储是以行为单位存储数据,三个颜色的代表三个不同行数据,而下面的是列式存储,以列为单位存储数据,四个颜色代表四个不同的列,箭头也是用来表示数据是如何存储的
• 在传统的RDBMS(关系型数据库)中,保存着一条完整的数据,如果查询数据的某列,需要将这行数据查询出来再进行过滤,这就造成了不必要的浪费,而在列式存储中,id存一起,name存一起,age存一起,一列的数据存一起,所以当我们不需要全部查询一条数据时,列式存储的优势就体现出来了,并且列式存储由于一列一列的存储,一列数据的数据类型都是一样的,而不是像RDBMS那样一行数据包含各种数据类型,所以列式存储的压缩比行式存储压缩好的多

RDBMS的问题

• RDBMS存储结构相当严谨(ACID之类的限制),主要是保留用户产品订单等信息,但是这种结构非常适合有限的数据量,对于数据激增的情况,就会显得力不从心了
• 对于RDBMS激增的问题,首先我们要减少压力,增加用于并行读取的从服务器,将读写分离(增加机器,一台只用于写,一些只应付读,当然应付读数据的服务器总是比写服务器多的,因为大部分的请求都是点击操作是请求数据的过程).然后我们还可以增加缓存,将读操作接入到缓存,但是问题就是缓存中肯定会存在数据不一致,因为写服务器更新后,缓存并不能第一时间将新内容更新过来.
• 如果某天,你的网站遇到写操作激增了,那么你的写服务器就只能去垂直扩容了(加内存等硬件,使一台服务器更牛),如果我们依旧沿用这种主从配置的,那么在做写服务的机器垂直扩容的时候,我们还需要增加读服务器的配置,因为可能会机子配置差距大导致读服务器内的数据更新速度远跟不上写服务器内的数据更新速度,这样成本将会有很大的开销
• 到现在主从配置已经运行了好久好久,服务器内的数据量已经相当庞大了,这时候可能会出现性能相当糟糕,我们就不得不弃用辅助索引的使用,原因是数据量增大的时候,索引量也足以将数据库性能拖得很慢,所以说了这么半天只是为了说明:当RDBMS遇到相当大的数据量的时候,它并不是最合理的解决方案

NoSQL

• NoSQL代表了非关系型数据库,RDBMS与NoSQL在有区别的,尤其是涉及到模式或者ACID事务特性的时候,NoSQL以抛弃一些限制因素来提升自己的扩展性,NoSql通常是不支持事物的,更重要的是他比RDBMS灵活,NoSQL没有固定模式,可以随着应用的改变而灵活变化(RDBMS需要提前定义好列,而NoSQL比它灵活的多,开篇的那副图,就说明了,NoSQL可以轻松的增加一列,而RDBMS基本定义好是不建议频繁修改的)

从ACID到CAP/BASE

• 分布式系统事务处理与数据一致性上的挑战

ACID

• 事务是由一系列对系统中数据进行访问与更新的操作锁组成的一个程序执行逻辑单元Unit

• 事务具有的四特征有：原子性Atomicity，一致性consistency，隔离性isolation，持久性durabillity

  • 原子性：是指事务必须是一个源自的操作序列单元，事务的执行要么全部成功要么全部失败
  • 一致性：是指事务的执行不能破坏数据的完整性和一致性，事务执行前后，数据都必须处于一致性状态
  • 隔离性：是指在并发环境下，并发的事务是相互隔离的，一个事务执行不能被其他事务干扰。不同的事务并发操作相同的数据时，每个事务都有各自完整的数据空间，各个事务内部的操作及使用的数据对其他并发事务是隔离的，并发执行的各个事务之间不能互相干扰
  • 持久性：是指一个事务一旦提交，他对数据的操作的变更僵尸永久性的，也就是所做的操作会被保存下来

CAP和BASE理论

• 单机上的事务处理用ACID来保证数据的严格一致性没有问题，但是单机中的ACID已经没有办法胜任分布式中的事务处理了，尤其是对于一个高访问高并发的分布式系统来说，如果我们期待实现一套严格满足ACID特性的分布式事务，很可能出现的情况就是系统的可用性和严格一致性之间出现冲突，因为当我们要求分布式系统具有严格一致性时，很可能就需要牺牲掉系统的可用性，但是可用性又不可能不要，但是对于一致性的需求一样是刚需，我们需要保证用户的数据的一致性。因此在可用性和一致性之间永远存在一个两全其美的方案，于是就出现了CAP和BASE的理论

• CAP定理：一个分布式系统不可能同事满足一致性，可用性和分区容错性，最多只能同时满足其中两个

  • C(Consistency)A(Availability)P(partition tolerance)
  1. 一致性：数组数据在多个副本之间是否能够保持一致的特性

  2. 可用性：是指系统提供的服务必须一致处于可用的状态，对于用户的每一个操作请求总是能够在有限的时间内返回结果

     • 有限时间内：是指对于用户的一个操作请求，系统必须能够在指定的时间内返回对应的处理结果，如果超过了这个时间，那么系统就会被认为是不可用的。但是这个时间还是根据应用具体而变的，比如Google搜索，hive查询一个必须是秒级，一个可能会达到分钟级或者小时级
     • 返回结果：他要求系统在完成对用户请求的处理后，返回一个正常的相应结果，正常的响应结果是能够明确反映出请求的处理结果，即成功或者失败而不是让用户困惑的返回结果
  3. 分区容错性：分区容错性约束了一个分布式系统需要具有如下特性：分布式系统在遇到任何网络分区故障的时候，仍然需要能够保证对外提供满足一致性和可用性的服务，除非是整个网络环境都发生了故障

  

放弃CAP定理	说明
放弃P(分区容错)	如果希望能够避免系统出现分区容错性问题，一种较为简单的做法就是将所有的数据或者仅仅是那些与事务相关的数据都放在一个分布式节点上, 这样的做法虽然无法百分百的保保证系统不会出错，但至少不会碰到由于网络分区带来的负面影响，但同事需要注意的是：放弃P的同时也也就意味着放弃了系统的可扩展性
放弃A(可用性)	与放弃P正好相反，其做法是一旦系统遇到网络分区或者其他故障时，那么么受到影响的服务需要等待一定的时间，因此在等待期间系统无法对外提供正常的服务，即不可用
放弃C(一致性)	这里所说的放弃一致性，并不是完全不需要数据一致性，如果是这样的话，那系统的数据都是没有意义的因为各节点的数据不一致，整个系统也是没有价值的。放弃一致性指的是放弃数据的强一致性，而保留数据的最终一致性。这样的系统无法保证数据的实时一致性，但是能够承诺数据最终会达到一个一致性状态，这就有一个时间窗口的概念，具体多久能够到达数据的一致性取决与系统的设计，主要包括数据副本在不同节点指甲的复制时间长短

• 如上我们可以分析出，一个分布式系统不可能同事满足一致性，可用性和分区容错三个需求，但是对于一个分布式系统而言，分区容错是一个最基本的要求，因为既然是一个分布式系统，那么分布式系统中的组件必须需要被部署到不同节点，因此必然出现子网络，而对于分布式系统而言，网络问题又是一个必定会出现的异常情况，因此分区容错性也就成为了一个分布式系统必须需要面对和解决的问题，因此应该在C一致性和A可用性之间寻求平衡

BASE理论

• 基本可用(Basically Availability)软状态(Soft state)最终一致性(Eventually consistent)
• BASE是对CAP一致性和可用性权衡的结果，核心思想是即使无法做到强一致性，但每个应用都可以根据自身业务的特点，采用适当的方式来使系统达到最终一致性
• 基本可用：是指分布式系统在出现不可预知故障的时候，允许损失部分可用性，但是不等于系统不可用
• 弱状态：也称为软状态，是指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时
• 最终一致性：是指系统中所有的数据副本再经过一段时间的同步后最终能够达到一个一致的状态，即不需要实时博整数据的强一致性，而最终数据能够达到一致

• 最终一致性的五类主要变种

  • 因果一致性：是指如果进程A在更新某个数据项后通知了进程B，那么进程B之后对该数据项的访问都应该能够获取到进程A更新后的最新值，并且如果进程B要对数据项更新，务必是基于进程A更新后的最新值，即不能够丢失更新情况
  • 读自己所写：是指进程A更新一个数据后，它自己总是能够访问到更新过的最新值，而不会看到旧值。也就是说，对于单个数据获取这来说，其读取到的数据一定不会比自己上次写入的值旧
  • 会话一致性：系统能够在同一个有效的会话中实现“读自己所写”的一致性，在执行更新操作之后，客户端能够在同一个会话中始终读取到该数据项的最新值
  • 单调读一致性：是指如果一个进程从系统中读取出一个数据项的某个值之后，那么系统对于该进程后续的任何数据访问都不应该返回更旧的值
  • 单调写一致性：是指一个系统需要能够保证来自同一个进程的写操作被顺序的执行
• BASE总的说：面向大型高可用高扩展的分布式系统，和传统ACID特性相反，它不同于ACID的强一致性，而是提出通过牺牲强一致性来获取可用性，并允许数据在一段时间是不可用的，但最终要达到最终一致状态

HBase

• 说到现在,以上在RDBMS中遇到的问题HBase都可以解决,那么HBase是什么?
• HBase是根据谷歌发表的BigTable论文中的设计原理实现的,是一个分布式的、面向列的开源数据库,不同于一般的关系数据库，它是一个适合于非结构化数据存储的数据库