程式員的成長之路
網際網路/程式員/技術/資料共享
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的自然延伸