馮祥+邱志超

摘 要 ApacheSolr是一個(gè)基于A(yíng)pacheLucene的開(kāi)源企業(yè)搜索服務(wù)器。Apache SolrCloud是基于Solr和Zookeeper的分布式搜索方案，它的主要思想是使用Zookeeper作為集群的配置信息中心。文章在海量日志索引信息存儲(chǔ)和查詢(xún)方面進(jìn)行了探索，證明了在相關(guān)優(yōu)化策略下Solr Cloud具備了優(yōu)秀的查詢(xún)性能。

關(guān)鍵詞 Solr；SolrCloud；日志信息查詢(xún)；大數(shù)據(jù)；性能優(yōu)化；集群；分片

中圖分類(lèi)號(hào)：TP393 文獻(xiàn)標(biāo)識(shí)碼：A 文章編號(hào)：1671-7597（2014）03-0037-03

隨著傳統(tǒng)互聯(lián)網(wǎng)和移動(dòng)互聯(lián)網(wǎng)的持續(xù)發(fā)展，網(wǎng)絡(luò)帶給我們的是不斷增長(zhǎng)的各種不同價(jià)值信息，然而如何在信息海洋中快速檢索到有價(jià)值信息，對(duì)于我們來(lái)講至關(guān)重要。目前一些搜索公司在公共互聯(lián)網(wǎng)領(lǐng)域提供了很好的解決方案，但是企業(yè)或者政府機(jī)關(guān)內(nèi)部相關(guān)信息往往需要應(yīng)用獨(dú)立的搜索系統(tǒng)，Solr Cloud則是很好的一個(gè)平臺(tái)選擇。

1 概述

隨著企業(yè)和政府信息化建設(shè)的持續(xù)推進(jìn)，相關(guān)系統(tǒng)平臺(tái)會(huì)產(chǎn)生海量的日志數(shù)據(jù)，而這些日志數(shù)據(jù)的整合分析對(duì)于企業(yè)和政府相關(guān)單位具有非常重要的價(jià)值，既有關(guān)系型數(shù)據(jù)庫(kù)能夠存儲(chǔ)如此海量的大數(shù)據(jù)，然而對(duì)于分析如此海量的大數(shù)據(jù)進(jìn)而提供準(zhǔn)確的信息查詢(xún)服務(wù)則顯得力不從心。

1.1 問(wèn)題描述

筆者所在從事項(xiàng)目環(huán)境對(duì)于海量的日志分析具有以下要求。

1）日志信息數(shù)據(jù)增量龐大。每天會(huì)有500萬(wàn)條記錄的日志增量，總量有15億條記錄，索引物理存儲(chǔ)總量1.5T的存儲(chǔ)。

2）數(shù)據(jù)索引需要保留4年并且會(huì)動(dòng)態(tài)添加新表的配置，并且維護(hù)索引和搜索會(huì)同步進(jìn)行。

3）需要根據(jù)關(guān)鍵字搜索，將相關(guān)表的搜索結(jié)果總數(shù)返回，并且返回其中一個(gè)表的前10條數(shù)據(jù)，要求召回率為100%，可以時(shí)間排序。

4）源日志數(shù)據(jù)表眾多且結(jié)構(gòu)不統(tǒng)一。

5）維護(hù)索引結(jié)構(gòu)時(shí)同時(shí)會(huì)產(chǎn)生實(shí)時(shí)日志數(shù)據(jù)（約平均每小時(shí)20萬(wàn)條記錄），需保證新日志數(shù)據(jù)索引同步延遲不得超過(guò)1小時(shí)。

6）80%請(qǐng)求2 s內(nèi)響應(yīng)。物理服務(wù)器資源有限，控制在3臺(tái)左右。

基于以上特定需求，我們提出基于SolrCloud的日志信息查詢(xún)性能優(yōu)化方案。

1.2 相關(guān)技術(shù)

SolrCloud是基于Solr和Zookeeper的分布式搜索方案，它的主要思想是使用Zookeeper作為集群的配置信息中心。它有如下幾個(gè)特色功能。

1）集中式的配置信息。

2）自動(dòng)容錯(cuò)。

3）近實(shí)時(shí)搜索。

4）查詢(xún)時(shí)自動(dòng)負(fù)載均衡.

下面將詳細(xì)描述應(yīng)用SolrCloud來(lái)管理維護(hù)海量日志數(shù)據(jù)查詢(xún)的方案，并給出相關(guān)優(yōu)化策略來(lái)滿(mǎn)足section 1.1所描述特定需求問(wèn)題。

2 方案設(shè)計(jì)

從總體框架（圖1）我們可以看出，具體優(yōu)化策略包括：索引優(yōu)化、檢索應(yīng)用緩存優(yōu)化、存儲(chǔ)優(yōu)化、分布式優(yōu)化等方面。方案中我們依據(jù)Solr實(shí)際測(cè)試結(jié)果將Solr單機(jī)節(jié)點(diǎn)數(shù)控制在3-5個(gè)，每節(jié)點(diǎn)索引量控制在3億條左右。

2.1 索引優(yōu)化

Solr自帶的全切詞只能講中文全切，英文和數(shù)字不能切，我們改造了分詞算法。全切分可以很好解決拉鏈問(wèn)題，也滿(mǎn)足全召回，但如果字段長(zhǎng)度過(guò)大可能會(huì)導(dǎo)致性能下降，我們將部分只做精確查詢(xún)的字段，制定為string類(lèi)型（不切詞），在索引和查詢(xún)時(shí)提高效率。

盡量減少配置的數(shù)據(jù)庫(kù)字段，僅索引必要的數(shù)據(jù)庫(kù)字段，減少索引量，同時(shí)很多字段是需要檢索，但不需要顯示，將這些設(shè)置為不存儲(chǔ)。

2.2 檢索應(yīng)用緩存優(yōu)化

為了更好的提供檢索性能，我們將繼承分布式緩存。借助Solr的SolrCacheBase集成了BerkeleyDB。由于BerkeleyDB具有以下特性：高速K-V系統(tǒng)，具備持久化功能，擁有一層可配置的內(nèi)存cache順序讀寫(xiě)。我們極大的縮短了查詢(xún)的響應(yīng)時(shí)間。

2.3 減少磁盤(pán)掃描

Solr是通過(guò)唯一主鍵的，每次檢索都要讀取正排索引，可以在每個(gè)段前添加BloomFilter。Solr要求讀取ID，有些記錄不分詞，倒排索引和目標(biāo)正文是一樣的，只讀取倒排索引，減少磁盤(pán)掃描，這樣通過(guò)優(yōu)化存儲(chǔ)來(lái)提高查詢(xún)效率。

2.4 分布式建立索引

Solr Cloud支持直接指定shard（分片），跳過(guò)node和collection的分流過(guò)程，提高索引入庫(kù)速度。我們根據(jù)日志時(shí)間來(lái)做shard指定。

2.5 優(yōu)化分頁(yè)過(guò)程

圖4 分頁(yè)過(guò)程

SolrCloud的分頁(yè)查詢(xún)是主節(jié)點(diǎn)將關(guān)鍵字傳給各個(gè)shard，各個(gè)shard將id和分?jǐn)?shù)傳給主節(jié)點(diǎn)，主節(jié)點(diǎn)再排序后，再通過(guò)id到各個(gè)shard中取數(shù)據(jù)。這個(gè)過(guò)程我們可以通過(guò)在圖4中1.1.2的步驟中直接返回?cái)?shù)據(jù)，避免進(jìn)行后續(xù)步驟，提高分頁(yè)查詢(xún)效率。

2.6 根據(jù)業(yè)務(wù)分片

圖5 分片策略

我們前面通過(guò)時(shí)間做shard分片，查詢(xún)過(guò)程中可以通過(guò)時(shí)間范圍來(lái)確定哪些shard分片，通過(guò)指定shard分片，來(lái)縮小查詢(xún)數(shù)據(jù)范圍，提高查詢(xún)效率。

3 寫(xiě)入、讀取性能效果分析

SolrCloud的數(shù)據(jù)寫(xiě)入性能測(cè)試主要包含以下幾個(gè)場(chǎng)景模式，包含單機(jī)3節(jié)點(diǎn)虛擬集群與單機(jī)5節(jié)點(diǎn)虛擬集群的性能比較。理論上節(jié)點(diǎn)越多，性能會(huì)越高，我們做3節(jié)點(diǎn)和5節(jié)點(diǎn)的測(cè)試。

3.1 實(shí)驗(yàn)環(huán)境

實(shí)測(cè)環(huán)境的數(shù)據(jù)庫(kù)版本為：Solr：4.5，Oracle：10g。

表1 測(cè)試環(huán)境

服務(wù)器 操作系統(tǒng) 硬件環(huán)境 數(shù)量endprint

Oracle RedHat Linux

5.4 64Bit CPU：32C

MEM：32G 2臺(tái)

Solr服務(wù)器 RedHat Linux

5.4 64Bit CPU：32C

MEM：32G 1臺(tái)

3.2 索引寫(xiě)入性能

表2 索引寫(xiě)入性能

虛擬節(jié)點(diǎn)數(shù) 數(shù)據(jù)量 索引

大小 時(shí)間

（小時(shí)） 每秒

條數(shù) Cpu/內(nèi)存

3分片集群 1億 58G 9h 3471 12%/9.6G

5分片集群 1億 40G 10h 2300 38%/11G

3分片集群 2億 120G 17h 3508 18%/15G

5分片集群 2億 83G 22h 1167 35%/12.5G

3分片集群 3億 171G 24h 3525 13%/15G

5分片集群 3億 135G 44h 1800 48%/18G

3.3 數(shù)據(jù)查詢(xún)性能

表3 數(shù)據(jù)查詢(xún)性能

虛擬節(jié)點(diǎn)數(shù) 關(guān)鍵字 數(shù)據(jù)量 時(shí)間（毫秒）

3分片集群 *：* 3億 1400

3分片集群 all_fields：*1986* 3億 230082

3分片集群 all_fields：1987* 3億 9870

3分片集群 all_fields：19880101 3億 4522

3分片集群 all_fields："19890101" 3億 153845

3分片集群 all_fields：（"1990" AND "1991"） 3億 250349

5分片集群 *：* 3億 1344

5分片集群 all_fields：*1986* 3億 190875

5分片集群 all_fields：1987* 3億 7703

5分片集群 all_fields：19880101 3億 3734

5分片集群 all_fields："19890101" 3億 118437

5分片集群 all_fields：（"1990" AND "1991"） 3億 218172

3.4 效果分析

由于做了5節(jié)點(diǎn)部署之后，對(duì)schema做了優(yōu)化（將不需要顯示的字段設(shè)置為不存儲(chǔ)索引），所以通過(guò)上述兩種寫(xiě)入模式分析我們可以看出，索引量降低很多，但是5節(jié)點(diǎn)索引速度慢了很多，而且隨著索引量的增加，索引隨之降低。

查詢(xún)效率方面，在3億級(jí)數(shù)據(jù)全量搜索情況下，節(jié)點(diǎn)數(shù)3或者5差別不是很大，但是查詢(xún)語(yǔ)法的不同效率明顯不同。通過(guò)不同的關(guān)鍵字語(yǔ)法進(jìn)行查詢(xún)，全模糊的效率最低。

考慮到日志系統(tǒng)對(duì)索引實(shí)時(shí)性要求不高，查詢(xún)性能比索引性能要求更高，該硬件配置情況下，選擇5節(jié)點(diǎn)模式。

4 總結(jié)

本文針對(duì)海量日志系統(tǒng)的數(shù)據(jù)索引和查詢(xún)性能優(yōu)化進(jìn)行了探索，證明在海量日志數(shù)據(jù)環(huán)境下，應(yīng)用以SolrCloud分布式搜索引擎為基礎(chǔ)的查詢(xún)系統(tǒng)，在經(jīng)過(guò)特定優(yōu)化策略下，具有很好的查詢(xún)性能和有良好的擴(kuò)展性。該方案不僅適用于大數(shù)據(jù)場(chǎng)景下的日志數(shù)據(jù)分析，同時(shí)也適用于其他海量文本數(shù)據(jù)查詢(xún)檢索應(yīng)用，為我們?cè)诖髷?shù)據(jù)時(shí)代的信息查詢(xún)搜索業(yè)務(wù)奠定了技術(shù)基礎(chǔ)。

參考文獻(xiàn)

[1]solr wiki. http：//wiki.apache.org/solr/FrontPage.

[2]solr中國(guó)微博. www.solr.cc.

[3]Otis Gospodnetic， Erik Hatcher.Lucene in Action中文版[M].北京：電子工業(yè)出版社，2007.endprint

Oracle RedHat Linux

5.4 64Bit CPU：32C

MEM：32G 2臺(tái)

Solr服務(wù)器 RedHat Linux

5.4 64Bit CPU：32C

MEM：32G 1臺(tái)

3.2 索引寫(xiě)入性能

表2 索引寫(xiě)入性能

虛擬節(jié)點(diǎn)數(shù) 數(shù)據(jù)量 索引

大小 時(shí)間

（小時(shí)） 每秒

條數(shù) Cpu/內(nèi)存

3分片集群 1億 58G 9h 3471 12%/9.6G

5分片集群 1億 40G 10h 2300 38%/11G

3分片集群 2億 120G 17h 3508 18%/15G

5分片集群 2億 83G 22h 1167 35%/12.5G

3分片集群 3億 171G 24h 3525 13%/15G

5分片集群 3億 135G 44h 1800 48%/18G

3.3 數(shù)據(jù)查詢(xún)性能

表3 數(shù)據(jù)查詢(xún)性能

虛擬節(jié)點(diǎn)數(shù) 關(guān)鍵字 數(shù)據(jù)量 時(shí)間（毫秒）

3分片集群 *：* 3億 1400

3分片集群 all_fields：*1986* 3億 230082

3分片集群 all_fields：1987* 3億 9870

3分片集群 all_fields：19880101 3億 4522

3分片集群 all_fields："19890101" 3億 153845

3分片集群 all_fields：（"1990" AND "1991"） 3億 250349

5分片集群 *：* 3億 1344

5分片集群 all_fields：*1986* 3億 190875

5分片集群 all_fields：1987* 3億 7703

5分片集群 all_fields：19880101 3億 3734

5分片集群 all_fields："19890101" 3億 118437

5分片集群 all_fields：（"1990" AND "1991"） 3億 218172

3.4 效果分析

由于做了5節(jié)點(diǎn)部署之后，對(duì)schema做了優(yōu)化（將不需要顯示的字段設(shè)置為不存儲(chǔ)索引），所以通過(guò)上述兩種寫(xiě)入模式分析我們可以看出，索引量降低很多，但是5節(jié)點(diǎn)索引速度慢了很多，而且隨著索引量的增加，索引隨之降低。

查詢(xún)效率方面，在3億級(jí)數(shù)據(jù)全量搜索情況下，節(jié)點(diǎn)數(shù)3或者5差別不是很大，但是查詢(xún)語(yǔ)法的不同效率明顯不同。通過(guò)不同的關(guān)鍵字語(yǔ)法進(jìn)行查詢(xún)，全模糊的效率最低。

考慮到日志系統(tǒng)對(duì)索引實(shí)時(shí)性要求不高，查詢(xún)性能比索引性能要求更高，該硬件配置情況下，選擇5節(jié)點(diǎn)模式。

4 總結(jié)

本文針對(duì)海量日志系統(tǒng)的數(shù)據(jù)索引和查詢(xún)性能優(yōu)化進(jìn)行了探索，證明在海量日志數(shù)據(jù)環(huán)境下，應(yīng)用以SolrCloud分布式搜索引擎為基礎(chǔ)的查詢(xún)系統(tǒng)，在經(jīng)過(guò)特定優(yōu)化策略下，具有很好的查詢(xún)性能和有良好的擴(kuò)展性。該方案不僅適用于大數(shù)據(jù)場(chǎng)景下的日志數(shù)據(jù)分析，同時(shí)也適用于其他海量文本數(shù)據(jù)查詢(xún)檢索應(yīng)用，為我們?cè)诖髷?shù)據(jù)時(shí)代的信息查詢(xún)搜索業(yè)務(wù)奠定了技術(shù)基礎(chǔ)。

參考文獻(xiàn)

[1]solr wiki. http：//wiki.apache.org/solr/FrontPage.

[2]solr中國(guó)微博. www.solr.cc.

[3]Otis Gospodnetic， Erik Hatcher.Lucene in Action中文版[M].北京：電子工業(yè)出版社，2007.endprint

Oracle RedHat Linux

5.4 64Bit CPU：32C

MEM：32G 2臺(tái)

Solr服務(wù)器 RedHat Linux

5.4 64Bit CPU：32C

MEM：32G 1臺(tái)

3.2 索引寫(xiě)入性能

表2 索引寫(xiě)入性能

虛擬節(jié)點(diǎn)數(shù) 數(shù)據(jù)量 索引

大小 時(shí)間

（小時(shí)） 每秒

條數(shù) Cpu/內(nèi)存

3分片集群 1億 58G 9h 3471 12%/9.6G

5分片集群 1億 40G 10h 2300 38%/11G

3分片集群 2億 120G 17h 3508 18%/15G

5分片集群 2億 83G 22h 1167 35%/12.5G

3分片集群 3億 171G 24h 3525 13%/15G

5分片集群 3億 135G 44h 1800 48%/18G

3.3 數(shù)據(jù)查詢(xún)性能

表3 數(shù)據(jù)查詢(xún)性能

虛擬節(jié)點(diǎn)數(shù) 關(guān)鍵字 數(shù)據(jù)量 時(shí)間（毫秒）

3分片集群 *：* 3億 1400

3分片集群 all_fields：*1986* 3億 230082

3分片集群 all_fields：1987* 3億 9870

3分片集群 all_fields：19880101 3億 4522

3分片集群 all_fields："19890101" 3億 153845

3分片集群 all_fields：（"1990" AND "1991"） 3億 250349

5分片集群 *：* 3億 1344

5分片集群 all_fields：*1986* 3億 190875

5分片集群 all_fields：1987* 3億 7703

5分片集群 all_fields：19880101 3億 3734

5分片集群 all_fields："19890101" 3億 118437

5分片集群 all_fields：（"1990" AND "1991"） 3億 218172

3.4 效果分析

由于做了5節(jié)點(diǎn)部署之后，對(duì)schema做了優(yōu)化（將不需要顯示的字段設(shè)置為不存儲(chǔ)索引），所以通過(guò)上述兩種寫(xiě)入模式分析我們可以看出，索引量降低很多，但是5節(jié)點(diǎn)索引速度慢了很多，而且隨著索引量的增加，索引隨之降低。

查詢(xún)效率方面，在3億級(jí)數(shù)據(jù)全量搜索情況下，節(jié)點(diǎn)數(shù)3或者5差別不是很大，但是查詢(xún)語(yǔ)法的不同效率明顯不同。通過(guò)不同的關(guān)鍵字語(yǔ)法進(jìn)行查詢(xún)，全模糊的效率最低。

考慮到日志系統(tǒng)對(duì)索引實(shí)時(shí)性要求不高，查詢(xún)性能比索引性能要求更高，該硬件配置情況下，選擇5節(jié)點(diǎn)模式。

4 總結(jié)

本文針對(duì)海量日志系統(tǒng)的數(shù)據(jù)索引和查詢(xún)性能優(yōu)化進(jìn)行了探索，證明在海量日志數(shù)據(jù)環(huán)境下，應(yīng)用以SolrCloud分布式搜索引擎為基礎(chǔ)的查詢(xún)系統(tǒng)，在經(jīng)過(guò)特定優(yōu)化策略下，具有很好的查詢(xún)性能和有良好的擴(kuò)展性。該方案不僅適用于大數(shù)據(jù)場(chǎng)景下的日志數(shù)據(jù)分析，同時(shí)也適用于其他海量文本數(shù)據(jù)查詢(xún)檢索應(yīng)用，為我們?cè)诖髷?shù)據(jù)時(shí)代的信息查詢(xún)搜索業(yè)務(wù)奠定了技術(shù)基礎(chǔ)。

參考文獻(xiàn)

[1]solr wiki. http：//wiki.apache.org/solr/FrontPage.

[2]solr中國(guó)微博. www.solr.cc.

[3]Otis Gospodnetic， Erik Hatcher.Lucene in Action中文版[M].北京：電子工業(yè)出版社，2007.endprint