Thanks for the responses. I guess my specific question is if I had something which was dependent on the mapping between lucene document ids and some object primary key so i could pull in external data from another data source without a constant reindex, how would this get affected by soft and hard commits? I'd prefer not to have to rebuild this mapping from scratch on each soft or even hard commits if possible since those seem to happen frequently.
Also can you explain why and how per segment caches are used and how at the client of lucene layer one gets access or knows about this? I always thought segments were an implementation detail where they get merged on optimize etc so wouldn't that affect clients depending on segment level stuff? Or what am I missing? Thanks again! Amit On Jul 7, 2012 9:22 AM, "Andy" <angelf...@yahoo.com> wrote: > So If I want to use multi-value facet with NRT I'd need to convert the > cache to per-segment? How do I do that? > > Thanks. > > > ________________________________ > From: Jason Rutherglen <jason.rutherg...@gmail.com> > To: solr-user@lucene.apache.org > Sent: Saturday, July 7, 2012 11:32 AM > Subject: Re: Nrt and caching > > The field caches are per-segment, which are used for sorting and basic > [slower] facets. The result set, document, filter, and multi-value facet > caches are [in Solr] per-multi-segment. > > Of these, the document, filter, and multi-value facet caches could be > converted to be [performant] per-segment, as with some other Apache > licensed Lucene based search engines. > > On Sat, Jul 7, 2012 at 10:42 AM, Yonik Seeley <yo...@lucidimagination.com > >wrote: > > > On Sat, Jul 7, 2012 at 9:59 AM, Jason Rutherglen > > <jason.rutherg...@gmail.com> wrote: > > > Currently the caches are stored per-multiple-segments, meaning after > each > > > 'soft' commit, the cache(s) will be purged. > > > > Depends which caches. Some caches are per-segment, and some caches > > are top level. > > It's also a trade-off... for some things, per-segment data structures > > would indeed turn around quicker on a reopen, but every query would be > > slower for it. > > > > -Yonik > > http://lucidimagination.com > >
