Lucene與HBase的組合使用及HBasene的報(bào)告分析

Lucene與HBase的組合使用及HBasene的報(bào)告分析，針對(duì)這個(gè)問題，這篇文章詳細(xì)介紹了相對(duì)應(yīng)的分析和解答，希望可以幫助更多想解決這個(gè)問題的小伙伴找到更簡(jiǎn)單易行的方法。

Lucene簡(jiǎn)介

　　Lucene中，以document的形式作為搜索的主體。document由fieldName和fieldValue所組成，每個(gè)fieldValue又可以由一個(gè)或多個(gè)term元素來組成。基于不同的分詞及索引規(guī)則，可用于搜索fieldValue的term少于組成fieldValue的term。Lucene的搜索基于反向索引，包含著可用于搜索document的field信息。通過Lucene，可以正向查找document，以便了解其包含哪些field信息；也可以通過反向索引，通過搜索字段的term，來查詢包含該term的document。

[ 圖1 ]  Lucene總體架構(gòu)

　　由圖1所示，IndexSearcher實(shí)現(xiàn)了搜索的邏輯，IndexWriter實(shí)現(xiàn)了文檔的插入與反向索引的建立，IndexReader由IndexSearcher調(diào)用以便讀取索引的內(nèi)容。IndexReader和IndexWriter都依賴于抽象類Directory，Directory提供操作索引數(shù)據(jù)及的API。

　　標(biāo)準(zhǔn)的Lucene是基于文件系統(tǒng)和基于內(nèi)存的。

　　標(biāo)準(zhǔn)基于文件系統(tǒng)的后端的缺點(diǎn)在于，隨著索引增加性能會(huì)下降，人們使用了各種不同的技術(shù)來解決這個(gè)問題，包括負(fù)載均衡和索引分片（index sharding，在多個(gè)Lucene實(shí)例之間切分索引）。盡管分片功能很強(qiáng)大，但它讓總體的實(shí)現(xiàn)架構(gòu)變得更復(fù)雜，并且需要大量對(duì)期望文檔的預(yù)測(cè)知識(shí)，才能對(duì)Lucene索引進(jìn)行合適地分片。另一方面，在大數(shù)據(jù)量的情況下，segment的合并花銷巨大；頻繁的update數(shù)據(jù)將使得Lucene對(duì)Disk io產(chǎn)生巨大的影響。一個(gè)新的數(shù)據(jù)的update，可能導(dǎo)致一部分根本沒有變化的索引被重寫很多次，并且可能導(dǎo)致很多的小的index segment，造成了search的性能下降。

　　Lucene的優(yōu)勢(shì)在于索引查找的迅速，而非document的存儲(chǔ)。為解決上述問題，基于NoSQL數(shù)據(jù)庫(kù)存儲(chǔ)索引的后端結(jié)構(gòu)應(yīng)運(yùn)而生。

以下，將基于HBase的實(shí)現(xiàn)來進(jìn)行分析。

實(shí)現(xiàn)方法

　　在Lucene中，其會(huì)操作兩個(gè)單獨(dú)的數(shù)據(jù)集：

• 文檔數(shù)據(jù)集中存儲(chǔ)了所有文檔，包括存儲(chǔ)的字段等。

• 索引數(shù)據(jù)集中存儲(chǔ)了所有字段/詞匯/詞頻/位置等信息，以及包含當(dāng)前字段的document

　　如果要實(shí)現(xiàn)將Lucene的后端移植到HBase上，直接構(gòu)建一個(gè)Directory的實(shí)現(xiàn)并不會(huì)是最簡(jiǎn)單的。在已有的開源項(xiàng)目中，Lucandra和HBasene均采用了直接重寫IndexReader和IndexWriter的方式，直接繞開了Directory的API。此實(shí)現(xiàn)并不會(huì)重寫Lucene的索引查詢機(jī)制。如若重載IndexSearcher，則可以在使用現(xiàn)有的Lucene索引查詢機(jī)制上，根據(jù)后端的功能增強(qiáng)性能。

[ 圖2 ] Lucene的后端重新設(shè)計(jì)

　　圖2的設(shè)計(jì)，可以將Lucene后端與HBase整合起來，將索引數(shù)據(jù)存儲(chǔ)到HBase中，從而利用HBase的大數(shù)據(jù)存儲(chǔ)以及分布式性能。

架構(gòu)設(shè)計(jì)

　　在架構(gòu)設(shè)計(jì)上，將HBase用作索引的持久化后端，同時(shí)可以如網(wǎng)上所說，基于內(nèi)存實(shí)現(xiàn)一套緩存機(jī)制，用來提高數(shù)據(jù)讀取速度。實(shí)現(xiàn)一套高效的緩存同步機(jī)制，也將有利于數(shù)據(jù)讀寫速率的提高。

[ 圖3 ] 帶有內(nèi)存緩存以及同步緩存的HBase后端實(shí)現(xiàn)

　　對(duì)于HBase的訪問，每一次交互都需要通過以太網(wǎng)，以太網(wǎng)的運(yùn)行狀態(tài)將大大影響系統(tǒng)的使用情況，而索引的建立又希望能達(dá)到實(shí)時(shí)且高響應(yīng)。為了平衡這兩種相互沖突的需求，在內(nèi)存中，緩存能夠最小化HBase用于搜索和文件返回的數(shù)據(jù)讀取量，從而極大提升性能；按照需要運(yùn)行為多個(gè)Lucene示例以支持日益增長(zhǎng)的搜索客戶端的能力。后者需要最小化緩存的生命周期，從而和HBase實(shí)例（上面提到實(shí)例的副本）中的內(nèi)容同步。通過為活動(dòng)參數(shù)實(shí)現(xiàn)可配置的緩存時(shí)間，限制每個(gè)Lucene實(shí)例中展現(xiàn)的緩存，我們可以達(dá)成一種折中方案。

　　根據(jù)上述所描述的結(jié)構(gòu)，對(duì)于讀操作，首先會(huì)檢查所需數(shù)據(jù)是否在內(nèi)存中且沒有過期，如果有效將直接使用，否者將從HBase中獲取數(shù)據(jù)并更新到內(nèi)存中。而對(duì)于寫操作，可以簡(jiǎn)化到直接將數(shù)據(jù)寫入到HBase中，進(jìn)而不需要考慮是否需要建立或更新緩存這種復(fù)雜的問題，這也將提高系統(tǒng)的實(shí)時(shí)響應(yīng)性。

HBase Table的實(shí)現(xiàn)

當(dāng)前了解到的兩種可參考的實(shí)現(xiàn)方式：HBasene類型、Lucandra類型。

1-- HBasene

其索引表由以下幾個(gè)column family組成：

• fm.sequence：記錄sequenceId，表示當(dāng)前添加的第幾個(gè)document。在執(zhí)行createLuceneIndexTable時(shí)創(chuàng)建該行，且rowKey為segmentId，Column.qulifier為qual.sequence，Column.value=-1。每add一個(gè)document，當(dāng)前segmentId的Column.value將自增1。

• fm.doc2int：每個(gè)document的存儲(chǔ)都將被分配一個(gè)唯一的id，如果document的Field.Store=YES，則能夠通過該id獲取到對(duì)應(yīng)的document的全部信息。

• fm.fields：記錄了Field中value的內(nèi)容，rowKey為documentId，Column.qulifier為FieldName，Column.value為FieldValue的內(nèi)容。

• fm.termVector：向量偏移數(shù)據(jù)，用于模糊查找，記錄了偏移量等信息，rowKey為FileldName/Term的組合，Column.qulifier為documentId，Column.value為指向的document中的所有位置偏移量。Column.value的結(jié)構(gòu)為：[A][size][position]……[position]

• fm.termFrequencies：關(guān)鍵詞在每個(gè)document中出現(xiàn)的頻率，rowKey結(jié)構(gòu)為zfm/FileName/Term，Column.qulifier為documentId，Column.value為出現(xiàn)的次數(shù)。

2-- Lucandra

在Lucendra中，只有兩個(gè)ColummFamily來存儲(chǔ)數(shù)據(jù)，分別是TermInfo和Documents

<Keyspace Name="Lucandra"> 
    <ColumnFamily   Name="TermInfo" CompareWith="BytesType" ColumnType="Super"  CompareSubcolumnsWith="BytesType"  KeysCached="10%" /> 
    <ColumnFamily Name="Documents" CompareWith="BytesType" KeysCached="10%" /> 
</Keyspace>

• TermInfo

        TermInfo存儲(chǔ)了Lucandra逆向索引的信息，用來存儲(chǔ)index的Field信息，其結(jié)構(gòu)如下：

        RowKey：field/term

        SuperColumn.name：documentId

        [ SubColumn.name："frequencies"  Column.value：count ]

        [ SubColumn.name："position"  Column.value：position vector ]

        [ SubColumn.name："offsets"  Column.value：offsets vector ]

        [ SubColumn.name："norms"  Column.value：norms vector ]

由于HBase中不存在SuperColumn和SubColumn的概念，我們可以將其簡(jiǎn)化為：

        RowKey：field/term

        Column.qulifier：documentId

        Column.value：fieldInfo [ 此fieldInfo可以通過AVRO類定義 ]

• Documents

        Documents存儲(chǔ)了Document數(shù)據(jù)，其結(jié)構(gòu)如下：

        RowKey：documentId

        Column.name：fieldName

        Column.value：fieldValue

對(duì)比：

        由HBasene的表結(jié)構(gòu)可以知道，對(duì)于每一個(gè)document的更新以及每一次term的查詢，都需要操縱多行數(shù)據(jù)才能實(shí)現(xiàn)，邏輯上相對(duì)復(fù)雜；而Lucandra只需要處理兩行（documents及TermInfo各一行）。但是HBasene的優(yōu)勢(shì)在于單行的存儲(chǔ)結(jié)構(gòu)小，每次與HBase交互只需要傳輸少量的數(shù)據(jù)及可，并且不像Lucandra結(jié)構(gòu)一樣需要而外的AVRO組件來序列化與反序列化數(shù)據(jù)。

HBasene的缺陷：

        1、HBasene在三年前已經(jīng)停止了其項(xiàng)目的更新，開源的支持?jǐn)嚅_了。

        2、在對(duì)HBasene的最新源碼分析過程中，首先是發(fā)現(xiàn)其設(shè)計(jì)上保留著segment的概念，但是其設(shè)計(jì)阻礙著document的查詢。其documentId由segmentId/sequenceId組成，每次segment的commit，sequenceId恢復(fù)為-1。而search時(shí)返回的TopDocs中只包含了sequenceId[int]。

        3、每次添加document時(shí)，只有fm.Fields以及fm.doc2int的數(shù)據(jù)被實(shí)時(shí)flush到了HBase中，而其他數(shù)據(jù)需要segment大小到了一定程度[默認(rèn)1000條document]才commit，容易造成數(shù)據(jù)缺失。在segment沒被commit的情況下，是無法查詢到新添加的document的。

        4、HBase Table的設(shè)計(jì)中，沒有考慮到當(dāng)document中fieldName相同的情況。當(dāng)fieldName相同的情況下，后面添加的會(huì)覆蓋前面添加數(shù)據(jù)的，最后只保留最后添加的一份。

        5、fm.termVector中，Column.value保存的并不是positionVector信息，而是segment中所有document里出現(xiàn)的次數(shù)。

        6、fm.termFrequencies只是單純地存儲(chǔ)了，并沒有被應(yīng)用上。

        7、IndexWriter的重寫并沒有實(shí)現(xiàn)所有函數(shù)，只實(shí)現(xiàn)了最基本的addDocument

        8、對(duì)IndexSearch的重寫和擴(kuò)展也不夠。

關(guān)于Lucene與HBase的組合使用及HBasene的報(bào)告分析問題的解答就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關(guān)注億速云行業(yè)資訊頻道了解更多相關(guān)知識(shí)。