You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-user@lucene.apache.org by Jamie Johnson <je...@gmail.com> on 2012/02/25 21:39:07 UTC
Solr 4.0 Question
I just got done reading
http://www.searchworkings.org/blog/-/blogs/uwe-says%3A-is-your-reader-atomic
and was specifically interested in the following line
"Unfortunately, Apache Solr still uses this horrible code in a lot of
places, leaving us with a major piece of work undone. Major parts of
Solr’s facetting and filter caching need to be rewritten to work per
atomic segment! For those implementing plugins or other components for
Solr, SolrIndexSearcher exposes a “atomic view” of its underlying
reader via SolrIndexSearcher.getAtomicReader()."
Can someone give more details around this? Is there a JIRA to address
this in Solr? I'm assuming that this is not something new, just
something that can be improved?
Re: Solr 4.0 Question
Posted by Jamie Johnson <je...@gmail.com>.
Thanks for clarifying Yonik.
On Sat, Feb 25, 2012 at 3:57 PM, Yonik Seeley
<yo...@lucidimagination.com> wrote:
> On Sat, Feb 25, 2012 at 3:39 PM, Jamie Johnson <je...@gmail.com> wrote:
>> "Unfortunately, Apache Solr still uses this horrible code in a lot of
>> places, leaving us with a major piece of work undone. Major parts of
>> Solr’s facetting and filter caching need to be rewritten to work per
>> atomic segment! For those implementing plugins or other components for
>> Solr, SolrIndexSearcher exposes a “atomic view” of its underlying
>> reader via SolrIndexSearcher.getAtomicReader()."
>
> Some of this is just a misunderstanding, and some of it is a
> difference of opinion.
>
> Solr uses a top-level FieldCache entry for certain types of faceting,
> but it's optional. Solr can also use per-segment FieldCache entries
> when faceting. The reason we haven't removed the top-level FieldCache
> faceting is that it's faster unless you are doing near-realtime (NRT)
> search (due to the cost of merging terms across segments). Top level
> fieldcache entries are also more memory efficient for Strings as
> string values are not repeated across each segment. The right
> approach depends on the specific use-case, and Solr will continue to
> strive to have faceting algorithms optimized for both NRT and non-NRT.
>
> -Yonik
> lucenerevolution.com - Lucene/Solr Open Source Search Conference.
> Boston May 7-10
Re: Solr 4.0 Question
Posted by Yonik Seeley <yo...@lucidimagination.com>.
On Sat, Feb 25, 2012 at 3:39 PM, Jamie Johnson <je...@gmail.com> wrote:
> "Unfortunately, Apache Solr still uses this horrible code in a lot of
> places, leaving us with a major piece of work undone. Major parts of
> Solr’s facetting and filter caching need to be rewritten to work per
> atomic segment! For those implementing plugins or other components for
> Solr, SolrIndexSearcher exposes a “atomic view” of its underlying
> reader via SolrIndexSearcher.getAtomicReader()."
Some of this is just a misunderstanding, and some of it is a
difference of opinion.
Solr uses a top-level FieldCache entry for certain types of faceting,
but it's optional. Solr can also use per-segment FieldCache entries
when faceting. The reason we haven't removed the top-level FieldCache
faceting is that it's faster unless you are doing near-realtime (NRT)
search (due to the cost of merging terms across segments). Top level
fieldcache entries are also more memory efficient for Strings as
string values are not repeated across each segment. The right
approach depends on the specific use-case, and Solr will continue to
strive to have faceting algorithms optimized for both NRT and non-NRT.
-Yonik
lucenerevolution.com - Lucene/Solr Open Source Search Conference.
Boston May 7-10