Apache Solr** with RankingAlgorithm enables Solr's search results to be comparable to Google Site Search and much better than Apache Lucene** for searches using the Perl index, see comparison searches. RankingAgorithm is a search library that uses a new scoring algorithm to rank results accurately and relevantly. RankingAlgorithm is very easy to use and uses the very popular Lucene index but scores and ranks on its own.

Solr with RankingAlgorithm also supports NRT and can update documents at about 5000 documents in 498 with concurrent searches without closing the Searchers or clearing the caches, etc., see
Near Real Time Search.

Multiple Algorithm are available SIMPLE, SIMPLE1, COMPLEX, COMPLEX1. SIMPLE* are very fast algorithms and can return queries in <50ms on a 10m wikipedia index (complete index).
It can also scale to 100m docs or maybe more. COMPLEX is a more complex algorithm so is a little
slower compared to the SIMPLE, but can also still return queries in < 100ms on a 10m wikipedia index (complete index).
COMPLEX is more accurate and should be able to give you the best rankings as compared to SIMPLE*.

In document mode, it ranks documents such as HTML, Wikipedia, Word/PDF docs relevantly while in Product mode, a term's occurrence is taken into account and scored accordingly. So titles starting with "wii console" are ranked first, and the others rank lower as the occurrence of "wii console" shifts in the title or gets reversed, see below:

Wii Console and Wii Fit Plus with Balance Board Bundle (Nintendo Wii)

Wii Console System with Wii Sports Resort Game with TWO MotionPlus Attachments

The RankingAlgorithm has been integrated into Solr so that either Lucene or the RankingAlgorithm can be used to do the search. The RankingAlgorithm scoring or working does not break any of the existing functionality, so shrad, faceting, highlighting, etc. still work as before. RankingAlogirhtm only uses Lucene Apis to retrieve the terms from the index and uses its own ranking and scoring to rank the documents. The scoring is very friendly and easy to follow.

Try Autocomplete using Solr with RankingAlgorithm, similar to Google/Yahoo/Bing's autocomplete (It is free), Give it a try

Installing and Using Solr with RankingAlgorithm

Install Solr as before, no changes to the existing installation steps (see Solr docs
for installation). No changes to the way you query or use Solr. The change is when you
initiate a query, the search uses RankingAlgorithm instead of Lucene. You can still use
Lucene by adding "&lucene=true" to use Lucene as before. You can download Solr with RA from here and follow the steps as in the download docs either on the Solr website or from here.

ver 1.4.8, works with Lucene 4.3 [md5sum:a40e448358657de69291ee1c517d3a64], 2013/06/92 (1.4.8.20130602.1)
(Has built in components Edge/Infix autocomplete with source. Support for glob/regular expressions in boolean queries)

ver 1.4.7, works with Lucene 4.1/4.0 [md5sum:ea6d5ca2c727026a05778827], 2013/03/18 (1.4.7.20130318.1)
(H/as built in components Edge/Infix autocomplete with source. Support for glob/regular expressions in boolean queries)

ver 1.4.6, works with Lucene 4.x [md5sum:61cab6301d30fa681ab198cf57355e42], 2012/12/23 (1.4.5.20121105.6)
(Has built in components Edge/Infix autocomplete with source. Support for glob/regular expressions in boolean queries)

ver 1.4.5, works with Lucene 4.x [md5sum:97ff962f5bb1a060591f35e07effa8fd], 2012/12/09 (1.4.5.20121105.4)
(Has built in components Edge/Infix autocomplete with source. Support for glob/regular expressions in boolean queries)

4. Add rankingalgorithm40_1.5.x.jar and lucene-ra-core-4x.jar to the classpath
5. Run your previous Lucene examples, applications with no changes but using the RankingAlgorithm for searches instead of Lucene library.

Offers multiple granularities, request and intra request. The granularity attribute controls the NRT behavior. With the default granularity="request", all search components like search, faceting, highlighting, etc. will see a consistent view of the index and will all report the same of number of documents. With granularity="intrarequest", the components may each report the most recent changes to the index.

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.

Warning! Warning! Warning!

You are using Google Chrome which does not fire Javascript events/functions properly.

The download links may not work. Please use Firefox/Safari/IE/Opera.

Warning! Warning! Warning!
You are using Google Chrome which does not fire Javascript events/functions properly.
The download links may not work. Please use Firefox/Safari/IE/Opera.

Background
Lucene/Solr search and commit architecture is designed to work off a point-in-time snapshots of the index.
Any add/update/deletion needs a commit to be visible to searches (or atleast a soft-commit). soft-commit still re-opens
the SolrIndexSearcher object and can be a performance limitation if the soft-commits happen more than one per second. Realtime-search
does away with the point-in-time snapshots and makes available a near realtime view of the index. So any changes made to the index are immediately visible. Performance
is not a limitation as it does not close the SolrIndexSearcher object but makes available a new NRT Reader to the searcher.

Realtime-search is different from realtime-get which allows you to check if a document exists in the transaction log and does not have search capability.
Realtime-search allows full search, so you could search by id, text, location, etc. using boolean, dismax, faceting, range queries.
Realtime-search does not need the transaction update log needed by realtime-get. So you can turn this off for improved performance.
autoCommit freq can also be increased to an hr from the default of 15 secs.

Performance
A 70,000 document insert with searches in realtime has been observed on a 4 core linux system. This is a real use case of realtime-search at a user location.

How to enable it
Add the following tag to solrconfig.xml
<realtime visible="150">true</realtime>

"visible" attribute controls the number of milliseconds before a document becomes visible to search. So setting this to 0 means any document added/updated becomes visible almost immediately.