【HBase】（一）NoSQL 360度盘点，这些细节值得关注！

最新推荐文章于 2021-01-22 13:00:50 发布

云祁

最新推荐文章于 2021-01-22 13:00:50 发布

阅读量1.3k

点赞数 2

分类专栏： # ---- HBase 文章标签： nosql hbase

本文链接：https://blog.csdn.net/BeiisBei/article/details/103639553

版权

---- HBase 专栏收录该内容

14 篇文章 3 订阅

订阅专栏

文章目录

一、前言

在开始HBase的学习之前，我们有必要了解一下NoSQL，为什么要使用NoSQL，NoSQL和关系型数据库的对比，NoSQL的特点以及NoSQL的基本概念–三大基石等，让我们带着疑惑开始学习吧！😄

二、为什么使用NoSQL

原因很简单，因为互联网的发展，传统关系型的数据库存在瓶颈，而NoSQL 数据库存在以下诸多优势：

高并发读写
高存储
高可用性
高扩展性
低成本

三、NoSQL和关系型数据库对比

对比	NoSQL	关系型数据库
存储格式	文档、键值对、图结构	表格式，行和列
存储规范	鼓励冗余	规范性，避免重复
存储扩展	横向扩展，分布式	纵向扩展（横向扩展有限）
查询方式	非结构化查询	结构化查询语言SQL
事务	不支持事务一致性	支持事务
性能	读写性能高	读写性能差
成本	简单易部署，开源，成本低	成本高

四、NoSQL 的特点

最终一致性
应用程序增加了维护一致性和处理事务等职责
冗余数据存储
NoSQL != 大数据
- NoSQL产品是为了帮助解决大数据存储的问题
- 大数据不仅仅包含数据存储的问题（Hadoop、Kafka、Spark）

五、NoSQL基本概念

三大基石（CAP、BASE和最终一致性）
Indexing（索引）、Query（查询）
MapReduce
Sharding

接下来我会重点讲一下 NoSQL 的三大基石，这也是面试里常常会被问道的，所以当然要重点关注辣！😁

六、NoSQL的三大基石（CAP、BASE和最终一致性）

在这里插入图片描述
所谓的CAP指的是：
C（Consistency）：一致性，是指任何一个读操作总是能够读到之前完成的写操作的结果。也就是在分布式环境中，多点的数据是一致的，或者说，所有节点在同一时间(读写应该是单线程的，否则写过程的流水线复制过程中各数据节点内容可能不一致)具有相同的数据
A:（Availability）：可用性，可以在确定的时间内返回操作结果，保证每个请求不管成功或者失败都有响应；
P（Tolerance of Network Partition）：分区容忍性，是指当出现网络分区的情况时（即系统中的一部分节点无法和其他节点进行通信），分离的系统也能够正常运行，也就是说，系统中任意信息的丢失或失败不会影响系统的继续运作。

CAP

CAP理论告诉我们，一个分布式系统不可能同时满足一致性、可用性和分区容忍性这三个需求，最多只能同时满足其中两个，正所谓“鱼和熊掌不可兼得”。

举例，为满足一致性，需要确保多副本数据一致，就使得多副本写数据过程中无法响应读请求。所以，NOSql数据库都不能同时满足CA(一致性和可用性)两个要求。关系型数据库可同时满足CA(一致性和可用性)。典型的NOSql数据库Redis、HBase、MongoDB、Neo4j都不能满足CA特性，可满足CP特性。
　　
当处理CAP的问题时，可以有几个明显的选择：

CA：也就是强调一致性（C）和可用性（A），放弃分区容忍性（P），最简单的做法是把所有与事务相关的内容都放到同一台机器上。很显然，这种做法会严重影响系统的可扩展性。传统的关系数据库（MySQL、SQL Server和PostgreSQL），都采用了这种设计原则，因此，扩展性都比较差
CP：也就是强调一致性（C）和分区容忍性（P），放弃可用性（A），当出现网络分区的情况时，受影响的服务需要等待数据一致，因此在等待期间就无法对外提供服务
AP：也就是强调可用性（A）和分区容忍性（P），放弃一致性（C），允许系统返回不一致的数据

BASE

在这里插入图片描述
一个数据库事务具有ACID四性：

A（Atomicity）：原子性，是指事务必须是原子工作单元，对于其数据修改(包括新增，修改，删除数据)，要么全都执行，要么全都不执行
C（Consistency）：一致性，是指事务在完成时，必须使所有的数据都保持一致状态
I（Isolation）：隔离性，是指由并发事务所做的修改必须与任何其它并发事务所做的修改隔离
D（Durability）：持久性，是指事务完成之后，它对于系统的影响是永久性的，该修改即使出现致命的系统故障也将一直保持

BASE的基本含义是基本可用（Basically Availble）、软状态（Soft-state）和最终一致性（Eventual consistency）：

基本可用
基本可用，是指一个分布式系统的一部分发生问题变得不可用时，其他部分仍然可以正常使用，也就是允许分区失败的情形出现
软状态
“软状态（soft-state）”是与“硬状态（hard-state）”相对应的一种提法。数据库保存的数据是“硬状态”时，可以保证数据一致性，即保证数据一直是正确的。“软状态”是指状态可以有一段时间不同步，具有一定的滞后性
最终一致性
一致性的类型包括强一致性和弱一致性，二者的主要区别在于高并发的数据访问操作下，后续操作是否能够获取最新的数据。对于强一致性而言，当执行完一次更新操作后，后续的其他读操作就可以保证读到更新后的最新数据；反之，如果不能保证后续访问读到的都是更新后的最新数据，那么就是弱一致性。而最终一致性只不过是弱一致性的一种特例，允许后续的访问操作可以暂时读不到更新后的数据，但是经过一段时间之后，必须最终读到更新后的数据。
最常见的实现最终一致性的系统是DNS（域名系统）。一个域名更新操作根据配置的形式被分发出去，并结合有过期机制的缓存；最终所有的客户端可以看到最新的值。

备注：软状态关注数据在不同节点间同步的滞后性(关注同步状态)，最终一致性关注不同节点数据最终一致(关注最终结果)

最终一致性

如何实现各种类型的一致性？

对于分布式数据系统：

N — 数据复制的份数
W — 更新数据是需要保证写完成的节点数(一个写操作，只有W个节点都写成功，本次写操作才返回成功)
R — 读取数据的时候需要读取的节点数(一个读操作，只有R个节点都读成功，本次读操作才返回成功)

如果W+R>N，写的节点和读的节点重叠(可保证至少读取的一个节点数据是最新写入的数据)，则是强一致性。例如对于典型的一主一备同步复制的关系型数据库，N=2,W=2,R=1，则不管读的是主库还是备库的数据，都是一致的。一般设定是R＋W = N+1，这是保证强一致性的最小设定

如果W+R<=N，则是弱一致性(读取的R个节点，不能保证至少读取的一个节点数据是最新写入的数据)。例如对于一主一备异步复制的关系型数据库，N=2,W=1,R=1，则如果读的是备库，就可能无法读取主库已经更新过的数据，所以是弱一致性。

对于分布式系统，为了保证高可用性，一般设置N>=3。不同的N,W,R组合，是在可用性和一致性之间取一个平衡，以适应不同的应用场景。

如果N=W,R=1，任何一个写节点失效，都会导致写失败，因此可用性会降低，但是由于数据分布的N个节点是同步写入的，因此可以保证强一致性。

实例：HBase是借助其底层的HDFS来实现其数据冗余备份的。HDFS采用的就是强一致性保证。在数据没有完全同步到N个节点前，写操作是不会返回成功的。也就是说它的W＝N，而读操作只需要读到一个值即可，也就是说它R＝1。

像Voldemort，Cassandra和Riak这些类Dynamo的系统，通常都允许用户按需要设置N，R，W三个值，即使是设置成W＋R<= N也是可以的。也就是说他允许用户在强一致性和最终一致性之间自由选择。而在用户选择了最终一致性，或者是W<N的强一致性时，则总会出现一段“各个节点数据不同步导致系统处理不一致的时间”。为了提供最终一致性的支持，这些系统会提供一些工具来使数据更新被最终同步到所有相关节点。