Bill:
The technical details of the NRT implementation in Apache Solr with
RankingAlgorithm (SOLR-RA) is available here:
http://solr-ra.tgels.com/papers/NRT_Solr_RankingAlgorithm.pdf
(Some changes for Solr 3.x, but for most it is as above)
Regarding support for 4.0 trunk, should happen sometime soon.
Regards
- Nagendra Nagarajayya
http://solr-ra.tgels.org
http://rankingalgorithm.tgels.org
On 8/14/2011 7:11 PM, Bill Bell wrote:
OK,
I'll ask the elephant in the roomŠ.
What is the difference between the new UpdateHandler from Mark and the
SOLR-RA?
The UpdateHandler works with 4.0 does SOLR-RA work with 4.0 trunk?
Pros/Cons?
On 8/14/11 8:10 PM, "Nagendra Nagarajayya"<nnagaraja...@transaxtions.com>
wrote:
Naveen:
NRT with Apache Solr 3.3 and RankingAlgorithm does need a commit for a
document to become searchable. Any document that you add through update
becomes immediately searchable. So no need to commit from within your
update client code. Since there is no commit, the cache does not have
to be cleared or the old searchers closed or new searchers opened, and
warmed (error that you are facing).
Regards
- Nagendra Nagarajayya
http://solr-ra.tgels.org
http://rankingalgorithm.tgels.org
On 8/14/2011 10:37 AM, Naveen Gupta wrote:
Hi Mark/Erick/Nagendra,
I was not very confident about NRT at that point of time, when we
started
project almost 1 year ago, definitely i would try NRT and see the
performance.
The current requirement was working fine till we were using
commitWithin 10
millisecs in the XMLDocument which we were posting to SOLR.
But due to which, we were getting very poor performance (almost 3 mins
for
15,000 docs) per user. There are many paraller user committing to our
SOLR.
So we removed the commitWithin, and hence performance was much much
better.
But then we are getting this maxWarmingSearcher Error, because we are
committing separately as a curl request after once entire doc is
submitted
for indexing.
The question here is what is difference between commitWithin and commit
(apart from the fact that commit takes memory and processes and
additional
hardware usage)
Why we want it to be visible as soon as possible, since we are applying
many
business rules on top of the results (older indexes as well as new one)
and
apply different filters.
upto 5 mins is fine for us. but more than that we need to think then
other
optimizations.
We will definitely try NRT. But please tell me other options which we
can
apply in order to optimize.?
Thanks
Naveen
On Sun, Aug 14, 2011 at 9:42 PM, Erick
Erickson<erickerick...@gmail.com>wrote:
Ah, thanks, Mark... I must have been looking at the wrong JIRAs.
Erick
On Sun, Aug 14, 2011 at 10:02 AM, Mark Miller<markrmil...@gmail.com>
wrote:
On Aug 14, 2011, at 9:03 AM, Erick Erickson wrote:
You either have to go to near real time (NRT), which is under
development, but not committed to trunk yet
NRT support is committed to trunk.
- Mark Miller
lucidimagination.com
