⭐⭐⭐ Spring Boot 项目实战 ⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》 《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》 《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》 《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》 《Java 面试题 + Java 学习指南》

摘要: 原创出处 blog.csdn.net/weixin_41605937/article/details/110933984 「庄小焱」欢迎转载,保留摘要,谢谢!


🙂🙂🙂关注**微信公众号:【芋道源码】**有福利:

  1. RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表
  2. RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址
  3. 您对于源码的疑问每条留言将得到认真回复。甚至不知道如何读源码也可以请教噢
  4. 新的源码解析文章实时收到通知。每周更新一篇左右
  5. 认真的源码交流微信群。

MySQL + HBase是我们日常应用中常用的两个数据库,分别解决应用的在线事务问题和大数据场景的海量存储问题。

从架构对比看差异

相比MySQL,HBase的架构特点:

  1. 完全分布式(数据分片、故障自恢复)
  2. 底层使用HDFS(存储计算分离)。

由架构看到的能力差异:

  1. MySQL:运维简单(组件少)、延时低(访问路径短)
  2. HBase:扩展性好、内置容错恢复与数据冗余

从引擎结构看差异

相比MySQL,HBase的内部引擎特点:

  1. HBase原生没有SQL引擎(无法使用sQL访问,使用APlI),云HBase增强版(Lindorm)及开源Phoenix均提供sQL能力
  2. HBase使用LSM(Log-Structure Merge)树,Innodb使用B+树。

由引擎结构(B+Tree vs LSM Tree)看到的能力差异:

  1. MySQL:读写均衡、存在空间碎片
  2. HBase:侧重于写、存储紧凑无浪费、Io放大、数据导入能力强

关于LSM树和B+树的理解

目的是为了减少磁盘IO,

索引:某种数据结构,方便查找数据

hash索引不利于范围查询,使用树结构

B+树

  • 从磁盘读数据是以页为单位,根据这个特点使用平衡多路查找树
  • B+树的非叶子节点存放索引,叶子节点存放数据
  • 非叶子节点能够存放更多的索引,树的高度更低
  • 叶子节点通过指针相连,有利于区间查询
  • 叶子节点和根节点的距离基本相同,查找的效率稳定
  • 数据插入导致叶子节点分裂,最终导致逻辑连续的数据存放到不同物理磁盘块位置,导致区间查询效率下降

LSM Tree

  • LSM(Log-Structured Merge),LevelDB,RocksDB,HBase,Cassandra等都是基于LSM结构
  • HDD,SSD顺序读写的速度都高于随机读写,写入日志就是顺序写
  • WAL,memtable,sstable
  • 有利于写,不利于读,先从memtable查找,再到磁盘所有的sstable文件查找
  • Compaction的目的是减少sstable文件数量,缓解读放大的问题,加速查找可以对sstable文件使用布隆过滤器
  • Compaction策略
  • STCS(SIze-Tiered Compaction Strategy)空间放大和读放大问题
  • LCS(Leveled Compaction Strategy)写放大问题
  • Compaction会引入写放大问题,在Value较大时采用KV分离存储缓解写放大
  • 写操作多于读操作时,LSM树有更好的性能,因为随着insert操作,为了维护B+树结构,节点分裂。读磁盘的随机读写概率会变大,性能会逐渐减弱。LSM树相比于B+树,多次单页随机写变成一次多页随机写,复用了磁盘寻道时间,极大提高写性能。不过付出代价就是放弃部分读性能。

数据访问

相同之处:数据以表的模型进行逻辑组织,应用对数据进行增删改查

不同之处:MySQL的SQL功能更丰富:事务能力更强,HBase既可以用APIl进行更灵活、性能更好的访问,也可以借助Phoenix使用标准sQL访问;只支持单行事务。

HBase的特色功能--TTL

HBase的特色功能—多版本

HBase的特色功能—多列簇

HBase的特色功能—MOB

从生态看差异

MySQL:满足APP的在线数据库存储,一般有我足矣

大数据圈:应用于大数据场景的存储、计算及管理组件

  • MySQL:一般可独立满足在线应用的数据存储需求,或者与少量组件配合(如缓存、分库中间件)
  • HBase:一般需要和较多大数据组件一起配合完成应用场景,场景架构的设计、实施存在较大的挑战

总结

哪些场景的存储适合HBase ?

HBase不是MySQL的替换,HBase是业务规模及场景扩张后,对MySQL的自然延伸

文章目录
  1. 1. 从架构对比看差异
  2. 2. 从引擎结构看差异
  3. 3. 关于LSM树和B+树的理解
    1. 3.0.1. B+树
      1. 3.0.1.1. LSM Tree
  • 4. 数据访问
  • 5. 从生态看差异
  • 6. 总结