MYSQL与HBASE对比

程序员的成长之路

互联网/程序员/技术/资料共享

阅读本文大概需要 2.8 分钟。

作者：庄小焱

来源：https://blog.csdn.net/weixin_41605937/article/details/110933984

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+树

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+树，多次单页随机写变成一次多页随机写,复用了磁盘寻道时间，极大提高写性能。不过付出代价就是放弃部分读性能。