1 、 Solr 4.0 soft commit 软提交
2 、 lucene 自带的特性
http://wiki.apache.org/lucene-java/NearRealtimeSearch
Lucene has a feature called near-real-time search to address exactly this need.
It requires that your IndexReader is in the same JVM as your IndexWriter.
You make changes with the IndexWriter, and then open a reader directly from the writer using IndexReader.open(writer), or on older Lucene releases writer.getReader(). This call will normally be very fast (in proportion to how many changes you've made since last opening a reader) as it bypasses the costly commit normally required for opening a reader. It's able to search the un-committed changes in the writer.
This reader still searches a point-in-time snapshot from the writer, ie all changes as of when you opened it.
包括另一个项目用的此特性：
https://tgels.com/solr-ra.jsp?by=solr-ra.jsp&si=60cb61a1a3b1f0cd31e708c389e3#downloads
3 、 zoie linkedIn 贡献
中文详细解读
https://linkedin.jira.com/wiki/pages/viewpage.action?pageId=4456480
4 、性能调优
http://wiki.apache.org/solr/NearRealtimeSearchTuning?highlight=%28real%29%7C%28time%29
http://java.dzone.com/articles/tuning-solr-near-real-time
5 、tgels - Solr with Ranking Algorithm
http://tgels.org/wiki/en/Near_Real_Time_Search_ver_3.x
6、比较
The NRT implementation differs from soft commit as below:
- Does not close the SolrIndexSearcher object. SolrIndexSearcher is a heavy object, holds caches, searches could be in progress, ref-counted, etc.
- The implementation passes the IndexReader as a parameter to each search ( suits the methodology of de-coupling the reader and searcher, and not maintaining any directory related information).
- Since the IndexReader is passed as a parameter, the search can be very granular, allowing query1, query2, query3 to return updated results in a high frequency update scenario.
As the searcher is not closed, the cache structures are not destroyed. The user can disable the queryResultsCache, etc. as needed for now. The dynamic IndexReader allows fine granular realtime search which may not be possible with soft commit.