基于Solr的海量日志信息查詢性能優(yōu)化的研究

馮祥+邱志超

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

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

中圖分類號：TP393 文獻標識碼：A 文章編號：1671-7597（2014）03-0037-03

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

1 概述

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

1.1 問題描述

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

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

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

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

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

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

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

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

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

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

1）集中式的配置信息。

2）自動容錯。

3）近實時搜索。

4）查詢時自動負載均衡.

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

2 方案設(shè)計

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

2.1 索引優(yōu)化

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

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

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

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

2.3 減少磁盤掃描

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

2.4 分布式建立索引

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

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

圖4 分頁過程

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

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

圖5 分片策略

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

3 寫入、讀取性能效果分析

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

3.1 實驗環(huán)境

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

表1 測試環(huán)境

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

Oracle RedHat Linux

5.4 64Bit CPU：32C

MEM：32G 2臺

Solr服務(wù)器 RedHat Linux

5.4 64Bit CPU：32C

MEM：32G 1臺

3.2 索引寫入性能

表2 索引寫入性能

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

大小 時間

（小時） 每秒

條數(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ù)查詢性能

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

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

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é)點部署之后，對schema做了優(yōu)化（將不需要顯示的字段設(shè)置為不存儲索引），所以通過上述兩種寫入模式分析我們可以看出，索引量降低很多，但是5節(jié)點索引速度慢了很多，而且隨著索引量的增加，索引隨之降低。

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

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

4 總結(jié)

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

參考文獻

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

[2]solr中國微博. 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臺

Solr服務(wù)器 RedHat Linux

5.4 64Bit CPU：32C

MEM：32G 1臺

3.2 索引寫入性能

表2 索引寫入性能

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

大小 時間

（小時） 每秒

條數(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ù)查詢性能

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

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

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é)點部署之后，對schema做了優(yōu)化（將不需要顯示的字段設(shè)置為不存儲索引），所以通過上述兩種寫入模式分析我們可以看出，索引量降低很多，但是5節(jié)點索引速度慢了很多，而且隨著索引量的增加，索引隨之降低。

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

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

4 總結(jié)

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

參考文獻

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

[2]solr中國微博. 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臺

Solr服務(wù)器 RedHat Linux

5.4 64Bit CPU：32C

MEM：32G 1臺

3.2 索引寫入性能

表2 索引寫入性能

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

大小 時間

（小時） 每秒

條數(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ù)查詢性能

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

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

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é)點部署之后，對schema做了優(yōu)化（將不需要顯示的字段設(shè)置為不存儲索引），所以通過上述兩種寫入模式分析我們可以看出，索引量降低很多，但是5節(jié)點索引速度慢了很多，而且隨著索引量的增加，索引隨之降低。

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

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

4 總結(jié)

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

參考文獻

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

[2]solr中國微博. www.solr.cc.

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