lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrea Gazzarini <>
Subject Re: Index and query time suggester behavior in a SolrCloud environment
Date Thu, 20 Apr 2017 10:57:51 GMT
Hi Shalin,
many thanks for your response. This is my scenario:

  * I build my index once in a day, it could be a delta or a full
    re-index.In any case, that takes some time;
  * I have an auto-commit (hard, no soft-commits) set to a given period
    and during the indexing cycle, several hard commits are executed. So
    the buildOnCommit (I guess) it's not an option because it will
    rebuild that suggest index several times.

But I have a doubt on the second point: the reference guide says:

/"Use buildOnCommit to rebuild the dictionary with every soft-commit"/

As I said, I have no soft-commits only hard-commits: does the rebuild 
happen after hard commits (with buildOnCommit=true)?

The other option, buildOnOptimize, makes me curious: in the scenario 
above, let's say documents are indexed / deleted every morning at 4am, 
in a window that takes 1 max 3 hours, how can I build the suggest index 
(more or less) just after that window? I'm ok if the build happens after 
a reasonable delay (e.g. 1, max 2 hours)

Many thanks,

On 20/04/17 11:11, Shalin Shekhar Mangar wrote:
> Comments inline:
> On Wed, Apr 19, 2017 at 2:46 PM, Andrea Gazzarini <> wrote:
>> Hi,
>> any help out there?
>> BTW I forgot the Solr version: 6.5.0
>> Thanks,
>> Andrea
>> On 18/04/17 11:45, Andrea Gazzarini wrote:
>>> Hi,
>>> I have a project, with SolrCloud, where I'm going to use the Suggester
>>> component (BlendedInfixLookupFactory with DocumentDictionaryFactory).
>>> Some info:
>>>    * I will have a suggest-only collection, with no NRT requirements
>>>      (indexes will be updated with a daily frequency)
>>>    * I'm not yet sure about the replication factor (I have to do some
>>>      checks)
>>>    * I'm using Solrj on the client side
>>> After reading some documentation I have a couple of doubts:
>>>    * how the ** command is working? Can I issue this
>>>      command towards just one node, and have that node forward the
>>>      request to the other nodes (so each of them can build its own
>>>      suggester index portion)?
> The only builds locally in the node to which you sent
> the request. This makes it a bit tricky because if you send that
> command with just the collection name, it will be resolved to a local
> core and executed there. The safest/easiest way is to set
> buildOnCommit or buildOnOptimize in the suggester configuration.
>>>    * how things are working at query time? Can I use send a request
>>>      with only suggest.q=... to my /suggest request handler and get
>>>      back distributed suggestions?
> The SuggestComponent works in distributed mode and it will request and
> merge results from all shards.
>>> Thanks in advance
>>> Andrea

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