HBase二級索引的解決方法

這篇文章將為大家詳細(xì)講解有關(guān)HBase二級索引的解決方法，文章內(nèi)容質(zhì)量較高，因此小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關(guān)知識有一定的了解。

HBase一個令人惋惜的地方，就是不支持二級索引。因此，社區(qū)有了很多補(bǔ)充方案來填補(bǔ)HBase的二級索引能力的缺陷。

今天，我們就來看看有哪些二級索引方案，通過對比各個方案的優(yōu)缺點，并結(jié)合我們的具體場景做出二級索引方案選型。

1.為什么需要二級索引

HBase系統(tǒng)單純從解決大數(shù)據(jù)實時讀寫問題角度出發(fā)，重點關(guān)注于分布式存儲的擴(kuò)展性、容錯性、讀寫性能等方面，為此也犧牲了很多傳統(tǒng)關(guān)系型數(shù)據(jù)庫的功能，比如事務(wù)，SQL表達(dá)與分析等。

實際上，這是NoSQL最初的含義，以解決大數(shù)據(jù)的實時存取為首要目標(biāo)，提供簡單的Get，Put，Scan接口，解決用戶的大數(shù)據(jù)量存儲的需求。因此，HBase完全是一個非常優(yōu)秀的大數(shù)據(jù)實時存取引擎，解決了傳統(tǒng)數(shù)據(jù)庫的容量問題。

就目前官方的HBase系統(tǒng)來說，并不支持二級索引，只有rowkey作為一級索引， 如果要對庫里的非rowkey字段進(jìn)行數(shù)據(jù)檢索和查詢， 往往要通過MapReduce/Spark等分布式計算框架進(jìn)行，硬件資源消耗和時間延遲都會比較高。

為了HBase的數(shù)據(jù)查詢更高效、適應(yīng)更多的場景， 諸如使用非rowkey字段檢索也能做到秒級響應(yīng)，或者支持各個字段進(jìn)行模糊查詢和多字段組合查詢等， 因此需要在原生HBase基礎(chǔ)上構(gòu)建二級索引， 以滿足現(xiàn)實中更復(fù)雜多樣的業(yè)務(wù)需求。一般有以下三類方案：

• 基于HBase的Coprocessor的方案（典型代表phoenix）

• 云廠商自研的二級索引（阿里云目前有自研增強(qiáng)版二級索引）

• 基于搜索平臺的索引方案（如solr、ES等）。

2.如何選擇二級索引方案

我們從讀寫性能、使用限制、學(xué)習(xí)成本、社區(qū)活躍等角度，對三類方案做對比。

基于HBase的Coprocessor的方案（典型代表phoenix）

• 官方文檔：http://phoenix.apache.org/secondary_indexing.html

• 讀寫性能：有一定讀寫性能損害，索引越多，寫入性能影響越大

• TTL功能：支持比較好

• 索引的使用限制：一個表的索引數(shù)不要超過10個

• 索引類型：全局索引、本地索引、覆蓋索引

• 學(xué)習(xí)成本：類JDBC的sql語法，多參考官方的語法（http://phoenix.apache.org/language/index.html）

• 開源/社區(qū)活躍程度：開源，目前社區(qū)不太活躍

• 優(yōu)點：社區(qū)文檔多、使用簡單、實時查詢無延遲

• 缺點：非商業(yè)化方案，沒有專門的技術(shù)支持

云廠商自研的二級索引（典型代表阿里云自研增強(qiáng)版二級索引）

• 官方文檔：https://help.aliyun.com/document_detail/144577.html?spm=a2c4g.11174283.6.576.4999363f2uZWt0

• 讀寫性能：二級索引內(nèi)置于HBase，官方的性能評測文檔說比Phoenix好

• TTL功能：只能在單列索引上生效

• 索引的使用限制：一個表的索引個數(shù)最多不超過5個、組合索引的列最多不要超過3個

• 索引類型：全局索引、本地索引、覆蓋索引

• 學(xué)習(xí)成本：內(nèi)部封裝的很簡單，在使用上就是HBase的原生用法

• 開源/社區(qū)活躍程度：非開源、阿里云私有

• 優(yōu)點：性能好、實時查詢無延遲

• 缺點：被云廠商鎖定

基于搜索平臺的二級索引方案（以Solr為例）

• 官方文檔：http://phoenix.apache.org/secondary_indexing.html

• 讀寫性能：有一定讀寫性能損害、數(shù)據(jù)同步的延遲需要考慮

• TTL功能：HBase是單個KV過期，而Solr中只能按照Document（對應(yīng)HBase的一行）過期，過期的時間不完全一致

• 索引的使用限制：沒有限制，完全取決于solr

• 索引類型：非常靈活

• 學(xué)習(xí)成本：需要熟悉solr語法

• 開源/社區(qū)活躍程度：開源 社區(qū)活躍

• 優(yōu)點：查詢方式更加靈活

• 缺點：引入搜索引擎組件、太重了，而且有明顯的延遲問題

總結(jié)一下（特別重要的技術(shù)選型策略）：

• 為了不被云廠商鎖定，所以不采用云廠商獨有的二級索引方案

• 對于實時性要求高、索引數(shù)量少的場景，完全可以使用phoenix，簡單而又絲滑

• 對于實時性要求不高、搜索場景比較復(fù)雜的，需要引入搜索引擎，如solr或者es進(jìn)行索引構(gòu)建

一般來說，為了滿足實時需求，我們會使用phoenix。

3.簡單了解下phoenix

為了讓HBase更強(qiáng)大，更好用，門檻更低，讓HBase幫助更多的用戶解決他們遇到的實際問題。于是，phoenix帶著SQL誕生了。眾所周知，SQL是數(shù)據(jù)處理領(lǐng)域的語言標(biāo)準(zhǔn)，簡單，好用，表達(dá)力強(qiáng)，用戶使用廣泛。當(dāng)然，HBase SQL的實現(xiàn)和發(fā)展跟傳統(tǒng)單機(jī)數(shù)據(jù)庫有很多不同，便于區(qū)別，我們稱之為NewSQL。這也是社區(qū)嘗試HBase二級索引的初衷，如果說HBase是功能強(qiáng)大的存儲引擎，那么支持NewSQL之后，就變成了新一代的大飛機(jī)。

Phoenix作為應(yīng)用層和HBASE之間的中間件,以下特性使它在大數(shù)據(jù)量的簡單查詢場景有著獨有的優(yōu)勢

• 二級索引支持(global index + local index)

• 編譯SQL成為原生HBASE的可并行執(zhí)行的scan

• 在數(shù)據(jù)層完成計算，server端的coprocessor執(zhí)行聚合

• 下推where過濾條件到server端的scan filter上

• skip scan功能提高掃描速度

關(guān)于HBase二級索引的解決方法就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，可以學(xué)到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。