王占宏,王戰(zhàn)英,顧國強,馬國春,呂振華
互聯(lián)網(wǎng)的快速發(fā)展,已逐漸在人們的工作、生活中,扮演著不可或缺的角色。人們通過互聯(lián)網(wǎng),最基本的目的就是獲取自己感興趣、滿足需求的信息。搜索引擎技術為人們從浩如煙海的信息中準確獲取想要的信息提供了可能,它經(jīng)歷了十多年的發(fā)展,極大的改變了人們獲取信息的方式。
例如在傳統(tǒng)的電子政務領域,對信息的檢索,已經(jīng)不再滿足普遍針對特定字段的精確或模糊檢索,在形式上采用類似Google、baidu的一框式全文檢索,其技術路線一般是采用基于大字段BLOB的全文檢索技術,如ORACLE 全文檢索引擎[1,2]。隨著數(shù)據(jù)量和訪問量的增大,該方式就經(jīng)常出現(xiàn)檢索速度慢、宕機等問題。而且其功能、檢索精度、信息資源覆蓋面、可維護性等方面也與專業(yè)的搜索引擎無法相比,這些問題往往制約著搜索結果的有效性和可用性。
采用搜索引擎是解決這一問題的比較合適的方法,但目前領先的搜索技術大都掌握在大公司的手中,如 Google、百度等,很難被用于普通的項目中。而一些開源的搜索引擎軟件,如 Lucene,其自身良好的跨平臺、搜索強大和簡單易用等特點,吸引了眾多的用戶群體。但 lucene在分布式存儲管理、集群搜索管理等方面存在不足。
由于用戶對信息資源的需求越來越大,對速度、準確度、可擴展性的要求也是越來越高,這無疑對目前傳統(tǒng)的集中式搜索引擎提出了巨大的挑戰(zhàn),應用云計算技術的分布式搜索引擎技術,自從進入人們視線之后,就得到了廣泛關注,基于云計算的分布式搜索引擎構建也已成為搜索引擎的熱點研究問題之一[3]。
基于云計算的分布式搜索引擎就是要讓搜索的資源廣泛分布在云端,并且由云為客戶提供搜索計算能力,有效的解決了資源與效率的問題,不僅提高了數(shù)據(jù)資源的安全性,也大幅提升了用戶的檢索效率。因此,基于云計算的搜索引擎研究有很大的實用性價值。
ElasticSearch(簡稱ES)是一個基于Lucene構建的開源,分布式搜索引擎,支持云計算框架。本文對ES進行了研究,并成功運用于公安信息資源整合與搜索的項目中,取得了良好的應用效果。
Lucene[4-8]是Apache軟件基金會jakarta項目組的一個子項目,它結構完整、層次分明、可擴展性好,且給開發(fā)人員在應用中實現(xiàn)全文檢索功能提供了完善的API文檔。
Lucene采用面向對象方法對系統(tǒng)的核心內容進行了抽象和封裝,形成了具體的類或接口。形成了一個與平臺無關、低耦合、高效率、易二次開發(fā)的全文檢索引擎構架。它技術上采用高度優(yōu)化的倒排索引結構,大大的提高了檢索效率。Lucene系統(tǒng)結構圖如圖1所示:
圖1 基于Lucene全文檢索系統(tǒng)結構圖
Lucene源碼中共包括 7個子包,每個包完成特定的功能[9],具體如表1所示:
表1 Lucene源碼包對應功能表
Lucene是集中式、單節(jié)點的框架體系,當索引文件越來越多時,其所需建立索引的時間會成倍、甚至幾何級增長,而且當索引文件達到一定數(shù)量時,搜索引擎也會遇到性能瓶頸。
所以要解決這一問題,就必須將集中式框架升級為分布式、多節(jié)點框架。
彈性搜索[10](Elastic Search簡稱:ES),是一個基于Lucene構建的分布式搜索引擎,能夠達到實時、穩(wěn)定、可靠的效果。
它由彈性網(wǎng)絡[11]演化而來的搜索方法,繼承了彈性網(wǎng)絡的思想。首先,從任意1個節(jié)點出發(fā),將其與離該節(jié)點最近的兩個節(jié)點連成一個環(huán),這個環(huán)像是一個正在逐漸被吹大氣球,由于氣球的彈力,則氣球先遇到離這個氣球上所有節(jié)點較近的節(jié)點,也就是所有未訪問節(jié)點中先訪問所需要距離最短的節(jié)點,直至所有節(jié)點均被搜索到。彈性搜索避免了彈性網(wǎng)絡的訓練過程,直接搜索訪問路徑最短的節(jié)點,加快了求解速度,時間復雜度也比較低。
ES支持分布式集群,集群中有多個節(jié)點。內部來看有一個主節(jié)點,可以通過選舉產(chǎn)生的。從外部看ES集群,無中心節(jié)點,在邏輯上是個整體,與任何一個節(jié)點的通信和與整個ES集群通信是等價的。
ES技術包括了索引存儲方式、分布式文件操作、搜索功能、節(jié)點發(fā)現(xiàn)、節(jié)點交互、外部接口等。分布式彈性搜索技術框架圖如圖2所示:
圖2 ES技術框架圖
(1)Gateway
Gateway是ES索引快照的存儲方式,它默認是先把索引存放到內存中,當內存不足時,再持久化到本地硬盤或存儲設備。當整個應用集群關閉再重新啟時,ES就會從gateway中讀取索引備份數(shù)據(jù)。目前ES支持本地文件系統(tǒng)、分布式文件系統(tǒng)、Hadoop的HDFS和amazon的s3云存儲服務。
(2)Distributed Lucene Directory
Directory是Lucene對文件操作的類,包括管理鎖工廠及其鎖實例、管理 Directory目錄實例的基本屬性、管理與操作該目錄相關流對象、索引文件的拷貝等。在ES中進行了分布式處理,可以支持集群中所有機器對文件的分布式操作。
(3)功能層
功能層包括Index Module、Search Module、Mapping、River。Index Module是索引管理模塊,包括索引的創(chuàng)建、添加、修改、刪除等;Search Module是檢索管理模塊,根據(jù)檢索條件,返回檢索結果;Mapping是對索引庫中索引的字段名及其數(shù)據(jù)類型進行定義,類似于關系數(shù)據(jù)庫中建表時定義字段名及其數(shù)據(jù)類型,不過ES的mapping比數(shù)據(jù)庫靈活很多,它可以動態(tài)添加字段,一般ES會自動根據(jù)數(shù)據(jù)格式定義它的類型,如果需要對某些字段添加特殊屬性(如:定義使用其它分詞器、是否分詞、是否存儲等),就必須手動添加mapping;River是ES的一個數(shù)據(jù)源,也是常用存儲方式(如:數(shù)據(jù)庫)同步數(shù)據(jù)到ES的一個方法,采用插件式服務,讀取river中的數(shù)據(jù)并把它索引到ES中。
(4)Discovery
Discovery是 ES的節(jié)點發(fā)現(xiàn)機制,他包括了兩種 Zen與EC2。Zen是ES的自動發(fā)現(xiàn)節(jié)點機制,ES是一個基于P2P的系統(tǒng),它先通過廣播尋找存在的節(jié)點,再通過多播協(xié)議來進行節(jié)點之間的通信,同時也支持點對點的交互;EC2是Amazon云平臺,ES也支持在此平臺中開發(fā)。
(5)Scripting
Scripting是書寫腳本,可以通過編寫自定義的腳本來增強擴充ES的功能,ES支持Mvel、js、python等多種腳本語言。
(6)Transport
Transport是ES內部節(jié)點或集群與客戶端的交互方式,支持Thrift、Memcached、Http等協(xié)議,他們都通過插件方式集成。
(7)RESTFul Style API、Java(Netty)
RESTFul Style API是具有RESTFul風格的接口,即符合REST的一組框架約束條件和原則。ES可以僅通過一組URL來操作其所有功能,便于各平臺各語句環(huán)境的使用,提供其通用性。另外ES也提供了原生的JAVA API,通過java NIO框架Netty來實現(xiàn),使熟悉java語言的開發(fā)者更容易使用。
(8)監(jiān)控(JMX)
ES可通過標準的JMX接口監(jiān)測集群中各節(jié)點服務器的運行狀態(tài)信息,以便對集群進行實時的監(jiān)控。ES所監(jiān)測的信息既包括節(jié)點級,也包括索引級、分片級。
(9)擴展
ES通過插件機制來擴展其基本功能,開發(fā)人員可以根據(jù)用戶的需求開發(fā)不同的插件實現(xiàn)特定功能。ES支持范圍很廣的插件,包括數(shù)據(jù)類型映射、分詞器、功能腳本、自動發(fā)現(xiàn)機制、數(shù)據(jù)抽取、對外接口等等。
公安內部大大小小存在200多套信息系統(tǒng),它們在不同的管理和實戰(zhàn)領域發(fā)揮著各自的作用,對于情報和一線打擊破案部門,這些信息資源都是很有價值的信息,隨時都需要查詢檢索。如果登陸不同的信息系統(tǒng)進行查詢檢索,效率可想而知。為了方便查詢,公安科技通信部門都逐步建立了公安綜合查詢系統(tǒng),即把各系統(tǒng)主要的信息資源整合到一個數(shù)據(jù)庫中,然后再分門別類的進行查詢。
隨著Google、Baidu的全文檢索模式逐步被人們所認可,用戶就希望不具體選擇信息模塊、不具體指定查詢字段就快速的搜索自己所需要的信息,這也沖擊著現(xiàn)有的公安綜合查詢系統(tǒng),綜合查詢系統(tǒng)也經(jīng)過優(yōu)化,在ORACLE數(shù)據(jù)庫匯總把部分核心字段合并成一個大的文本字段,作為大字段存放在Oracle中,在利用Oracle 的全文檢索功能針對這些核心字段進行全文檢索,解決了目前小數(shù)量的信息檢索,但該放手檢索內容上擴展具有局限性,同時隨著數(shù)量的增加,效率就越來越低,對集中式部署的硬件環(huán)境又提出了很高的要求,所以很難滿足人們日益增長的搜索體驗要求和信息資源迅猛的增長要求。
針對以上問題,我們基于ES開發(fā)了公安信息資源整合與全文檢索平臺,較好地解決了該問題。
我們配置10臺刀片機作為一個集群,每臺機器安裝了64位的Linux操作系統(tǒng),Intel Xeon E58核2400Hz CPU、內存為16GB,自帶200GB硬盤。
安裝JAVA虛擬機以及ElasticSearch 0.90.7,安裝后系統(tǒng)會自動發(fā)現(xiàn)可用的機器節(jié)點,參與計算、存儲。
公安信息資源量非常大,格式多樣,有存儲在 Oracle中的格式化數(shù)據(jù),也有文本文件、網(wǎng)頁以及PDF格式的非格式化數(shù)據(jù)。下面以某市實有人口的數(shù)據(jù)抽取與索引構建為例,介紹基于ES的數(shù)據(jù)處理與索引構建過程。
(1)分片、副本設置
根據(jù)所用機器配置,反復實驗測算,每個節(jié)點分配 4個分片,每個分片存儲20GB的數(shù)據(jù)時性能最佳,我們的實驗數(shù)據(jù)大致為300GB包含10億條記錄,考慮到分片太多會增加分布式計算時的分解與聚合成本,影響性能,因此我們把分片數(shù)設置為 10,為了數(shù)據(jù)存儲的安全考慮,副本數(shù)設置為2,即每份數(shù)據(jù)存儲在3個節(jié)點上。
(2)創(chuàng)建river及索引數(shù)據(jù)
由于實有人口數(shù)據(jù)存儲在 Oracle數(shù)據(jù)庫中,因此我們采用JDBC.river插件實現(xiàn)數(shù)據(jù)抽取并對數(shù)據(jù)進行索引,采用java api方式。
主要代碼如下:
(3)同步監(jiān)控
數(shù)據(jù)同步的監(jiān)測主要包括集群的運行狀況、各節(jié)點機器的運行狀況和磁盤的讀寫情況等。
集群的運行狀況是通過顏色直觀的表達當前集群的“健康”情況,綠色表明集群很“健康”,一切運轉正常;黃色表明集群處于“亞健康”狀態(tài),即目前的集群狀況不能滿足所設置的集群策略要求,例如一個數(shù)據(jù)切片設置了3個副本,而目前集群中只有兩臺正常運轉的機器;橙色表明集群已經(jīng)被破壞,不能正常運轉。
各節(jié)點機器的運行狀況通過列表形式顯示當前正常運作的機器,以及每臺機器上數(shù)據(jù)切片、切片副本。如果某臺機器故障,則立即會從列表內被剔除。
磁盤的讀寫監(jiān)測重點監(jiān)測集群中磁盤的讀寫次數(shù)變化以及磁盤的讀寫數(shù)據(jù)量變化。
在數(shù)據(jù)索引構建完成后,需要根據(jù)應用需求設計系統(tǒng)搜索界面,并通過各種調用方式在集群中分布式執(zhí)行搜索引擎,并根據(jù)系統(tǒng)設計風格將反饋數(shù)據(jù)嵌入顯示界面。
在本項目中我們采用了Java api方式,并通過性能監(jiān)控接口可視化了性能參數(shù)。
(1)搜索調用代碼
以下是使用java api執(zhí)行搜索功能的代碼片段。
(2)性能監(jiān)控
搜索性能監(jiān)控中,我們重點對內存使用情況、CPU使用情況,查詢效率等進行了可視化監(jiān)測。
內存檢測包括常駐內存和共享內存的實時使用情況;CPU檢測則實時顯示了系統(tǒng)的CPU使用率;查詢效率檢測一方面實時監(jiān)測每秒鐘平均索引請求數(shù)量,另一方面檢測每秒每個搜索的平均耗時情況。
本文針對大數(shù)據(jù)量、信息資源全文檢索的集中式架構和效率慢問題,通過對ES的深入研究,針對公安信息資源整合和快速查詢需求,基于ES開發(fā)了分布式的信息整合與搜索信息系統(tǒng),利用廉價硬件設備資源構建了高效的信息資源整合與搜索平臺,滿足了公安情報與一線實戰(zhàn)部門對信息資源簡潔、高效的搜索需要。
目前該系統(tǒng)在增量信息快速同步、智能搜索、自動快速提取有價值信息方面還需要進一步的研究與探索,逐步適應新的挑戰(zhàn)。
[1]李瑞麗,錢皓,黃以凱.基于Oracle大數(shù)據(jù)的全文檢索技術研究與實現(xiàn).微型電腦應用[J].2013,29(1):18-21.
[2]陳天偉.基于Oracle Text電子政務全文檢索技術的應用.辦公自動化(綜合版)[J].2007(1):11-13.
[3]楊光偉.基于Lucene的個性化搜索引擎的研究與實現(xiàn)[D],呼和浩特:內蒙古大學,2009.
[4]張淳晟,鄭麗英.基于XML的搜索引擎倒排索引研究[J].太原科技,2009(1):64—66.
[5]Liu chun, Guo Qingping.Analysis and Research of Web Chinese Retrieval system Based Lunece[J].Computer society, 2009(12): 105l-1055.
[6]Zhang Yong, Li Jianlin.Research and Improvement of Search Engine Based on lucene [c].International Conference on Intelligent Human-Machine Systems and Cybemetics.Zhe jiang:[s.n.], 2009:270-273.
[7]Zhou Ning, Wu JiaXin, Zhang ShaoLong, et .Mining Weighted Association Rules with Lucene Index[J].Wireless Communications, Networking and Mobile Computing, 2007 (9):3697—3700.
[8]Kim Min—Soo, Whang Kyu-Young, Lee Jae-Gil, et.n-Gram/2L:A Space and Time Efficient Two-Level n-Gram Inverted Index structure[c]∥Proceedings of the 3lst international conference on very large data bases.Trondheim, Norway: [s.n.], 2005: 325-336.
[9]Gospodnetic O, Hatcher E.Lucene in action[M].[s.l.]:Manning Publications Co, 2005.
[10]http://www.elasticsearch.org/
[11]Durbin R, Willshaw D.An Analogue Approach to the Traveling Salesman Problem Using an Elastic Net method.[J]Nature, 1987, 326:689—691.