華為云企業級Redis揭秘第九期:高斯Redis與HBase對比優勢

      網友投稿 686 2022-05-29

      【最新活動】企業級Redis專場熱銷中!首月免費,包年僅需4折!

      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中,所有的數據都是以字節碼的方式進行存儲。

      華為云企業級Redis揭秘第九期:高斯Redis與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的伊卡洛斯之翼

      開源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萬次讀寫。

      純內存的操作也使得開源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在典型場景下的弱點,提供成本更低、性能更好、靈活性更強的數據庫服務。

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

      GaussDB(for Redis)產品主頁:

      https://www.huaweicloud.com/product/gaussdbforredis.html

      更多技術文章,關注GaussDB(for Redis)官方博客:

      https://bbs.huaweicloud.com/community/usersnew/id_1614151726110813

      HBase Redis 云數據庫 GaussDB(for Redis) 數據庫 緩存

      版權聲明:本文內容由網絡用戶投稿,版權歸原作者所有,本站不擁有其著作權,亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容,請聯系我們jiasou666@gmail.com 處理,核實后本網站將在24小時內刪除侵權內容。

      上一篇:gui事件處理機制
      下一篇:互聯網公司面試必問的Redis題目
      相關文章
      亚洲成熟xxxxx电影| 亚洲精品国产精品乱码视色 | 国产偷窥女洗浴在线观看亚洲| 亚洲日韩精品射精日| 亚洲性一级理论片在线观看| 亚洲国产免费综合| 亚洲网址在线观看| 不卡一卡二卡三亚洲| 国产亚洲精彩视频| 亚洲Av高清一区二区三区| 亚洲一区二区三区自拍公司| 成人亚洲性情网站WWW在线观看| 亚洲国产一级在线观看| 亚洲欧洲精品成人久久奇米网 | 精品久久久久久亚洲综合网| 亚洲成a人不卡在线观看| 亚洲日本国产乱码va在线观看| 亚洲小说区图片区| tom影院亚洲国产一区二区| 久久精品亚洲中文字幕无码网站| 无码欧精品亚洲日韩一区夜夜嗨| 亚洲一区二区影视| 亚洲avav天堂av在线网爱情| 中文字幕亚洲码在线| 亚洲欧洲日产国码一级毛片 | 亚洲无码黄色网址| 国产亚洲精品资源在线26u| 亚洲无人区一区二区三区| 亚洲精品tv久久久久久久久久| 亚洲中文字幕无码专区| 亚洲精品无码久久久久APP| 亚洲综合激情六月婷婷在线观看| 91亚洲国产成人久久精品| 亚洲男人都懂得羞羞网站| 亚洲网站视频在线观看| 亚洲AV综合色区无码二区偷拍 | 91丁香亚洲综合社区| 亚洲AV无码AV吞精久久| 国产精品亚洲综合久久| 亚洲一区二区三区免费观看| 亚洲日本VA午夜在线影院|