HBase可以替代redis嗎?

01-15

線上請求直接訪問Hbase是否可行呢？

現在的架構，導致hbase對寫友好，對讀就差了些許。

LSM 模型造成的

我做過一個用hbase做線上高並發的任務，但是是在前面加了緩存層，榮譽是緩存層的。

對於線上的請求，redis等類似的cache系統是不可缺少的工具。

---

hbase 可以用來做數據的固化，也就是數據存儲，做這個他非常合適。

redis適合做cache，也就是系統的訪問。好消息是現在基於redis的分散式方案也不少，不用擔心單機的性能或者內存不夠用的情況。

cache+storage 是比較經典的組合。

---

這個組合最大的問題估計就是數據一致性的問題了，我有簡單的方法

1. cache miss tag

2. cache read not write

hbase慢

兩個不能互相替代，只能互相彌補，redis是基於內存的，而hbase基於hdfs。

1、hbase：可以存儲上億的數據，適合存儲大數據，可以基於rowkey掃描數據，作為大數據存儲資料庫的不錯選擇。

2、redis：基於內存的，速度比hbase快，但是不能作為大數據存儲，但是適合一些批量數據，快速讀取，作為臨時數據緩存的不錯選擇。

二者都屬於NoSQL，但又有很大不同：

HBase是一個分散式的、面向列的開源資料庫，它是Apache的Hadoop項目的子項目。最初來源於 Fay Chang 所撰寫的Google論文「Bigtable：一個結構化數據的分散式存儲系統」。一般和HDFS一起結合使用，能存儲海量數據。

Redis是一個開源的使用ANSI C語言編寫、支持網路、基於內存的日誌型、Key-Value資料庫；優勢是速度快，並發高，缺點是數據類型有限，查詢功能不強，一般用作緩存（當做DB用的，更多是允許丟失的數據）。

綜上，不存在誰替代誰，還是那句不變的話：「根據具體業務場景、數據量選擇最合適的就好」。

兩個場景有點不同。

hbase是屬於hadoop生態圈的組件，不可能脫離hdfs使用的。hbase部署起來較重，需要有一定人力搞定它。但是優點也是很明顯的，作為分散式資料庫，容災以及擴展性都很棒。

redis更適合小場景的需求，優點是速度快，作為緩存是個不錯的選擇。但是大數據肯定不夠玩。

最後回答一下樓主的問題，hbase是可以作為線上系統的後台的，實時性是建立在你們對錶的設計和優化上的。如果人力允許，完全可以用hbase+redis實現數據倉庫加緩存資料庫，速度和擴展性都兼顧。

目前正在做技術選型，有一些結論你可以參考一下：

redis

1. 速度快，響應穩定(&<10ms)

2. 數據持久化（落地）存在隱患

3. 分散式方案沒有或者不好，擴展起來不如hbase方便

4. 完全依靠內存容量，存儲容量大成本很高

hbase

1. 速度不如redis(10-200ms級別)，存在一些性能尖峰（毛刺）。

2. hadoop(hive)算完寫入hbase很方便

3. 對錶結構設計等要求較高，需要對hbase比較了解才可以規避一些性能陷阱

4. 擴展較redis容易，成本低

結論：

redis適合場景：性能要求高，存儲容量不是很大，可以接受內存成本高的

hbase適合場景：性能要求不是特別高，可以容忍一些請求是失敗的或者超時的

不存在誰替代誰的關係

本人不了解redis 但可以確定的是HBase諸多限制和問題肯定不會出現替代***的情況 (即便現處於高速發展態

各種場景都有各個db的角色孰勝孰優很難一刀斷

只能說HBase後台硬吧哈哈哈畢竟很多apache項目都有意支援HBase 例如火到炸開的spark

兩者功能上比較相近，都屬於nosql資料庫，都支持數據分片存儲，一般來講redis比較依賴內存，適合做緩存，hbase適合做大數據的持久存儲，兩者適合的場景不太一樣，主要區別有如下幾點：

1.讀寫性能：hbase採用了LSM結構，寫快讀慢，hbase讀延時在一般在幾毫秒，redis讀延時在幾十微秒，性能相差比較大

2.數據類型：hbase和redis都支持kv類型，但redis支持更豐富的集合類型list，set等

3.數據量：redis在熱數據比內存大時，性能下降比較厲害，非常依賴內存，hbase不存在這問題

4.部署複雜度：hbase部署複雜，依賴hadoop，zookeeper，redis部署簡單

5.數據持久化：hbase採用了WAL，先記錄日誌再寫入數據，理論上不會丟失數據，而redis採用的是非同步複製數據，failover時可能丟失數據

Cassandra+Row Cache可以在大數據量下可以完美替換Redis。

不行，redis較快，因為它把數據熱緩到內存，存儲大小有限，而hbase雖然也是k_v資料庫，但是它是大表資料庫，適合放大數據，速度慢redis。某些業務是可以互相替換的，但是redis並適合放持久性數據。

也想了解下高並發讀場景下hbase是否合適，不過樓上有人提到的用redis做一層緩存倒是很好的想法