HBase —— NoSQL_Not Only SQL
NoSQL数据库：
- 不遵循传统的RDBMS模型
- 解决数据库的可伸缩性和可用性（多机器）
- 数据是非关系的（可切分），不使用sql语句
- 不针对原子性或一致性（定时同步数据）问题
——————————————————————————————
-
传统关系型数据库存在瓶颈
- 高并发读写，每秒上万次读写请求
- 高存储量，分库分表难以维护
- 高扩展性，无法简单地通过增加硬件提升性能
- 高可用性，不能保证服务长时间运行时的稳定性
-
NoSQL的优势
- 优异的海量数据读写性能
- 灵活的数据模型
- 数据间无关系，易于切割、扩展
SQL与NOSQL对比
| 对比 | NoSQL | 关系型数据库 |
|---|---|---|
| 常用数据库 | HBase、MongoDB、Redis | Oracle、DB2、MySQL |
| 存储格式 | 文档、键值对、图结构 | 表格式，行和列 |
| 存储规范 | 鼓励冗余 | 规范性，避免重复 |
| 存储扩展 | 横向扩展，分布式 | 纵向扩展（横向扩展有限） |
| 查询方式 | 非结构化查询 | 结构化查询语言SQL |
| 事务 | 不支持事务一致性 | 支持事务 |
| 性能 | 读写性能高 | 读写性能差 |
| 成本 | 简单易部署，开源，成本低 | 成本高 |
-
NoSQL的特点
- 最终一致性，数据并非实时一致，但最终会一致
- 应用程序可以增加一致性
- 鼓励冗余数据存储
-
NoSQL 不等于 大数据
- nosql是为了帮助解决大数据的数据存储问题
- 但大数据不仅仅包含数据的存储问题（存储、分析）
NoSQL基本概念
一、三大基石
1、CAP理论
分布式系统最多支持3个中的两个（AC、AP、CP）
- Consistency 一致性
- Availability 可用性
- Partition Tolerance 分区容错性
NoSQL 不保证ACID，提供最终一致性（HBase是强一致性的，支持CP，因为其基于HDFS的，分区多副本）
2、BASE
-
Basically Availble 基本可用
- 允许部分失效， 但保证核心可用
-
Soft-state 软状态
- 状态可以有一段时间不同步
-
Eventual Consistency 最终一致性
- 系统经过一定时间后，数据最终能达到一致的状态
3、最终一致性
- 最终一致性是弱一致性的特列，系统会保证在一定时间内，能达到一个数据一致的状态，而不是时时一致
- Hbase是强一致性数据库，不是最终一致性。因为HBase基于HDFS存储系统的，而HDFS是实时备份的，备份完成后才返回操作结果，因此Hbase是强一致性的。
二、索引和查询
1、Indexing（索引）
-
大多数NoSQL是按key进行索引
-
部分NoSQL允许二级索引
-
HBase使用HDFS，append-only（读写很快）
- 批处理写入Logged
- 重新创建并排序文件
2、Query（查询）
- 没有专门的查询语言，通常使用脚本语言查询
- 有些开始支持SQL查询
- 有些可以使用MapReduce代码查询
三、MapReduce、Sharding
1、MapReduce 概念相关，map预处理映射，reduce分析/聚合（并非hadoop的mr）
2、sharding 分片 ，一种分区模式，可以复制分片
NoSQL分类
| 分类 | 举例 | 典型应用场景 |
|---|---|---|
| 键值存储数据库 (key-value) | Redis, MemcacheDB, Voldemort | 内容缓存等(减少检索数据库的次数) |
| 列存储数据库 (WIDE COLUMN STORE) | Cassandra, HBase | 应对分布式存储的海量数据 |
| 文档型数据库 (DOCUMENT STORE) | CouchDB, MongoDB | Web应用（可看做键值数据库的升级版） |
| 图数据库 (GRAPH DB) | Neo4J, InfoGrid, Infinite Graph | 社交网络，推荐系统等，专注于构建关系图谱 |
- 通常大数据场景采用列存储数据库
HBase概述
1)hbase是一个分布式的，基于列式存储的数据库，基于hadoop的hdfs存储，zookeeper进行管理。
2)hbase 适合存储半结构化或非结构化的数据，对于数据结构字段不够确定或者杂乱无章很难按照一个概念去抽取的数据。
-
HBase是一个领先的NoSQL数据库
- 是一个面向列存储的数据库
- 是一个分布式hash map
- 基于Google Big Table论文
- 使用HDFS作为存储并利用其可靠性
-
HBase特点
- 数据访问速度快，响应时间约2-20毫秒
- 支持随机读写(实质是切片再append)，每个节点20k~100k+ ops/s
- 可扩展性，可扩展到20,000+节点
HBase物理架构
1、HBase采用Master/Slaves架构
- HMaster
- RegionServer （salve，部署在datanode上）
- Zookeeper （监管集群）
- HBase Client（java、shell、rest thrift）
- Region （分区）
2、HMaster的作用
- 维护Table和Region的原数据信息
- 管理Region和为 RegionServer 分配Region
- 负责RegionServer的负载均衡
- 发现失效的RegionServer并重新分配其上的Region
- 处理 Schema 更新请求（表的创建，删除，修改，列簇的增加等等）
- 是HBase集群的主节点，可以配置多个，用来实现high available 高可用
3、RegionServer负责管理维护Region
-
一个RegionServer包含一个WAL（数据操作日志）、一个BlockCache (读缓存)和多个Region
-
一个Region包含多个Store存储区，每个存储区对应一个列族
-
一个存储区由多个StoreFile和MemStore（写缓存，128M，一个Block）组成
-
一个StoreFile对应于一个HFile和一个列族
-
负责 Split 在运行过程中变得过大的 Region，负责 Compact 操作
-
WAL（write ahead log），在数据写入之前将操作写入日志，在灾难后可以最大程度恢复数据
-
HFile和WAL作为序列文件保存在HDFS上
-
Client与RegionServer交互
- 流程：clinet -> zookeeper . get meta 的region server->meta .get 要查询的rowkey对应region所在的regionserver地址 ->链接region server，查询
4、Region和Table
- 单表大小最大256M，之后会单个Table（表）被分区成大小大致相同的新Region
- Region是HBase集群分布数据的最小单位，但不是最小的数据存储单元，其下还有Store和HFile，HBase的数据存储是以HFile组织的
- Region由集群中的RegionServer维护，一个RS通常维护多个Region
- 但一个Region只能分配给一个RegionServer
5、Clinet 客户端
- 缓存机制，每次读写会记录地址信息
- 缓存地址信息错误多次后会重新访问ZK服务获取新的地址
HBase逻辑架构--ROW
- Rowkey（行键）是唯一的并按字典排序
- 每个Row都可以定义自己的列，即使其他Row不使用，一定范围具有联系的列的总和为列族
- 使用唯一时间戳维护多个Row版本
- 在不同版本中值类型可以不同
- HBase数据全部以字节存储
- 行键、列族、列键、时间戳、ceil值
- HBase只需要定义列族
HBase 架构特点
-
强一致性
-
自动扩展
-
当Region变大会自动分割
-
使用HDFS扩展数据并管理空间
-
写恢复
- 使用WAL(Write Ahead Log)
-
与Hadoop集成