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

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

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

1.爲何須要二級索引

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

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

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

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

  • 基於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)
  • 開源/社區活躍程度:開源,目前社區不太活躍
  • 優勢:社區文檔多、使用簡單、實時查詢無延遲
  • 缺點:非商業化方案,沒有專門的技術支持

雲廠商自研的二級索引(典型表明阿里雲自研加強版二級索引)ide

  • 官方文檔: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的原理和最佳實踐,敬請期待!

看到這裏了,原創不易,點個關注、點個贊吧,你最好看了~

知識碎片從新梳理,構建Java知識圖譜:https://github.com/saigu/JavaKnowledgeGraph

相關文章
相關標籤/搜索