文章目录
1.NoSQL简介
1.1什么是NoSQL
NoSQL：not only SQL，非关系型数据库
NoSQL是一个通用术语
- 指不遵循传统RDBMS模型的数据库
- 数据是非关系的，且不使用SQL作为主要查询语言
- 解决数据库的可伸缩性和可用性问题
- 不针对原子性或一致性问题
1.2为什么使用NoSQL
互联网的发展，传统关系型数据库存在瓶颈
- 高并发读写
- 高存储量
- 高可用性
- 高扩展性
- 低成本
NoSQL和关系型数据库对比
主要有以下一些区别
| 对比 | NoSQL | 关系型数据库 |
|---|---|---|
| 常用数据库 | HBase、MongoDB、Redis | Oracle、DB2、MySQL |
| 存储格式 | 文档、键值对、图结构 | 表格式，行和列 |
| 存储规范 | 鼓励冗余 | 规范性，避免重复 |
| 存储扩展 | 横向扩展，分布式 | 纵向扩展（横向扩展有限） |
| 查询方式 | 结构化查询语言SQL | 非结构化查询 |
| 事务 | 不支持事务一致性 | 支持事务 |
| 性能 | 读写性能高 | 读写性能差 |
| 成本 | 简单易部署，开源，成本低 | 成本高 |
1.3NoSQL的特点
-
最终一致性
-
应用程序增加了维护一致性和处理事务等职责
-
冗余数据存储
-
NoSQL != 大数据
- NoSQL产品是为了帮助解决大数据存储问题
- 大数据不仅仅包含数据存储的问题
- Hadoop
- Kafka
- Spark, etc
1.4NoSQL基本概念
- 三大基石
- CAP、BASE、 最终一致性
- Indexing（索引）、Query（查询）
- MapReduce
- Sharding
- CAP理论
- 数据库最多支持3个中的2个
- Consistency（一致性）
- Availability（可用性）
- Partition Tolerance（分区容错性）
- NoSQL不保证“ACID”
- 提供“最终一致性”
- BASE
- Basically Availble（基本可用）
- 保证核心可用
- Soft-state（软状态）
- 状态可以有一段时间不同步
- Eventual Consistency（最终一致性）
- 系统经过一定时间后，数据最终能够达到一致的状态
- 核心思想是即使无法做到强一致性，但应用可以选择适合的方式达到最终一致性
- 最终一致性
- 最终结果保持一致性，而不是时时一致
- 如账户余额，库存量等数据需强一致性
- 如catalog等信息不需要强一致性
- Causal consistency（因果一致性）
- Read-your-writes consistency
- Session consistency
索引和查询
- Indexing（索引）
大多数NoSQL是按key进行索引
部分NoSQL允许二级索引
HBase使用HDFS，append-only
批处理写入Logged
重新创建并排序文件 - Query（查询）
没有专门的查询语言，通常使用脚本语言查询
有些开始支持SQL查询
有些可以使用MapReduce代码查询
MapReduce、Sharding
- MapReduce
不是Hadoop的MapReduce，概念相关
可进行数据的处理查询 - Sharding（分片）
一种分区模式
可以复制分片
有利于灾难恢复
1.5NoSQL分类
主要分为以下四类
| 分类 | 举例 | 典型应用场景 |
|---|---|---|
| 键值存储数据库(key-value) | Redis, MemcacheDB, Voldemort | 内容缓存等 |
| 列存储数据库(WIDE COLUMN STORE) | Cassandra, HBase | 应对分布式存储的海量数据 |
| 文档型数据库(DOCUMENT STORE) | CouchDB, MongoDB | Web应用（可看做键值数据库的升级版） |
| 图数据库(GRAPH DB) | Neo4J, InfoGrid, Infinite Graph | 社交网络，推荐系统等，专注于构建关系图谱 |
键值存储数据库（Key-Value）
列存储数据库（Wide Column Store）
文档型数据库（Document Store）
图数据库（Graph Databases）
1.6NoSQL和BI、大数据的关系
- BI（Business Intelligence）：商务智能
它是一套完整的解决方案
BI应用涉及模型，模型依赖于模式
BI主要支持标准SQL，对NoSQL支持弱于关系型数据库 - NoSQL和大数据相关性较高
通常大数据场景采用列存储数据库
如：HBase和Hadoop
2.HBase介绍
2.1HBase概述
- HBase是一个领先的NoSQL数据库
是一个面向列存储的数据库
是一个分布式hash map
基于Google Big Table论文
使用HDFS作为存储并利用其可靠性 - HBase特点
数据访问速度快，响应时间约2-20毫秒
支持随机读写，每个节点20k~100k+ ops/s
可扩展性，可扩展到20,000+节点
2.2HBase发展历史
| 时间 | 事件 |
|---|---|
| 2006年 | Google发表了关于Big Table论文 |
| 2007年 | 第一个版本的HBase和Hadoop0.15.0一起发布 |
| 2008年 | HBase成为Hadoop的子项目 |
| 2010年 | HBase成为Apache*项目 |
| 2011年 | Cloudera基于HBase0.90.1推出CDH3 |
| 2012年 | HBase发布了0.94版本 |
| 2013-2014 | HBase先后发布了0.96版本/0.98版本 |
| 2015-2016 | HBase先后发布了1.0版本、1.1版本和1.2.4版本 |
| 2017年 | HBase发布1.3版本 |
| 2018年 | HBase先后发布了1.4版本和2.0版本 |
2.3HBase用户群体
2.4HBase应用场景
- 应用场景-1
增量数据-时间序列数据
高容量，高速写入
- 应用场景-2
信息交换-消息传递
高容量，高速读写
- 应用场景-3
内容服务-Web后端应用程序
高容量，高速读写
2.5Apache HBase生态圈
HBase生态圈技术
Lily – 基于HBase的CRM
OpenTSDB – HBase面向时间序列数据管理
Kylin – HBase上的OLAP
Phoenix – SQL操作HBase工具
Splice Machine – 基于HBase的OLTP
Apache Tephra – HBase事务支持
TiDB – 分布式SQL DB
Apache Omid - 优化事务管理
Yarn application timeline server v.2 迁移到HBase
Hive metadata存储可以迁移到HBase
Ambari Metrics Server将使用HBase做数据存储
2.6HBase架构
1.物理架构
HBase采用Master/Slave架构
-
HMaster的作用
是HBase集群的主节点，可以配置多个，用来实现HA
管理和分配Region
负责RegionServer的负载均衡
发现失效的RegionServer并重新分配其上的Region -
RegionServer
RegionServer负责管理维护Region
一个RegionServer包含一个WAL、一个BlockCache (读缓存)和多个Region
一个Region包含多个存储区，每个存储区对应一个列族
一个存储区由多个StoreFile和MemStore组成
一个StoreFile对应于一个HFile和一个列族
HFile和WAL作为序列文件保存在HDFS上
Client与RegionServer交互
- Region和Table
2.逻辑架构Row
- Rowkey（行键）是唯一的并已排序
- Schema可以定义何时插入记录
- 每个Row都可以定义自己的列，即使其他Row不使用
- 相关列定义为列族
- 使用唯一时间戳维护多个Row版本
- 在不同版本中值类型可以不同
- HBase数据全部以字节存储
2.7HBase数据管理
- 数据管理目录
- 系统目录表hbase:meta
- 存储元数据等
- HDFS目录中的文件
- Servers上的region实例
- 系统目录表hbase:meta
- HBase数据在HDFS上
- 可以通过HDFS进行修复File
- 修复路径
- RegionServer->Table->Region->RowKey->列族
2.8HBase架构特点
- 强一致性
- 自动扩展
- 当Region变大会自动分割
- 使用HDFS扩展数据并管理空间
- 写恢复
- 使用WAL(Write Ahead Log)
- 与Hadoop集成