国产精品精品视频一区二区三区,精品国产乱码一区二区三,欧美在线观看一区

Hbase 構(gòu)建二級索引的一些解決方案

1 為什么需要二級索引

HBase的一級索引就是rowkey，我們僅僅能通過rowkey進行檢索。假設(shè)我們相對Hbase里面列族的列列進行一些組合查詢，就只能全表掃描了。表如果較大的話，代價是不可接受的，所以要提出二級索引的方案。

二級索引的思想：簡單理解就是，根據(jù)列族的列的值，查出rowkey，再按照rowkey就能很快從hbase查詢出數(shù)據(jù)，我們需要構(gòu)建出根據(jù)列族的列的值，很快查出rowkey的方案。

2 常見的二級索引方案

MapReduce方案;
Coprocessor方案;
elasticsearch+hbase方案;
Solr+hbase方案;

2.1 MapReduce方案

IndexBuilder：利用MR的方式構(gòu)建Index 長處：并發(fā)批量構(gòu)建Index 缺點：不能實時構(gòu)建Index

舉例：原表：

row 1 f1:name zhangsan
row 2 f1:name lisi
row 3 f1:name wangwu

索引表：

row zhangsan f1:id 1
row lisi f1:id 2
row wangwu f1:id 3

這種方式的思想是再構(gòu)建一張hbase表，列族的列這里的name作為索引表的rowkey，根據(jù)rowkey查詢出數(shù)據(jù)hbase是很快的，拿到id后，也就拿到了原表的rowkey了，因為源表的rowkey就是id，每次查詢一共需要查詢兩張表。

2.2 Coprocessor方案

有關(guān)協(xié)處理器的講解，Hbase官方文檔是最好的，這里大體說一下它的作用與使用方法。

Coprocessor提供了一種機制可以讓開發(fā)者直接在RegionServer上運行自定義代碼來管理數(shù)據(jù)。通常我們使用get或者scan來從Hbase中獲取數(shù)據(jù)，使用Filter過濾掉不需要的部分，最后在獲得的數(shù)據(jù)上執(zhí)行業(yè)務(wù)邏輯。但是當數(shù)據(jù)量非常大的時候，這樣的方式就會在網(wǎng)絡(luò)層面上遇到瓶頸?？蛻舳艘残枰獜姶蟮挠嬎隳芰妥銐虼蟮膬?nèi)存來處理這么多的數(shù)據(jù)，客戶端的壓力就會大大增加。但是如果使用Coprocessor，就可以將業(yè)務(wù)代碼封裝，并在RegionServer上運行，也就是數(shù)據(jù)在哪里，我們就在哪里跑代碼，這樣就節(jié)省了很大的數(shù)據(jù)傳輸?shù)木W(wǎng)絡(luò)開銷。
Coprocessor有兩種：Observer和Endpoint EndPoint主要是做一些計算用的，比如計算一些平均值或者求和等等。而Observer的作用類似于傳統(tǒng)關(guān)系型數(shù)據(jù)庫的觸發(fā)器，在一些特定的操作之前或者之后觸發(fā)。學習過Spring的朋友肯定對AOP不陌生，想象一下AOP是怎么回事，就會很好的理解Observer了。Observer Coprocessor在一個特定的事件發(fā)生前或發(fā)生后觸發(fā)。在事件發(fā)生前觸發(fā)的Coprocessor需要重寫以pre作為前綴的方法，比如prePut。在事件發(fā)生后觸發(fā)的Coprocessor使用方法以post作為前綴，比如postPut。Observer Coprocessor的使用場景如下：2.1. 安全性：在執(zhí)行Get或Put操作前，通過preGet或prePut方法檢查是否允許該操作;2.2. 引用完整性約束：HBase并不直接支持關(guān)系型數(shù)據(jù)庫中的引用完整性約束概念，即通常所說的外鍵。但是我們可以使用Coprocessor增強這種約束。比如根據(jù)業(yè)務(wù)需要，我們每次寫入user表的同時也要向user_daily_attendance表中插入一條相應(yīng)的記錄，此時我們可以實現(xiàn)一個Coprocessor，在prePut方法中添加相應(yīng)的代碼實現(xiàn)這種業(yè)務(wù)需求。2.3. 二級索引：可以使用Coprocessor來維持一個二級索引。正是我們需要的

索引設(shè)計思想

關(guān)鍵部分來了，既然Hbase并沒有提供二級索引，那如何實現(xiàn)呢?先看下面這張圖

Hbase 構(gòu)建二級索引的一些解決方案

Coprocessor

我們的需求是找出滿足cf1:col2=c22這條記錄的cf1:col1的值，實現(xiàn)方法如圖，首先根據(jù)cf1:col2=c22查找到該記錄的行鍵，然后再通過行健找到對應(yīng)的cf1:col1的值。其中第二步是很容易實現(xiàn)的，因為Hbase的行鍵是有索引的，那關(guān)鍵就是第一步，如何通過cf1:col2的值找到它對應(yīng)的行鍵。很容易想到建立cf1:col2的映射關(guān)系，即將它們提取出來單獨放在一張索引表中，原表的值作為索引表的行鍵，原表的行鍵作為索引表的值，這就是Hbase的倒排索引的思想。

2.3 elasticsearch+hbase方案

比如說你現(xiàn)在有一行數(shù)據(jù)

id name age ….30 個字段

但是你現(xiàn)在搜索，只需要根據(jù) id name age 三個字段來搜索

如果你傻乎乎的往 es 里寫入一行數(shù)據(jù)所有的字段，就會導(dǎo)致說 70% 的數(shù)據(jù)是不用來搜索的，結(jié)果硬是占據(jù)了 es 機器上的 filesystem cache 的空間，單挑數(shù)據(jù)的數(shù)據(jù)量越大，就會導(dǎo)致 filesystem cahce 能緩存的數(shù)據(jù)就越少

僅僅只是寫入 es 中要用來檢索的少數(shù)幾個字段就可以了，比如說，就寫入 es id name age 三個字段就可以了，然后你可以把其他的字段數(shù)據(jù)存在 mysql 里面，我們一般是建議用 es + hbase 的這么一個架構(gòu)。

hbase 的特點是適用于海量數(shù)據(jù)的在線存儲，就是對 hbase 可以寫入海量數(shù)據(jù)，不要做復(fù)雜的搜索，就是做很簡單的一些根據(jù) id 或者范圍進行查詢的這么一個操作就可以了

從 es 中根據(jù) name 和 age 去搜索，拿到的結(jié)果可能就 20 個 doc id，然后根據(jù) doc id 到 hbase 里去查詢每個 doc id 對應(yīng)的完整的數(shù)據(jù)，給查出來，再返回給前端。

Hbase 構(gòu)建二級索引的一些解決方案

你最好是寫入 es 的數(shù)據(jù)小于等于，或者是略微大于 es 的 filesystem cache 的內(nèi)存容量

然后你從 es 檢索可能就花費 20ms，然后再根據(jù) es 返回的 id 去 hbase 里查詢，查 20 條數(shù)據(jù)，可能也就耗費個 30ms，可能你原來那么玩兒，1T 數(shù)據(jù)都放 es，會每次查詢都是 5 ~ 10 秒，現(xiàn)在可能性能就會很高，每次查詢就是 50ms。

四個字總結(jié)的話，我覺得就是“各司其職”，HBase 就用來存儲，ES 就用來做索引，況且目前的實際情況跟文章中說的也很像，要查詢的字段就幾個，而其他的字段又很大又沒用，沒必要都丟到 ES 中，浪費查詢效率

2.4 Solr+hbase方案

Solr是一個獨立的企業(yè)級搜索應(yīng)用server，它對并提供相似干Web-service的API接口。用戶能夠通過http請求，向搜索引擎server提交一定格式的XML文件，生成索引。也能夠通過Http Get操作提出查找請求，并得到XML格式的返回結(jié)果。

Solr是一個高性能。採用Java5開發(fā)。基干Lucene的全文搜索server。同一時候?qū)ζ溥M行了擴展。提供了比Lucene更為豐富的查詢語言，同一時候?qū)崿F(xiàn)了可配置、可擴展并對查詢性能進行了優(yōu)化，而且提供了一個完好的功能節(jié)理界面。是一款非常優(yōu)秀的全文搜索引擎。

HBase無可置疑擁有其優(yōu)勢，但其本身僅僅對rowkey支持毫秒級的高速檢索，對于多字段的組合查詢卻無能為力?；赟olr的HBase多條件查詢原理非常easy。將HBase表中涉及條件過濾的字段和rowkey在Solr中建立索引，通過Solr的多條件查詢高速獲得符合過濾條件的rowkey值，拿到這些rowkey之后在HBASE中通過指定rowkey進行查詢。

Hbase 構(gòu)建二級索引的一些解決方案