「從零單排HBase 11」HBase二級索引解決方案

不知不覺超預算3倍，618你爲什麼買買買停不下來？從技術維度一探究！>>>

HBase一個使人可惜的地方，就是不支持二級索引。所以，社區有了不少補充方案來填補HBase的二級索引能力的缺陷。

今天，咱們就來看看有哪些二級索引方案，經過對比各個方案的優缺點，並結合咱們的具體場景作出二級索引方案選型。

1.爲何須要二級索引

HBase系統單純從解決大數據實時讀寫問題角度出發，重點關注於分佈式存儲的擴展性、容錯性、讀寫性能等方面，爲此也犧牲了不少傳統關係型數據庫的功能，好比事務，SQL表達與分析等。

實際上，這是NoSQL最初的含義，以解決大數據的實時存取爲首要目標，提供簡單的Get，Put，Scan接口，解決用戶的大數據量存儲的需求。所以，HBase徹底是一個很是優秀的大數據實時存取引擎，解決了傳統數據庫的容量問題。

就目前官方的HBase系統來講，並不支持二級索引，只有rowkey做爲一級索引， 若是要對庫裏的非rowkey字段進行數據檢索和查詢， 每每要經過MapReduce/Spark等分佈式計算框架進行，硬件資源消耗和時間延遲都會比較高。

爲了HBase的數據查詢更高效、適應更多的場景， 諸如使用非rowkey字段檢索也能作到秒級響應，或者支持各個字段進行模糊查詢和多字段組合查詢等， 所以須要在原生HBase基礎上構建二級索引， 以知足現實中更復雜多樣的業務需求。通常有如下三類方案：

• 基於HBase的Coprocessor的方案（典型表明phoenix）

• 雲廠商自研的二級索引（阿里雲目前有自研加強版二級索引）

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

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

咱們從讀寫性能、使用限制、學習成本、社區活躍等角度，對三類方案作對比。

基於HBase的Coprocessor的方案（典型表明phoenix）

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

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

• TTL功能：支持比較好

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

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

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

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

• 優勢：社區文檔多、使用簡單、實時查詢無延遲

• 缺點：非商業化方案，沒有專門的技術支持

雲廠商自研的二級索引（典型表明阿里雲自研加強版二級索引）

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

• 讀寫性能：二級索引內置於HBase，官方的性能評測文檔說比Phoenix好

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

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

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

• 學習成本：內部封裝的很簡單，在使用上就是HBase的原生用法

• 開源/社區活躍程度：非開源、阿里雲私有

• 優勢：性能好、實時查詢無延遲

• 缺點：被雲廠商鎖定

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

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

• 讀寫性能：有必定讀寫性能損害、數據同步的延遲須要考慮

• TTL功能：HBase是單個KV過時，而Solr中只能按照Document（對應HBase的一行）過時，過時的時間不徹底一致

• 索引的使用限制：沒有限制，徹底取決於solr

• 索引類型：很是靈活

• 學習成本：須要熟悉solr語法

• 開源/社區活躍程度：開源 社區活躍

• 優勢：查詢方式更加靈活

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

總結一下（特別重要的技術選型策略）：

• 爲了避免被雲廠商鎖定，因此不採用雲廠商獨有的二級索引方案

• 對於實時性要求高、索引數量少的場景，徹底可使用phoenix，簡單而又絲滑

• 對於實時性要求不高、搜索場景比較複雜的，須要引入搜索引擎，如solr或者es進行索引構建

通常來講，爲了知足實時需求，咱們會使用phoenix。

3.簡單瞭解下phoenix

爲了讓HBase更強大，更好用，門檻更低，讓HBase幫助更多的用戶解決他們遇到的實際問題。因而，phoenix帶着SQL誕生了。衆所周知，SQL是數據處理領域的語言標準，簡單，好用，表達力強，用戶使用普遍。固然，HBase SQL的實現和發展跟傳統單機數據庫有不少不一樣，便於區別，咱們稱之爲NewSQL。這也是社區嘗試HBase二級索引的初衷，若是說HBase是功能強大的存儲引擎，那麼支持NewSQL以後，就變成了新一代的大飛機。

Phoenix做爲應用層和HBASE之間的中間件,如下特性使它在大數據量的簡單查詢場景有着獨有的優點

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

• 編譯SQL成爲原生HBASE的可並行執行的scan

• 在數據層完成計算，server端的coprocessor執行聚合

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

• skip scan功能提升掃描速度

下一期，咱們將結合實踐，來講明phoenix的原理和最佳實踐，敬請期待！

原創：阿丸筆記（微信公衆號：aone_note），歡迎 分享，轉載請保留出處。

掃描下方二維碼能夠關注我哦～

                                                                              以爲不錯，就點個  再看 吧????

本文分享自微信公衆號 - 阿丸筆記（aone_note）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。