在做一個(gè)網(wǎng)站站內(nèi)搜索中，使用lucene實(shí)現(xiàn)實(shí)時(shí)搜索時(shí)，我遇到了一對(duì)矛盾：在使用一個(gè)IndexSearcher單例時(shí)，搜索的效率極高，但是在 indexSearcher實(shí)例新建后新增的索引，這個(gè)單例是不可見(jiàn)的，除非我定時(shí)的去觸發(fā)將這個(gè)IndexSearcher重新建一次，否則就不能搜索出最新的信息。假如我每來(lái)一個(gè) request，就新建一個(gè)IndexSearcher實(shí)例，則可以搜索出最新的信息，但是，效率非常低。不知道大家有什么好的策略或插件，提出來(lái)討論討論。（我現(xiàn)在的策略是定時(shí)的reopen下insexSearcher）

可以使用這樣的策略：
使用一個(gè)獨(dú)立的線程去維護(hù)這個(gè)IndexSearcher,當(dāng)索引有更新時(shí)，記錄下索引已更新；當(dāng)有request時(shí)，先去檢驗(yàn)一下索引是否有更新，有則reopen后再查，無(wú)則直接查。

最簡(jiǎn)單的方法，用timer定時(shí)生成下indexSearcher，全文引擎有略微的延時(shí)也是可以接受的。

用2.3的包,有一個(gè)reopen()的方法,只會(huì)加載變化的索引片段。
每次索引更新之后，對(duì)于當(dāng)前正在使用的IndexReader來(lái)說(shuō)不是可見(jiàn)的，必須重新open一次Index，才能保證能夠搜索到新加入的 document，2.3相當(dāng)于做了一次增量的open。
每一次reopen前可以先判斷一下是不是當(dāng)前的索引文件,主要看有沒(méi)有更新,
如果有更新,用reopen()方法打開(kāi),看它文檔上說(shuō)明是只加載更新了的索引文件,這樣就不用全部重新打開(kāi)了,時(shí)間主要耗在這里,如果判斷結(jié)果是沒(méi)有更新則直接返回那個(gè)實(shí)例就行了
IndexReader.reopen一直是沒(méi)有實(shí)現(xiàn)的？

比如在你加了索引之后新生成一個(gè)searcher把那個(gè)單例給替換了 ，但是，當(dāng)幾十的并發(fā)增量索引過(guò)來(lái)的時(shí)候，就不能這么觸發(fā)了，我現(xiàn)在只是弄了個(gè)timer，定時(shí)30秒鐘來(lái)?yè)Q個(gè)IndexSearcher實(shí)例。

the singleton of IndexSearcher will be more efficient.
see http://wiki.apache.org/lucene-java/ImproveSearchingSpeed

由于前一章所述的Lucene的事務(wù)性，使得Lucene可以增量的添加一個(gè)段，我們知道，倒排索引是有一定的格式的，而這個(gè)格式一旦寫(xiě)入是非常難以改變的，那么如何能夠增量建索引呢？Lucene使用段這個(gè)概念解決了這個(gè)問(wèn)題，對(duì)于每個(gè)已經(jīng)生成的段，其倒排索引結(jié)構(gòu)不會(huì)再改變，而增量添加的文檔添加到新的段中，段之間在一定的時(shí)刻進(jìn)行合并，從而形成新的倒排索引結(jié)構(gòu)。
然而也正因?yàn)長(zhǎng)ucene的事務(wù)性，使得Lucene的索引不夠?qū)崟r(shí)，如果想Lucene實(shí)時(shí)，則必須新添加的文檔后IndexWriter需要commit，在搜索的時(shí)候IndexReader需要重新的打開(kāi)，然而當(dāng)索引在硬盤(pán)上的時(shí)候，尤其是索引非常大的時(shí)候，IndexWriter的commit操作和IndexReader的open操作都是非常慢的，根本達(dá)不到實(shí)時(shí)性的需要。
好在Lucene提供了RAMDirectory，也即內(nèi)存中的索引，能夠很快的commit和open，然而又存在如果索引很大，內(nèi)存中不能夠放下的問(wèn)題。

所以要構(gòu)建實(shí)時(shí)的索引，就需要內(nèi)存中的索引RAMDirectory和硬盤(pán)上的索引 FSDirectory相互配合來(lái)解決問(wèn)題。

Zoie 是linkedin支持的基于Lucene開(kāi)源實(shí)時(shí)搜索引擎項(xiàng)目

? Solr? ( http://lucene.apache.org/solr/? )
說(shuō)明：基于 Lucene 的企業(yè)級(jí)搜索的開(kāi)箱即用的解決方案
優(yōu)點(diǎn)：比較成熟的解決方案，也有很多的成功案例。Lucene 子項(xiàng)目，實(shí)現(xiàn)了大部分常見(jiàn)的搜索功能需求，包括 facet 搜索（搜索結(jié)果分類過(guò)濾）等。
缺點(diǎn)：可定制性比 Lucene 要差，一些不常見(jiàn)的需求，定制的難度比直接在 Lucene 上做要大的多。性能上，由于 Solr 的建索引和搜索是同一個(gè)進(jìn)程，耦合度比較高，對(duì)于性能調(diào)優(yōu)有一定的影響。

? 直接使用 Lucene? ( http://lucene.apache.org? )
說(shuō)明：Lucene 是一個(gè) JAVA 搜索類庫(kù)，它本身并不是一個(gè)完整的解決方案，需要額外的開(kāi)發(fā)工作
優(yōu)點(diǎn)：成熟的解決方案，有很多的成功案例。apache頂級(jí)項(xiàng)目，正在持續(xù)快速的進(jìn)步。龐大而活躍的開(kāi)發(fā)社區(qū)，大量的開(kāi)發(fā)人員。它只是一個(gè)類庫(kù)，有足夠的定制和優(yōu)化空間：經(jīng)過(guò)簡(jiǎn)單定制，就可以滿足絕大部分常見(jiàn)的需求；經(jīng)過(guò)優(yōu)化，可以支持10億+ 量級(jí)的搜索。
缺點(diǎn)：需要額外的開(kāi)發(fā)工作。所有的擴(kuò)展，分布式，可靠性等都需要自己實(shí)現(xiàn)；非實(shí)時(shí)，從建索引到可以搜索中間有一個(gè)時(shí)間延遲，而當(dāng)前的“近實(shí)時(shí)” (Lucene Near Real Time search)搜索方案的可擴(kuò)展性有待進(jìn)一步完善

2.9新版本引入了IndexWriter.getReader()方法，它可用于搜索目前完整的索引，包括當(dāng)前IndexWriter會(huì)話中還沒(méi)有提交的改變，這帶來(lái)了接近于實(shí)時(shí)搜索的能力。此外，你還可以調(diào)用IndexWriter.setMergedSegmentWarmer()方法進(jìn)行“預(yù)熱”，這樣那些片斷便可以立即投入使用了。

2.9版本之前的版本，都是基于文本搜索的，因?yàn)閷?duì)于很多數(shù)字的處理方式就很頭疼，例如在我們項(xiàng)目中遇到的很多問(wèn)題都是由于把數(shù)字當(dāng)作了文本處理出現(xiàn)的 BUG：1、搜索價(jià)格的5，把包含.5的也搜索出來(lái)了；2、排序（降序）時(shí)，把800排到5000前面；……這些都是由于Lucene把所有的都作為文本處理的方式造成的問(wèn)題。Lucene 2.9以后已經(jīng)自帶對(duì)數(shù)字的處理方式。Field和Query類會(huì)采取合適的精度進(jìn)行索引和搜索，這樣大大降低了需要搜索的關(guān)鍵字?jǐn)?shù)量，使查詢的響應(yīng)能力得以顯著提高。

我們web應(yīng)用是好幾臺(tái)機(jī)器，而索引也有好幾種，如果用lucene的話，定時(shí)更新不能保證所有服務(wù)器同步。如果用mount方式，lucen也有問(wèn)題， 所以想用solr統(tǒng)一管理所有索引。然后讓其它服務(wù)器從一個(gè)統(tǒng)一的地方查詢索引。
http://lucene-group.group.javaeye.com/group/topic/23507


億級(jí)數(shù)據(jù)的高并發(fā)通用搜索引擎架構(gòu)設(shè)計(jì) http://blog.s135.com/post/385/
http://lucene-group.group.javaeye.com/group/topic/2786
http://blog.fulin.org/2010/11/search_solutions_compare.html
http://www.javaeye.com/topic/117212
Twitter新搜索架構(gòu)將采用開(kāi)源Lucene http://cloud.csdn.net/a/20101008/280220.html?1286504886
用 Lucene構(gòu)建實(shí)時(shí)的索引 http://www.cnblogs.com/forfuture1978/archive/2010/06/08/1753642.html
基于lucene實(shí)現(xiàn)自己的推薦引擎 http://blog.fulin.org/2010/10/recommendation_system_based_lucene.html
Lucene3.0(2.9)的主要變化 http://www.ourys.com/post/lucene3-0_about.html
Katta is a scalable, failure tolerant, distributed, data storage for real time access.