HBase高表與寬表怎么選擇

這篇文章主要講解了“HBase高表與寬表怎么選擇”，文中的講解內(nèi)容簡單清晰，易于學(xué)習(xí)與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學(xué)習(xí)“HBase高表與寬表怎么選擇”吧！

hbase中的寬表是指很多列較少行，即列多行少的表，一行中的數(shù)據(jù)量較大，行數(shù)少；高表是指很多行較少列，即行多列少，一行中的數(shù)據(jù)量較少，行數(shù)大。

hbase的row key是分布式的索引，也是分片的依據(jù)。
hbase的row key + column family + column qualifier + timestamp + value 是HFile中數(shù)據(jù)排列依據(jù)。HFile據(jù)此，對數(shù)據(jù)的索引到data block級別，而不是行級別。所以這種key是HFile內(nèi)部的粗粒度（data block粒度）本地索引的主鍵。

據(jù)此，在HBase中使用寬表、高表的優(yōu)劣總結(jié)如下：

• 查詢性能：高表更好，因?yàn)椴樵儣l件都在row key中, 是全局分布式索引的一部分。高表一行中的數(shù)據(jù)較少。所以查詢緩存BlockCache能緩存更多的行，以行數(shù)為單位的吞吐量會更高。

• 分片能力：高表分片粒度更細(xì)，各個分片的大小更均衡。因?yàn)楦弑硪恍械臄?shù)據(jù)較少，寬表一行的數(shù)據(jù)較多。HBase按行來分片。

• 元數(shù)據(jù)開銷：高表元數(shù)據(jù)開銷更大。高表行多，row key多，可能造成region數(shù)量也多，- root -、 .meta表數(shù)據(jù)量更大。過大的元數(shù)據(jù)開銷，可能引起HBase集群的不穩(wěn)定、master更大的負(fù)擔(dān)（這方面后續(xù)再好好總結(jié)）。

• 事務(wù)能力：寬表事務(wù)性更好。HBase對一行的寫入（Put）是有事務(wù)原子性的，一行的所有列要么全部寫入成功，要么全部沒有寫入。但是多行的更新之間沒有事務(wù)性保證。

• 數(shù)據(jù)壓縮比：如果我們對一行內(nèi)的數(shù)據(jù)進(jìn)行壓縮，寬表能獲得更高的壓縮比。因?yàn)閷挶碇?，一行的?shù)據(jù)量較大，往往存在更多相似的二進(jìn)制字節(jié)，有利于提高壓縮比。通過壓縮，緩解了寬表一行數(shù)據(jù)量太大，并導(dǎo)致分片大小不均勻的問題。查詢時(shí)，我們根據(jù)row key找到壓縮后的數(shù)據(jù)，進(jìn)行解壓縮。而且解壓縮可以通過協(xié)處理器（coproesssor）在HBase服務(wù)器上做，而不是在業(yè)務(wù)應(yīng)用的服務(wù)器上做，以充分應(yīng)用HBase集群的CPU能力。

設(shè)計(jì)表時(shí)，可以不絕對追求高表、寬表，而是在兩者之間做好**平衡**。根據(jù)查詢模式，需要分布式索引、分片、**有很高選擇度**（即能據(jù)此查詢條件迅速鎖定很小范圍的一些行）的查詢用字段，應(yīng)該放入row key；能夠均勻地劃分?jǐn)?shù)據(jù)字節(jié)數(shù)的字段，也應(yīng)該放入row key，作為分片的依據(jù)。選擇度較低，并且不需要作為分片依據(jù)的查詢用字段，放入column family和column qualifier，不放入row key。

感謝各位的閱讀，以上就是“HBase高表與寬表怎么選擇”的內(nèi)容了，經(jīng)過本文的學(xué)習(xí)后，相信大家對HBase高表與寬表怎么選擇這一問題有了更深刻的體會，具體使用情況還需要大家實(shí)踐驗(yàn)證。這里是億速云，小編將為大家推送更多相關(guān)知識點(diǎn)的文章，歡迎關(guān)注！