華爲雲PB級數據庫GaussDB(for Redis)揭祕第九期：與HBase的對比

摘要： 高斯Redis，兼具開源Redis和HBase各自優勢，提供成本更低、性能更好、靈活性更強的數據庫服務！

本文分享自華爲雲社區《華爲雲PB級數據庫GaussDB(for Redis)揭祕第九期：與HBase的對比》，原文做者：高斯Redis官方博客。

0. 引言

HBase是一個分佈式的、面向列的開源數據庫，基於Hadoop生態圈，在NoSQL蓬勃發展的今天被國內外衆多公司選擇，應用於現代互聯網系統的不一樣業務。本文簡要描述了HBase的基本架構和使用場景，重點分析了HBase關鍵特性在此場景下的表現，以及HBase在使用上尚存的痛點；同時介紹了華爲自研的強一致、持久化 NoSQL數據庫GaussDB(for Redis)（下文簡稱高斯Redis）在以上場景中的表現，以及對於HBase痛點問題的改善。

1. HBase系統簡述

HBase的物理結構主要包括ZooKeeper、 HMaster、 RegionServer、HDFS 等組件。 ZooKeeper 用以實現 HMaster 的高可用、 RegionServer 的監控、元數據的入口以及集羣配置的維護等工做。HMaster的做用是維護整個集羣的Region信息，處理元數據變動及負載均衡工做。RegionServer是直接處理用戶讀寫請求的節點，實際處理所分配Region的讀寫、分裂等工做，並使用WAL實現容錯機制。HDFS提供最終的底層數據存儲服務，提供元數據和表數據的底層分佈式存儲服務，同時利用數據多副本，保證的高可靠和高可用性。

在邏輯結構中，RowKey是表的主鍵，並按照字典序進行排列，HRegion 達到必定大小後也會按照 RowKey 範圍進行裂變。ColumnFamily在縱向上對錶進行切分，將多個Column分紅一組進行管理，在HBase中，ColumnFamily是表的schema而Column不是。Cell則是保存的具體value，在HBase中，全部的數據都是以字節碼的方式進行存儲。

2.HBase大顯身手

2.1標籤數據的存儲

標籤數據是稀疏矩陣的表明，描述了實體的各種屬性，主要應用於智能推薦、商務智能或營銷引擎等領域。

三個不一樣的用戶在同一公司旗下的不一樣APP中留下了大量的行爲數據，這些數據中包含了直接填寫的用戶資料、使用APP的具體行爲以及領域專家對某些現象的標記，經過後臺的標籤算法能夠獲得這樣的數據：

咱們能發現，對用戶行爲採集存在侷限性，所以所能獲得的標籤種類各不相同，表中大量的數據項只能被置空，也就是所謂的稀疏矩陣。並且隨着用戶更深度的使用APP，能夠預見到，對用戶感興趣領域/不感興趣領域會逐漸被髮掘，那麼表的列也會隨之增長。

這樣的特色對於MySQL是災難性的，這是由於在MySQL建表時就必須定義表結構，屬性的動態增刪是巨大的工做量，同時大量NULL值的存儲會致使存儲成本變得難以接受。可是使用HBase存儲時，未指定value的列不會佔用任何的存儲空間，於是能夠將有限的資源高效利用，且HBase表在建立時只需指定ColumnFamily，而對於Column的增刪極爲容易，有利於應對將來屬性的擴張。

2.2 車聯網數據的收集

車聯網系統是利用車載設備收集車輛運行時產生的各項數據，經過網絡實時上傳，在平臺進行動態分析和利用。

咱們能夠發現，車聯網系統所面對的數據特色是大量車輛終端高併發的不間斷寫入TB級甚至PB級的數據，並且對於實時分析來講，爲了保證分析結果的時效性，又要求查詢的低時延響應。

HBase採用LSM存儲模型，能夠從容應對高併發寫入的場景，同時也能保證讀時延在可接受的範圍內。同時HBase具備良好的水平擴展能力。經過增減RegionServer來實現對存儲容量動態調整，知足對使用成本的要求。

2.3 交易記錄的保存

在移動支付領域，保證歷史交易記錄等敏感信息的安全性是一個重要的話題。當數據中心遭遇天然災害、外部攻擊時，必須保證這些信息不丟，並且從業務角度要保證RTO儘量短、RPO儘量爲0。

HBase基於底層的HDFS做爲存儲系統，HDFS實現了三副本策略，按照必定的規則將副本放在不一樣的節點或機架中，自己具備較高的容災能力。在工程實踐中，也產生了Region replica、主備集羣、互備雙活等策略來儘量進行災備並保證高可用。

3.HBase並不全能

從上文三個例子能夠看出，HBase基於其自己的設計，在稀疏矩陣的存儲、抗高併發大流量寫入、高可用和高可靠場景下表現得至關優秀，但這並不意味着HBase能夠沒有任何弱點的適應全部場景。

3.1HBase的阿克琉斯之踵

1. 朱麗葉暫停

Java系統繞不開Full GC的討論。HBase在Full GC形成STW時，ZooKeeper將收不到來自RegionServer的心跳，進而將此節點斷定爲宕機，由其餘節點接管數據，當Full GC結束後，RegionServer爲防止腦裂而主動自殺，稱之爲朱麗葉暫停。這類問題通常須要資深的java程序員根據業務場景進行細緻的GC策略調優才能儘量避免。

2. 數據類型少

HBase支持存儲的類型是字節數組，在使用中須要將字符串、複雜對象、甚至圖像等數據轉化爲字節數組進行存儲。可是這樣的存儲只能表示鬆散的數據關係，對於集合、隊列、Map等數據結構或數據關係，則須要開發人員編碼實現轉換邏輯才能進行存儲，靈活性較差。

3. 性能之瓶頸

HBase是按照RowKey的字典序分割爲Region進行存儲的，不佳的RowKey設計方案會形成負載不均，請求大量打到某一個Region造成熱點，那麼所在RegionServer的IO有可能被打爆。

RegionServer掉線後，須要由ZooKeeper發現節點宕機，將其負責的數據移動到其餘節點接管，並對meta表中的Region信息進行修改。在此過程當中，RegionServer上的數據將變得不可用，對於這部分數據的請求會被阻塞。

3.2 Redis的伊卡洛斯之翼

3.2.1 開源Redis的良好表現

開源Redis的特性在必定程度上解決了HBase的痛點問題，因其具備如下優勢：

1. 更豐富的數據類型

Redis 5.0協議中包含了String、List、Set、ZSet、Hash、Bit Array、HyperLogLog、Geospatial Index、Streams九種數據類型，以及創建在這些數據類型上的相關操做。與HBase的單一數據類型相比，Redis給了開發人員更多的選擇空間來表達數據和數據間的相互關係。

2. 純內存的絲滑感覺

開源Redis的本質是一個key-value類型的內存數據庫，整個數據庫都加載在內存中進行操做。這也就意味着Redis的響應速度和處理能力遠超過須要進行磁盤IO的HBase，目前大量的測試結果都代表，開源Redis的性能能夠達到每秒10萬次讀寫。

3.2.2 開源Redis的顯著弱點

純內存的操做也使得開源Redis有沒法避免的弱點，主要體如今如下兩方面：

1. 大數據量下的噩夢

當數據量持續增大時，有限的內存成爲使用限制。此時必須使用更大容量的內存才能完成數據的全量加載，而內存價格遠高於磁盤價格，會致使使用成本的激增。同時常見的服務器內存可能是GB級，也嚴重限制了開源Redis在高量級數據庫領域的競爭力。

2. 斷電後該何去何從

純內存操做的另外一弊端是宕機後數據會所有丟失。現有的解決方案是使用AOF或RDB的方式將數據持久化，進程重啓後能夠在內存中將數據恢復。但這兩種方式並不完備，AOF是執行命令的集合，所以恢復速度相對較慢；RDB是按期dump內存數據，所以存在數據丟失的風險。除此以外，在最壞場景下須要預留一半內存，下降了內存的使用率。

4.高斯Redis：成年人不作選擇題

HBase和開源Redis各有所長，這時一句熟悉的話在腦海中浮現：小孩子才作選擇題，成年人固然是全都要，高斯Redis的兼具兩者優勢，更好的知足了對數據庫服務的需求。

• 兼容Redis5.0協議

延續開源Redis的豐富數據類型，爲描述數據和數據關係提供更多選擇。例如在稀疏矩陣場景使用Hash類型，甚至無需定義HBase表ColumnFamily，能夠更靈活的進行數據組織。

• 性能追平開源Redis

參考【華爲雲高斯DB(for Redis)與開源Redis集羣性能對比】能夠看出，高斯Redis與開源Redis的性能幾乎相同，在大流量高併發的場景中，能夠提供比HBase更好的讀寫表現。

• 更高的災備可靠性

高斯Redis基於華爲自研的分佈式、強一致數據湖DFV構建的存儲層，在部分局點的已經上線了3AZ特性，AZ間作到風火水電的物理隔離，一個AZ的故障不會影響到其餘AZ，與HBase相比更好保證了關鍵數據的可靠性。

• 秒級彈性伸縮

高斯Redis使用存算分離架構，數據下沉至存儲池，計算節點擴縮容僅修改映射無需搬遷數據，實現秒級平滑伸縮，不存在HBase在Region上下線時出現的數據不可用問題。

• 低成本海量持久化存儲

全量數據通過邏輯和物理壓縮，將落入共享存儲池DFV持久化存儲，無宕機數據丟失問題，每GB的綜合成本不到開源Redis的十分之一。實際應用中可根據業務須要隨時對DFV容量進行擴容，不存在開源Redis存儲受限的問題。

• 自動化監控運維等其餘優點

高斯Redis配套全面的監控系統可對請求時延等關鍵性能指標可視化監控，同時可實現故障節點自動摘除、平滑移動、自動告警、自動恢復。此外，高斯Redis利用hash策略對數據進行均衡，與HBase相比更好的避免了熱點問題，並且不存在Full GC煩惱。

5.結語

高斯Redis在兼容Redis5.0協議的基礎上，兼具開源Redis和HBase各自優勢，結合華爲自研DFV存儲的相關特性，規避HBase和開源Redis在典型場景下的弱點，提供成本更低、性能更好、靈活性更強的數據庫服務。

6.附錄

本文做者：華爲雲高斯Redis團隊。

杭州西安深圳簡歷投遞：yuwenlong4@huawei.com

更多技術文章，請關注高斯Redis官方博客：
https://bbs.huaweicloud.com/c...

高斯Redis官方首頁：
https://www.huaweicloud.com/p...

點擊關注，第一時間瞭解華爲雲新鮮技術~