本發(fā)明實(shí)施例涉及海量數(shù)據(jù)搜索
技術(shù)領(lǐng)域：
：，尤其涉及一種基于Solr數(shù)據(jù)搜索的方法及裝置。
背景技術(shù)：
：：自2012起，大數(shù)據(jù)(BigData)一詞被越來(lái)越多的提及，人們用它來(lái)描述和定義信息爆炸時(shí)代產(chǎn)生的海量信息，并命名與之相關(guān)的技術(shù)發(fā)展與創(chuàng)新。2012年2月《紐約時(shí)報(bào)》一篇專欄稱，“大數(shù)據(jù)”時(shí)代已經(jīng)降臨，在商業(yè)、經(jīng)濟(jì)及其他領(lǐng)域中，決策將日益基于數(shù)據(jù)和分析而做出，而非基于經(jīng)驗(yàn)和直覺(jué)。大數(shù)據(jù)通常用來(lái)形容一個(gè)公司創(chuàng)造的大量非結(jié)構(gòu)化以及半結(jié)構(gòu)化數(shù)據(jù)，而這些數(shù)據(jù)在下載到關(guān)系型數(shù)據(jù)庫(kù)用于分析時(shí)會(huì)花費(fèi)過(guò)多時(shí)間和金錢。大數(shù)據(jù)分析常和云計(jì)算聯(lián)系到一起，因?yàn)閷?shí)時(shí)的大型數(shù)據(jù)集分析需要像Spark這樣的框架向數(shù)十、數(shù)百甚至數(shù)千的電腦分配工作。大數(shù)據(jù)到底有多大？一組名為“互聯(lián)網(wǎng)上一天”的數(shù)據(jù)告訴我們，一天之中，互聯(lián)網(wǎng)產(chǎn)生的全部?jī)?nèi)容可以刻滿1.68億張DVD；發(fā)出的郵件有2940億封之多(相當(dāng)于美國(guó)兩年的紙質(zhì)信件數(shù)量)；發(fā)出的社區(qū)帖子達(dá)200萬(wàn)個(gè)(相當(dāng)于《時(shí)代》雜志770年的文字量)；賣出的手機(jī)為37.8萬(wàn)臺(tái)，高于全球每天出生的嬰兒數(shù)量37.1萬(wàn)……截止到2012年，數(shù)據(jù)量已經(jīng)從TB(1024GB＝1TB)級(jí)別躍升到PB(1024TB＝1PB)、EB(1024PB＝1EB)乃至ZB(1024EB＝1ZB)級(jí)別。國(guó)際數(shù)據(jù)公司(IDC)的研究結(jié)果表明，2008年全球產(chǎn)生的數(shù)據(jù)量為0.49ZB，2009年的數(shù)據(jù)量為0.8ZB，2010年增長(zhǎng)為1.2ZB，2011年的數(shù)量更是高達(dá)1.82ZB，相當(dāng)于全球每人產(chǎn)生200GB以上的數(shù)據(jù)。而到2012年為止，人類生產(chǎn)的所有印刷材料的數(shù)據(jù)量是200PB，全人類歷史上說(shuō)過(guò)的所有話的數(shù)據(jù)量大約是5EB。IBM的研究稱，整個(gè)人類文明所獲得的全部數(shù)據(jù)中，有90％是過(guò)去兩年內(nèi)產(chǎn)生的。而到了2020年，全世界所產(chǎn)生的數(shù)據(jù)規(guī)模將達(dá)到今天的44倍。[5]每一天，全世界會(huì)上傳超過(guò)5億張圖片，每分鐘就有20小時(shí)時(shí)長(zhǎng)的視頻被分享。然而，即使是人們每天創(chuàng)造的全部信息——包括語(yǔ)音通話、電子郵件和信息在內(nèi)的各種通信，以及上傳的全部圖片、視頻與音樂(lè)，其信息量也無(wú)法匹及每一天所創(chuàng)造出的關(guān)于人們自身的數(shù)字信息量。大數(shù)據(jù)是如此重要，以至于其獲取、儲(chǔ)存、搜索、共享、分析，乃至可視化地呈現(xiàn)，都成為了當(dāng)前重要的研究課題。技術(shù)實(shí)現(xiàn)要素：本發(fā)明實(shí)施例的目的在于提出一種基于Solr數(shù)據(jù)搜索的方法及裝置，旨在解決大數(shù)據(jù)量存儲(chǔ)以及對(duì)海量數(shù)據(jù)的查詢優(yōu)化問(wèn)題。為達(dá)此目的，本發(fā)明實(shí)施例采用以下技術(shù)方案：第一方面，一種基于Solr數(shù)據(jù)搜索的方法，所述方法包括：選用HBase或是MongoDB的底層存儲(chǔ)數(shù)據(jù)庫(kù)，并根據(jù)記錄的字段生成rowkey；在內(nèi)存的優(yōu)化上對(duì)JVM進(jìn)行優(yōu)化，并對(duì)Solr的內(nèi)存配置、磁盤占用和事務(wù)日志進(jìn)行優(yōu)化；在查詢數(shù)據(jù)時(shí)，根據(jù)Solr創(chuàng)建后的索引從所述底層存儲(chǔ)中獲取對(duì)應(yīng)的數(shù)據(jù)。優(yōu)選地，所述在內(nèi)存的優(yōu)化上對(duì)JVM進(jìn)行優(yōu)化，包括：分配給所述Solr需要的內(nèi)存后再加上預(yù)設(shè)大小的緩存。優(yōu)選地，所述對(duì)Solr的內(nèi)存配置進(jìn)行優(yōu)化，包括：對(duì)所述Solr的緩存大小、回收策略的選取進(jìn)行配置；所述緩存包括自動(dòng)預(yù)熱緩存、過(guò)濾器緩存、文檔緩存、查詢結(jié)果緩存和/或域值緩存；所述回收策略的選取為：使用FieldCache，減少mergeFactor的使用，使索引中保存少的段，關(guān)閉使用索引的復(fù)合文件格式，并在創(chuàng)建索引時(shí)選用NIOFSDirectory使用NIO，直接使用直接內(nèi)存，選用合適的段合并策略避免生成小段。優(yōu)選地，所述對(duì)Solr的磁盤占用進(jìn)行優(yōu)化，包括：在無(wú)相關(guān)性使用的情況下，限制使用TermVector；在設(shè)計(jì)schema時(shí)，選擇合適的文檔粒度，設(shè)置有選擇性的存儲(chǔ)域；若通過(guò)Solr的唯一鍵定位數(shù)據(jù)庫(kù)中的一條記錄，將stored的屬性全部設(shè)為fals；對(duì)于不貢獻(xiàn)評(píng)分的屬性，將omitNorms設(shè)置為true；對(duì)日期以及數(shù)字類型，減少精度步長(zhǎng)precisionStep。優(yōu)選地，所述對(duì)事務(wù)日志進(jìn)行優(yōu)化，包括：所述事務(wù)日志用于支持近實(shí)時(shí)獲取數(shù)據(jù)以及原子更新；使寫持久化與提交流程解耦；支持SolrCloud分片主節(jié)點(diǎn)的副本同步；用于平衡事務(wù)日志的長(zhǎng)度與硬提交的頻率。第二方面，一種基于Solr數(shù)據(jù)搜索的裝置，所述裝置包括：第一獲取模塊，用于選用HBase或是MongoDB的底層存儲(chǔ)數(shù)據(jù)庫(kù)，并根據(jù)記錄的字段生成rowkey；優(yōu)化模塊，用于在內(nèi)存的優(yōu)化上對(duì)JVM進(jìn)行優(yōu)化，并對(duì)Solr的內(nèi)存配置、磁盤占用和事務(wù)日志進(jìn)行優(yōu)化；第二獲取模塊，用于在查詢數(shù)據(jù)時(shí)，根據(jù)Solr創(chuàng)建后的索引從所述底層存儲(chǔ)中獲取對(duì)應(yīng)的數(shù)據(jù)。優(yōu)選地，所述優(yōu)化模塊，具體用于：分配給所述Solr需要的內(nèi)存后再加上預(yù)設(shè)大小的緩存。優(yōu)選地，所述優(yōu)化模塊，還具體用于：對(duì)所述Solr的緩存大小、回收策略的選取進(jìn)行配置；所述緩存包括自動(dòng)預(yù)熱緩存、過(guò)濾器緩存、文檔緩存、查詢結(jié)果緩存和/或域值緩存；所述回收策略的選取為：使用FieldCache，減少mergeFactor的使用，使索引中保存少的段，關(guān)閉使用索引的復(fù)合文件格式，并在創(chuàng)建索引時(shí)選用NIOFSDirectory使用NIO，直接使用直接內(nèi)存，選用合適的段合并策略避免生成小段。優(yōu)選地，所述優(yōu)化模塊，還具體用于：在無(wú)相關(guān)性使用的情況下，限制使用TermVector；在設(shè)計(jì)schema時(shí)，選擇合適的文檔粒度，設(shè)置有選擇性的存儲(chǔ)域；若通過(guò)Solr的唯一鍵定位數(shù)據(jù)庫(kù)中的一條記錄，將stored的屬性全部設(shè)為fals；對(duì)于不貢獻(xiàn)評(píng)分的屬性，將omitNorms設(shè)置為true；對(duì)日期以及數(shù)字類型，減少精度步長(zhǎng)precisionStep。優(yōu)選地，所述優(yōu)化模塊，還具體用于：所述事務(wù)日志用于支持近實(shí)時(shí)獲取數(shù)據(jù)以及原子更新；使寫持久化與提交流程解耦；支持SolrCloud分片主節(jié)點(diǎn)的副本同步；用于平衡事務(wù)日志的長(zhǎng)度與硬提交的頻率。本發(fā)明實(shí)施例提供的一種基于Solr數(shù)據(jù)搜索的方法及裝置，選用HBase或是MongoDB的底層存儲(chǔ)數(shù)據(jù)庫(kù)，并根據(jù)記錄的字段生成rowkey；在內(nèi)存的優(yōu)化上對(duì)JVM進(jìn)行優(yōu)化，并對(duì)Solr的內(nèi)存配置、磁盤占用和事務(wù)日志進(jìn)行優(yōu)化；在查詢數(shù)據(jù)時(shí)，根據(jù)Solr創(chuàng)建后的索引從所述底層存儲(chǔ)中獲取對(duì)應(yīng)的數(shù)據(jù)。從而通過(guò)對(duì)底層存儲(chǔ)以及數(shù)據(jù)結(jié)構(gòu)的設(shè)計(jì)可以實(shí)現(xiàn)數(shù)據(jù)對(duì)Solr的弱依賴性，將數(shù)據(jù)獨(dú)立出來(lái)；通過(guò)對(duì)Solr進(jìn)行優(yōu)化以及shema設(shè)計(jì)提升搜索性能，同時(shí)通過(guò)對(duì)JVM調(diào)優(yōu)提升Solr集群查詢效率并降低Solr因發(fā)生FullGC導(dǎo)致Socket超時(shí)的可能性；對(duì)數(shù)據(jù)創(chuàng)建索引以及數(shù)據(jù)存儲(chǔ)至數(shù)據(jù)庫(kù)做好事務(wù)控制，保證了搜索的數(shù)據(jù)與查詢的數(shù)據(jù)同步。附圖說(shuō)明圖1是本發(fā)明實(shí)施例提供的一種基于Solr數(shù)據(jù)搜索的方法的流程示意圖；圖2是本發(fā)明實(shí)施例提供的一種基于Solr數(shù)據(jù)搜索的裝置的功能模塊示意圖。具體實(shí)施方式下面結(jié)合附圖和實(shí)施例對(duì)本發(fā)明實(shí)施例作進(jìn)一步的詳細(xì)說(shuō)明?？梢岳斫獾氖牵颂幩枋龅木唧w實(shí)施例僅僅用于解釋本發(fā)明實(shí)施例，而非對(duì)本發(fā)明實(shí)施例的限定。另外還需要說(shuō)明的是，為了便于描述，附圖中僅示出了與本發(fā)明實(shí)施例相關(guān)的部分而非全部結(jié)構(gòu)。參考圖1，圖1是本發(fā)明實(shí)施例提供的一種基于Solr數(shù)據(jù)搜索的方法的流程示意圖。如圖1所示，所述基于Solr數(shù)據(jù)搜索的方法包括：步驟101，選用HBase或是MongoDB的底層存儲(chǔ)數(shù)據(jù)庫(kù)，并根據(jù)記錄的字段生成rowkey；具體的，搜索引擎的返回結(jié)果是按相關(guān)性進(jìn)行排序的，而關(guān)系型數(shù)據(jù)庫(kù)只能按照表中的列返回。也就是說(shuō)，如果無(wú)相關(guān)性的限制，可以選擇使用內(nèi)存型數(shù)據(jù)庫(kù)同步關(guān)系型數(shù)據(jù)庫(kù)實(shí)現(xiàn)查詢性能的提升，而沒(méi)必要使用搜索引擎。搜索引擎不是存儲(chǔ)數(shù)據(jù)的地方，除非數(shù)據(jù)對(duì)查詢和顯示結(jié)果有用。所以，不應(yīng)該將搜索引擎當(dāng)做數(shù)據(jù)庫(kù)使用?？紤]到像Memcache、Redis等內(nèi)存型數(shù)據(jù)庫(kù)對(duì)內(nèi)存的依賴性，從經(jīng)濟(jì)角度以及大數(shù)據(jù)量條件下，啟動(dòng)內(nèi)存型數(shù)據(jù)庫(kù)加載數(shù)據(jù)的時(shí)間消耗上，暫不考慮將內(nèi)存型數(shù)據(jù)庫(kù)作為備選方案中。選用HBase或是MongoDB都是較為合適的方案。同時(shí)，為了將底層存儲(chǔ)與搜索引擎解耦，那么數(shù)據(jù)庫(kù)必須要有手段不通過(guò)Solr仍舊可以獲取數(shù)據(jù)的方式，這也就要求在數(shù)據(jù)庫(kù)庫(kù)表設(shè)計(jì)時(shí)要完全避免唯一鍵依賴于Solr來(lái)產(chǎn)生的情況出現(xiàn)，尤其是對(duì)于HBase。為了避免全表掃描，必須要通過(guò)唯一的rowkey獲取準(zhǔn)確的記錄，那么該rowkey的設(shè)計(jì)才是采用Solr+HBase架構(gòu)的關(guān)鍵。根據(jù)所存記錄的字段采用一定的方式獲取rowkey，而不是生成唯一隨機(jī)值作為rowkey以及Solr的uniquekey。步驟102，在內(nèi)存的優(yōu)化上對(duì)JVM進(jìn)行優(yōu)化，并對(duì)Solr的內(nèi)存配置、磁盤占用和事務(wù)日志進(jìn)行優(yōu)化；其中，JVM為Java虛擬機(jī)，Solr為一款全文檢索的應(yīng)用。具體的，由于Solr底層封裝的是Lucene，而Lucene為了提高搜索效率，在索引時(shí)采用的是倒排索引。而MapReduce的發(fā)明也是得益于倒排索引。NoSQL的設(shè)計(jì)都是反規(guī)范化(denormalized)的，從而避免了關(guān)系型數(shù)據(jù)庫(kù)中為了精簡(jiǎn)存儲(chǔ)而在查詢時(shí)不得不使用一系列的連接語(yǔ)句，這樣的設(shè)計(jì)雖然使存儲(chǔ)數(shù)據(jù)產(chǎn)生大量的冗余，但同時(shí)也獲得了查詢效率的提高。這也在設(shè)計(jì)上提供了指導(dǎo)，不管是數(shù)據(jù)庫(kù)的設(shè)計(jì)，還是Solr索引記錄的設(shè)計(jì)，都應(yīng)該是以記錄為單位，而不是關(guān)系型數(shù)據(jù)庫(kù)中所謂的表(table)為單位。優(yōu)選地，所述在內(nèi)存的優(yōu)化上對(duì)JVM進(jìn)行優(yōu)化，包括：分配給所述Solr需要的內(nèi)存后再加上預(yù)設(shè)大小的緩存。具體的，JVM設(shè)置主要的原則是，只分配給Solr需要的內(nèi)存再加上一點(diǎn)緩存即可，避免gc時(shí)要花費(fèi)很長(zhǎng)時(shí)間。因?yàn)镾olr集群是依賴于ZooKeeper協(xié)同實(shí)現(xiàn)的，如果在發(fā)生Stop-The-World時(shí)，ZooKeeper超時(shí)會(huì)給ZooKeeper集群造成影響。尤其是在使用HBase作為底層存儲(chǔ)搭建集群的情況下，一旦HBase集群發(fā)生FullGC時(shí)間過(guò)長(zhǎng)，有可能導(dǎo)致HBase的HMaster節(jié)點(diǎn)失聯(lián)，更壞的情況是Standby節(jié)點(diǎn)也失聯(lián)，出現(xiàn)這種情況就意味著整個(gè)底層存儲(chǔ)不可用。所以，做好JVM調(diào)優(yōu)至關(guān)重要。優(yōu)選地，所述對(duì)Solr的內(nèi)存配置進(jìn)行優(yōu)化，包括：對(duì)所述Solr的緩存大小、回收策略的選取進(jìn)行配置；所述緩存包括自動(dòng)預(yù)熱緩存、過(guò)濾器緩存、文檔緩存、查詢結(jié)果緩存和/或域值緩存；所述回收策略的選取為：使用FieldCache，減少mergeFactor的使用，使索引中保存少的段，關(guān)閉使用索引的復(fù)合文件格式，并在創(chuàng)建索引時(shí)選用NIOFSDirectory使用NIO，直接使用直接內(nèi)存，選用合適的段合并策略避免生成小段。具體的，在內(nèi)存的優(yōu)化上除了對(duì)JVM的優(yōu)化外，Solr本身也有大量的配置是可以調(diào)整，從而適應(yīng)各種生產(chǎn)環(huán)境的，比如緩存大小的調(diào)整，回收策略的選取等，而可配置的緩存又包括自動(dòng)預(yù)熱緩存(autowarming)、過(guò)濾器緩存、文檔緩存、查詢結(jié)果緩存、域值(FieldValue)緩存等。建議使用域緩存(FieldCache)，減少mergeFactor的使用，使索引中保存較少的段，關(guān)閉使用索引的復(fù)合文件格式。同時(shí)，創(chuàng)建索引時(shí)可以選用NIOFSDirectory(Solr技術(shù)中對(duì)Directory接口的一個(gè)實(shí)現(xiàn))使用非阻塞IO(NIO)，直接使用直接內(nèi)存，避免搶占JVM堆內(nèi)存。選用合適的段合并策略避免生成過(guò)多的小段。為了避免單個(gè)schema數(shù)據(jù)量達(dá)到一定量級(jí)后產(chǎn)生的性能問(wèn)題，可以考慮對(duì)該schema進(jìn)行拆分，按天或按月動(dòng)態(tài)生成schema，查詢時(shí)再采用Collection的Alias將所有相同數(shù)據(jù)結(jié)構(gòu)的schema合并起來(lái)，從而避免了查詢單個(gè)schema。同時(shí)，考慮將Replication的數(shù)量調(diào)大同樣可以達(dá)到提高響應(yīng)速度的目的。但也不是集群的數(shù)量越大越好，Solr只是理論上可以無(wú)限擴(kuò)展的，在該領(lǐng)域，Solr仍有其局限性。優(yōu)選地，所述對(duì)Solr的磁盤占用進(jìn)行優(yōu)化，包括：在無(wú)相關(guān)性使用的情況下，限制使用詞向量(TermVector)；在設(shè)計(jì)schema(特指Solr的schema.xml配置文件)時(shí)，選擇合適的文檔粒度，設(shè)置有選擇性的存儲(chǔ)域；若通過(guò)Solr的唯一鍵定位數(shù)據(jù)庫(kù)中的一條記錄，將stored的屬性全部設(shè)為fals；對(duì)于不貢獻(xiàn)評(píng)分的屬性，將omitNorms設(shè)置為true；對(duì)日期以及數(shù)字類型，減少精度步長(zhǎng)precisionStep。具體的，對(duì)Solr的配置上同樣有可優(yōu)化的地方，無(wú)論是內(nèi)存占用還是磁盤的占用上。例如，在無(wú)相關(guān)性使用的情況下，可以限制使用TermVector，從而減少磁盤的占用。設(shè)計(jì)schema時(shí)，選擇合適的文檔粒度，存儲(chǔ)域可以有選擇性的設(shè)置，如果主要是通過(guò)Solr的唯一鍵定位數(shù)據(jù)庫(kù)中的一條記錄，可以將stored的屬性全部設(shè)為false，從而降低磁盤壓力。對(duì)于某些不準(zhǔn)備貢獻(xiàn)評(píng)分的屬性，可以將omitNorms設(shè)置為true。對(duì)于日期以及數(shù)字類型，可以適當(dāng)?shù)膶⒕炔介L(zhǎng)precisionStep設(shè)置的小一點(diǎn)。優(yōu)選地，所述對(duì)事務(wù)日志進(jìn)行優(yōu)化，包括：所述事務(wù)日志用于支持近實(shí)時(shí)獲取數(shù)據(jù)以及原子更新；使寫持久化與提交流程解耦；支持SolrCloud(Solr集群)分片主節(jié)點(diǎn)的副本同步；用于平衡事務(wù)日志的長(zhǎng)度與硬提交的頻率。具體的，事務(wù)日志可以確保不會(huì)丟失未提交更新，主要目的有三個(gè)：1、用于支持近實(shí)時(shí)(NRT)獲取數(shù)據(jù)以及原子更新；2、使寫持久化與提交流程解耦；3、支持SolrCloud分片主節(jié)點(diǎn)的副本同步。對(duì)于事務(wù)日志來(lái)說(shuō)就是平衡事務(wù)日志的長(zhǎng)度(多少未提交更新)與硬提交的頻率。如果事務(wù)日志過(guò)大，那么重啟就會(huì)花更久的時(shí)間來(lái)執(zhí)行更新。步驟103，在查詢數(shù)據(jù)時(shí)，根據(jù)Solr創(chuàng)建后的索引從所述底層存儲(chǔ)中獲取對(duì)應(yīng)的數(shù)據(jù)。具體的，Solr沒(méi)有基于文檔級(jí)別的安全，而根據(jù)所選擇數(shù)據(jù)庫(kù)，需要根據(jù)實(shí)際情況加上事務(wù)控制。對(duì)于HBase，有諸如Haeinsa、Tephra等事務(wù)框架可以在HBase上添加事務(wù)，而MongoDB目前最為流行的添加事務(wù)控制的方式是使用消息隊(duì)列模擬事務(wù)實(shí)現(xiàn)事務(wù)的控制。如果添加上Solr創(chuàng)建索引的事務(wù)控制，可以將Solr創(chuàng)建索引以及數(shù)據(jù)庫(kù)數(shù)據(jù)的增刪作為整體考慮事務(wù)的添加。在吞吐量不是特別大的情況，可以使用RabbitMQ模擬事務(wù)，而在吞吐量很大的情況下，推薦使用Kafka，RabbitMQ在吞吐量和每秒事務(wù)/請(qǐng)求的數(shù)量(TPS)方面與Kafka沒(méi)有可比性。但Kafka設(shè)計(jì)的初衷就是處理日志的，可以看做是一個(gè)日志系統(tǒng)，針對(duì)性很強(qiáng)，所以它并沒(méi)有具備一個(gè)成熟消息隊(duì)列MQ應(yīng)該具備的特性。而RabbitMQ比Kafka成熟，在可用性上，穩(wěn)定性上，可靠性上，RabbitMQ超過(guò)Kafka。本發(fā)明實(shí)施例提供的一種基于Solr數(shù)據(jù)搜索的方法，選用HBase或是MongoDB的底層存儲(chǔ)數(shù)據(jù)庫(kù)，并根據(jù)記錄的字段生成rowkey；在內(nèi)存的優(yōu)化上對(duì)JVM進(jìn)行優(yōu)化，并對(duì)Solr的內(nèi)存配置、磁盤占用和事務(wù)日志進(jìn)行優(yōu)化；在查詢數(shù)據(jù)時(shí)，根據(jù)Solr創(chuàng)建后的索引從所述底層存儲(chǔ)中獲取對(duì)應(yīng)的數(shù)據(jù)。從而通過(guò)對(duì)底層存儲(chǔ)以及數(shù)據(jù)結(jié)構(gòu)的設(shè)計(jì)可以實(shí)現(xiàn)數(shù)據(jù)對(duì)Solr的弱依賴性，將數(shù)據(jù)獨(dú)立出來(lái)；通過(guò)對(duì)Solr進(jìn)行優(yōu)化以及shema設(shè)計(jì)提升搜索性能，同時(shí)通過(guò)對(duì)JVM調(diào)優(yōu)提升Solr集群查詢效率并降低Solr因發(fā)生FullGC導(dǎo)致Socket超時(shí)的可能性；對(duì)數(shù)據(jù)創(chuàng)建索引以及數(shù)據(jù)存儲(chǔ)至數(shù)據(jù)庫(kù)做好事務(wù)控制，保證了搜索的數(shù)據(jù)與查詢的數(shù)據(jù)同步。參考圖2，圖2是本發(fā)明實(shí)施例提供的一種基于Solr數(shù)據(jù)搜索的裝置的功能模塊示意圖。如圖2所示，所述裝置包括：第一獲取模塊201，用于選用HBase或是MongoDB的底層存儲(chǔ)數(shù)據(jù)庫(kù)，并根據(jù)記錄的字段生成rowkey；優(yōu)化模塊202，用于在內(nèi)存的優(yōu)化上對(duì)JVM進(jìn)行優(yōu)化，并對(duì)Solr的內(nèi)存配置、磁盤占用和事務(wù)日志進(jìn)行優(yōu)化；第二獲取模塊203，用于在查詢數(shù)據(jù)時(shí)，根據(jù)Solr創(chuàng)建后的索引從所述底層存儲(chǔ)中獲取對(duì)應(yīng)的數(shù)據(jù)。優(yōu)選地，所述優(yōu)化模塊202，具體用于：分配給所述Solr需要的內(nèi)存后再加上預(yù)設(shè)大小的緩存。優(yōu)選地，所述優(yōu)化模塊202，還具體用于：對(duì)所述Solr的緩存大小、回收策略的選取進(jìn)行配置；所述緩存包括自動(dòng)預(yù)熱緩存、過(guò)濾器緩存、文檔緩存、查詢結(jié)果緩存和/或域值緩存；所述回收策略的選取為：使用FieldCache，減少mergeFactor的使用，使索引中保存少的段，關(guān)閉使用索引的復(fù)合文件格式，并在創(chuàng)建索引時(shí)選用NIOFSDirectory使用NIO，直接使用直接內(nèi)存，選用合適的段合并策略避免生成小段。優(yōu)選地，所述優(yōu)化模塊202，還具體用于：在無(wú)相關(guān)性使用的情況下，限制使用TermVector；在設(shè)計(jì)schema時(shí)，選擇合適的文檔粒度，設(shè)置有選擇性的存儲(chǔ)域；若通過(guò)Solr的唯一鍵定位數(shù)據(jù)庫(kù)中的一條記錄，將stored的屬性全部設(shè)為fals；對(duì)于不貢獻(xiàn)評(píng)分的屬性，將omitNorms設(shè)置為true；對(duì)日期以及數(shù)字類型，減少精度步長(zhǎng)precisionStep。優(yōu)選地，所述優(yōu)化模塊202，還具體用于：所述事務(wù)日志用于支持近實(shí)時(shí)獲取數(shù)據(jù)以及原子更新；使寫持久化與提交流程解耦；支持SolrCloud分片主節(jié)點(diǎn)的副本同步；用于平衡事務(wù)日志的長(zhǎng)度與硬提交的頻率。本發(fā)明實(shí)施例提供的一種基于Solr數(shù)據(jù)搜索的裝置，選用HBase或是MongoDB的底層存儲(chǔ)數(shù)據(jù)庫(kù)，并根據(jù)記錄的字段生成rowkey；在內(nèi)存的優(yōu)化上對(duì)JVM進(jìn)行優(yōu)化，并對(duì)Solr的內(nèi)存配置、磁盤占用和事務(wù)日志進(jìn)行優(yōu)化；在查詢數(shù)據(jù)時(shí)，根據(jù)Solr創(chuàng)建后的索引從所述底層存儲(chǔ)中獲取對(duì)應(yīng)的數(shù)據(jù)。從而通過(guò)對(duì)底層存儲(chǔ)以及數(shù)據(jù)結(jié)構(gòu)的設(shè)計(jì)可以實(shí)現(xiàn)數(shù)據(jù)對(duì)Solr的弱依賴性，將數(shù)據(jù)獨(dú)立出來(lái)；通過(guò)對(duì)Solr進(jìn)行優(yōu)化以及shema設(shè)計(jì)提升搜索性能，同時(shí)通過(guò)對(duì)JVM調(diào)優(yōu)提升Solr集群查詢效率并降低Solr因發(fā)生FullGC導(dǎo)致Socket超時(shí)的可能性；對(duì)數(shù)據(jù)創(chuàng)建索引以及數(shù)據(jù)存儲(chǔ)至數(shù)據(jù)庫(kù)做好事務(wù)控制，保證了搜索的數(shù)據(jù)與查詢的數(shù)據(jù)同步。以上結(jié)合具體實(shí)施例描述了本發(fā)明實(shí)施例的技術(shù)原理。這些描述只是為了解釋本發(fā)明實(shí)施例的原理，而不能以任何方式解釋為對(duì)本發(fā)明實(shí)施例保護(hù)范圍的限制?；诖颂幍慕忉專绢I(lǐng)域的技術(shù)人員不需要付出創(chuàng)造性的勞動(dòng)即可聯(lián)想到本發(fā)明實(shí)施例的其它具體實(shí)施方式，這些方式都將落入本發(fā)明實(shí)施例的保護(hù)范圍之內(nèi)。當(dāng)前第1頁(yè)1 2 3 當(dāng)前第1頁(yè)1 2 3