lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitry Kan <solrexp...@gmail.com>
Subject Re: {soft}Commit and cache flusing
Date Tue, 01 Oct 2013 17:36:49 GMT
Thanks a lot Shawn for an exhaustive reply!

Regards,
Dmitry


On Tue, Oct 1, 2013 at 5:37 PM, Shawn Heisey <solr@elyograg.org> wrote:

> On 10/1/2013 2:48 AM, Dmitry Kan wrote:
> > This is a minor thing, perhaps, but thought to ask / share:
> >
> > if there are no modifications to an index and a softCommit or hardCommit
> > issued, then solr flushes the cache.
>
> Any time you do a commit that opens a new Searcher object
> (openSearcher=true, which is required if you want index changes to be
> visible to people making queries), the caches are invalidated.  This is
> because the layout of the index (and therefore the Lucene internal IDs)
> can completely change with *any* commit/merge, and there is no easy and
> reliable way to determine when the those numbers have NOT changed.
>
> If you have warming queries configured, those happen on the new
> searcher, populating the new cache.  If you have cache autoWarming
> configured, then keys from the old caches are re-queried against the new
> index and used to populate the new cache.
>
> I do not understand deep Lucene internals, but what I've seen come
> through Jira activity and commits over the last year or two has been a
> strong move towards per-segment thinking instead of whole-index
> thinking.  If this idea becomes applicable to all aspects of Lucene,
> then perhaps Solr caches can also become per-segment, and will not need
> to be completely invalidated except in the case of a major merge or
> forceMerge.
>
> Thanks,
> Shawn
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message