hbase屬于什么技術(shù)?HBase – Hadoop Database,是一個高可靠性、高性能、面向列、可伸縮的分布式存儲系統(tǒng),利用HBase技術(shù)可在廉價PC Server上搭建起大規(guī)模結(jié)構(gòu)化存儲集群。
HBase是Google BigTable的開源實現(xiàn),類似Google BigTable利用GFS作為其文件存儲系統(tǒng),HBase利用Hadoop HDFS作為其文件存儲系統(tǒng);Google運(yùn)行MapReduce來處理Bigtable中的海量數(shù)據(jù),HBase同樣利用Hadoop MapReduce來處理HBase中的海量數(shù)據(jù);Google Bigtable利用 Chubby作為協(xié)同服務(wù),HBase利用Zookeeper作為對應(yīng)。
Hbase的特點
1、海量存儲,Hbase適合存儲PB級別的海量數(shù)據(jù),在PB級別的數(shù)據(jù)以及采用廉價PC存儲的情況下,能在幾十到百毫秒內(nèi)返回數(shù)據(jù),因為Hbase良好的擴(kuò)展性,才為海量數(shù)據(jù)的存儲提供了便利。
2、列式存儲,這里的列式存儲其實說的是列族存儲,Hbase是根據(jù)列族來存儲數(shù)據(jù)的。列族下面可以有非常多的列,列族在創(chuàng)建表的時候就必須指定。
3、極易擴(kuò)展,Hbase的擴(kuò)展性主要體現(xiàn)在兩個方面,一個是基于上層處理能力(RegionServer)的擴(kuò)展,一個是基于存儲的擴(kuò)展(HDFS)。
4、高并發(fā),由于目前大部分使用Hbase的架構(gòu),這里說的高并發(fā),主要是在并發(fā)的情況下,Hbase的單個IO延遲下降并不多。能獲得高并發(fā)、低延遲的服務(wù)。
5、稀疏,稀疏主要是針對Hbase列的靈活性,在列族中,你可以指定任意多的列,在列數(shù)據(jù)為空的情況下,是不會占用存儲空間的。
使用場景
HBase并不適合所有場景
首先,數(shù)據(jù)量方面。確信有足夠多數(shù)據(jù),如果有上億或十億行數(shù)據(jù),至少單表數(shù)據(jù)量超過千萬,HBase會是一個很好的選擇。如果只有上千或上百萬行,用傳統(tǒng)的RDBMS可能是更好的選擇。
其次,關(guān)系型數(shù)據(jù)庫特性方面。確信可以不依賴所有RDBMS的額外特性 (如列數(shù)據(jù)類型、二級索引、事務(wù)、高級查詢語言等) 。一個建立在RDBMS上應(yīng)用,并不能通過簡單的改變JDBC驅(qū)動就能遷移到HBase,需要一次完全的重新設(shè)計。
再次,硬件方面。確信你有足夠硬件。比如由于HDFS 的默認(rèn)副本是3,所以一般至少5個數(shù)據(jù)節(jié)點才能夠發(fā)揮其特性,另外 還要加上一個 NameNode節(jié)點。
最后,數(shù)據(jù)分析方面。數(shù)據(jù)分析是HBase的弱項,因為對于HBase乃至整個NoSQL生態(tài)圈來說,基本上都是不支持表關(guān)聯(lián)的。如果主要需求是數(shù)據(jù)分析,比如做報表,顯然HBase是不太合適的。
什么時候使用 HBase
HBase作為一款NoSQL數(shù)據(jù)庫,前面也提及了并不能解決所有問題。關(guān)于我們在實際生產(chǎn)過程中滿足哪些條件的時候可以選擇HBase作為底層存儲,這里給出幾點建議:
1、數(shù)據(jù)量規(guī)模非常龐大
一般而言,單表數(shù)據(jù)量如果只有百萬級或者更少,不是非常建議使用HBase而應(yīng)該考慮關(guān)系型數(shù)據(jù)庫是否能夠滿足需求;單表數(shù)據(jù)量超過千萬或者十億百億的時候,并且伴有較高并發(fā),可以考慮使用HBase。這主要是充分利用分布式存儲系統(tǒng)的優(yōu)勢,如果數(shù)據(jù)量比較小,單個節(jié)點就能有效存儲的話則其他節(jié)點的資源就會存在浪費。
2、要求是實時的點查詢
HBase是一個Key-Value數(shù)據(jù)庫,默認(rèn)對Rowkey即行鍵做了索引優(yōu)化,所以即使數(shù)據(jù)量非常龐大,根據(jù)行鍵的查詢效率依然會很高,這使得HBase非常適合根據(jù)行鍵做單條記錄的查詢。值得說明的是,允許根據(jù)行鍵的一部分做范圍查詢,這里涉及到Rowkey的設(shè)計問題,不再贅言。
3、能夠容忍N(yùn)oSQL短板
前面提及了NoSQL并不能解決所有問題,HBase也是一樣,如果業(yè)務(wù)場景是需要事務(wù)支持、表與表的關(guān)聯(lián)查詢等,不建議使用HBase。HBase有它適合的業(yè)務(wù)場景,我們不能苛求它能夠幫我們解決所有問題。
4、數(shù)據(jù)分析需求并不多
雖然說HBase是一個面向列的數(shù)據(jù)庫,但它有別于真正的列式存儲系統(tǒng)比如Parquet、Kudu等,再加上自身存儲架構(gòu)的設(shè)計,使得HBase并不擅長做數(shù)據(jù)分析,或者說數(shù)據(jù)分析是HBase的弱項,所以如果主要的業(yè)務(wù)需求就是為了做數(shù)據(jù)分析,比如做報表,那么不建議直接使用HBase。
如果能夠滿足上訴的幾點,硬件條件也滿足的情況下,強(qiáng)烈建議考慮使用HBase作為底層存儲解決你的問題。