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 Rajesh Hazari <ra...@gmail.com> on 2015/06/29 20:21:02 UTC
solr suggester build issues
Solr : 4.9.x , with simple solr cloud on jetty.
JDK 1.7
num of replica : 4 , one replica for each shard
num of shards : 1
Hi All,
I have been facing below issues with solr suggester introduced in 4.7.x. Do
any one have good working solution or
buildOnCommit=true property is suggested not to use with index with more
frequent softcommits as suggested in the documentation
https://cwiki.apache.org/confluence/display/solr/Suggester
So we have disabled this (buildOnCommit=false) and started using
buildOnOptimize=true, which was not helping us to have latest document
suggestion (with frequent softcommits),
as hardly there was one optimize each day. (we have default optimize
setting in solrconfig)
So we have disabled buildOnOptimize (buildOnOptimize=false)
As suggested in the documentation, as of now, we came up with cron jobs to
build the suggester for every hour.
These jobs are doing their job, i.e, we are having the latest suggestions
available every hour, below are issues that we have this implementation.
*Issue#1* : Suggest built url i.e,
*http://$solrnode:8983/solr/collection1/suggest?suggest.build=true* if
issued to one replica of solr cloud does not build suggesters in all of the
replicas in solrcloud.
Resolution: For which we have separate cron jobs on each of the
solr instance having the build call to build the suggester, below is the
raw pictorial representation of this impl
(which is not the best implementation which has
many flaws)
*http://$solrnode:8983/solr/collection1/suggest?suggest.build=true*
* |*
* |--
suggestcron.job.sh <http://suggestcron.job.sh> (on solr1.aws.instance)*
*http://$solrnode:8983/solr/collection1/suggest?suggest.build=true*
* |*
* |--
suggestcron.job.sh <http://suggestcron.job.sh> (on solr2.aws.instance)*
* .......... similar for other solr nodes*
* We will be coming up with single script to go this for all
collection later.*
we were bit happy that we are having a updated suggester in all of the
instances, *which is not!*
*The issue#2 the suggester built on all solr nodes were not consistent as
the solr core in each solr replica have difference in max-docs and
num-docs *
*(which is quiet normal **with frequent softcommits , when updates mostly
have the same documents updated with different data, **i guess , correct me
if i'm wrong )*
when we query curl -i "http://
$solrnode:8983/solr/liveaodfuture/suggest?q=Nirvana&wt=json&indent=true"
one of the solr node returns
{
"responseHeader":{
"status":0,
"QTime":0},
"suggest":{
"AnalyzingSuggester":{
"Nirvana":{
"numFound":1,
"suggestions":[{
"term":"nirvana",
"weight":6,
"payload":""}]}},
"DictionarySuggester":{
"Nirvana":{
"numFound":0,
"suggestions":[]}}}}
/admin/luke/collection/ call status
"index":{
"numDocs":90564,
"maxDoc":94583,
"deletedDocs":4019,
.......}
while other 3 solr node returns
{
"responseHeader":{
"status":0,
"QTime":1},
"suggest":{
"AnalyzingSuggester":{
"Nirvana":{
"numFound":2,
"suggestions":[{
"term":"nirvana",
"weight":163,
"payload":""},
* {*
* "term":"nirvana cover",*
* "weight":11,*
* "payload":""}]}},*
"DictionarySuggester":{
"Nirvana":{
"numFound":0,
"suggestions":[]}}}}
/admin/luke/collection/ call status on other 3 solr nodes... which have
different maxDoc that the above solr node.
"index":{
"numDocs":90564,
"maxDoc":156760,
........}
when i check the built time for suggest directory of the collection on each
solr node have the same time
ls -lah /mnt/solrdrive/solr/cores/*/data/suggest_analyzing/*
-rw-r--r-- 1 root root 3.0M May 20 16:00
/mnt/solrdrive/solr/cores/collection1_shard1_replica3/data/suggest_analyzing/wfsta.bin
Questions:
Does the suggester built url i.e,
*http://$solrnode:8983/solr/collection1/suggest?suggest.build=true
*consider maxdocs or deleted docs also?
Does the suggester built from i.e,
*solr/collection1/suggest?suggest.build=true
*is different from buildOnCommit=true property ?
Do any one have better solution to keep the suggester current
with contents in the index with more frequent softcommits?
Does solr have any component like scheduler like cron scheduler
to schedule the suggest build and
scheduling the optimize on daily basis ?
*Thanks,*
*Rajesh**.*
RE: solr suggester build issues
Posted by "Tarala, Magesh" <MT...@bh.com>.
Sorry for the late response Rajesh. We are not in production yet. Will be performing load testing in QA next week and hope to go live end of next month.
--Magesh
-----Original Message-----
From: Rajesh Hazari [mailto:rajeshhazari@gmail.com]
Sent: Monday, June 29, 2015 2:28 PM
To: solr-user@lucene.apache.org
Subject: Re: solr suggester build issues
Thanks Tarala for sharing your solution that you have.
We have had this in our earlier discussions to separate the suggester in to a different collection, but this would have been good if we have only one collection. Till date we have to 4 collection out of which 2 are big collections with about 50 searchable files in each and these may grow in future.
So managing the suggester in different collection is not wise as they may be some time inconsistent/unavailable/down/recovering with the actual searchable collections.
How often are you building your suggester and how are you managing this?
*Thanks,*
*Rajesh**.*
On Mon, Jun 29, 2015 at 3:17 PM, Tarala, Magesh <MT...@bh.com> wrote:
> This may sound crazy, but it works. If there are better ways, all ears
> for
> it:) Not sure if this fits your use case though.
>
> We created a collection for each suggester and handling separately
> them from the "main" collection. The main collection has about 60
> fields. The .NET UI front end for search provides the ability to
> search for specific values in 10 of these fields. So, for Field A, as
> the user starts to type in the text box, I need to provide the
> suggested values. The standalone suggester for field A provides the suggested values.
>
> Here's the config in solrconfig.xml
>
> <searchComponent name="suggest" class="solr.SuggestComponent">
> <lst name="suggester">
> <str name="name">mySuggester</str>
>
> <!--
> <str name="lookupImpl">FuzzyLookupFactory</str>
> <str name="storeDir">suggester_fuzzy_dir</str>
> -->
>
> <!-- Substitute these for the two above for another "flavor" -->
> <str name="lookupImpl">AnalyzingInfixLookupFactory</str>
> <str name="indexPath">suggester_infix_dir</str>
>
> <str name="dictionaryImpl">DocumentDictionaryFactory</str>
> <str name="field">contact_suggest</str>
> <str name="weightField">5</str>
> <str name="suggestAnalyzerFieldType">suggestTypeLc</str>
> <str name="buildOnStartup">false</str>
> <str name="buildOnCommit">false</str>
> </lst>
> </searchComponent>
>
>
> Here are the relevant entries in schema.xml
>
> <!-- Field Names -->
> <field name="contact" type="string" indexed="true" stored="true"
> omitNorms="true" omitTermFreqAndPositions="true" multiValued="false"/>
> <field name="contact_suggest" type="suggestTypeLc" indexed="true"
> stored="true"/>
>
> <!-- <uniqueKey>id</uniqueKey> -->
> <uniqueKey>contact</uniqueKey>
> <defaultSearchField>contact</defaultSearchField>
>
> <copyField source="contact" dest="contact_suggest"/>
>
>
> We are keeping one shard and 2 replicas for each suggester.
>
> We have not gone to production yet, but it is working well in the test
> environment.
>
>
>
> -----Original Message-----
> From: Rajesh Hazari [mailto:rajeshhazari@gmail.com]
> Sent: Monday, June 29, 2015 1:21 PM
> To: solr-user@lucene.apache.org
> Subject: solr suggester build issues
>
> Solr : 4.9.x , with simple solr cloud on jetty.
> JDK 1.7
> num of replica : 4 , one replica for each shard num of shards : 1
>
> Hi All,
>
> I have been facing below issues with solr suggester introduced in 4.7.x.
> Do any one have good working solution or
>
> buildOnCommit=true property is suggested not to use with index with
> more frequent softcommits as suggested in the documentation
>
> https://cwiki.apache.org/confluence/display/solr/Suggester
> So we have disabled this (buildOnCommit=false) and started using
> buildOnOptimize=true, which was not helping us to have latest document
> suggestion (with frequent softcommits), as hardly there was one
> optimize each day. (we have default optimize setting in solrconfig) So
> we have disabled buildOnOptimize (buildOnOptimize=false)
>
> As suggested in the documentation, as of now, we came up with cron
> jobs to build the suggester for every hour.
> These jobs are doing their job, i.e, we are having the latest
> suggestions available every hour, below are issues that we have this implementation.
>
> *Issue#1* : Suggest built url i.e,
> *http://$solrnode:8983/solr/collection1/suggest?suggest.build=true*
> if issued to one replica of solr cloud does not build suggesters in
> all of the replicas in solrcloud.
> Resolution: For which we have separate cron jobs on each of
> the solr instance having the build call to build the suggester, below
> is the raw pictorial representation of this impl
> (which is not the best implementation
> which has many flaws)
>
>
> *http://$solrnode:8983/solr/collection1/suggest?suggest.build=true*
> * |*
> * |--
> suggestcron.job.sh <http://suggestcron.job.sh> (on
> solr1.aws.instance)*
>
>
> *http://$solrnode:8983/solr/collection1/suggest?suggest.build=true*
> * |*
> * |--
> suggestcron.job.sh <http://suggestcron.job.sh> (on solr2.aws.instance)*
> * .......... similar for other solr nodes*
> * We will be coming up with single script to go this for all
> collection later.*
>
> we were bit happy that we are having a updated suggester in all of the
> instances, *which is not!*
>
> *The issue#2 the suggester built on all solr nodes were not consistent
> as the solr core in each solr replica have difference in max-docs and
> num-docs
> * *(which is quiet normal **with frequent softcommits , when updates
> mostly have the same documents updated with different data, **i guess
> , correct me if i'm wrong )*
>
> when we query curl -i "http://
> $solrnode:8983/solr/liveaodfuture/suggest?q=Nirvana&wt=json&indent=true"
>
> one of the solr node returns
> {
> "responseHeader":{
> "status":0,
> "QTime":0},
> "suggest":{
> "AnalyzingSuggester":{
> "Nirvana":{
> "numFound":1,
> "suggestions":[{
> "term":"nirvana",
> "weight":6,
> "payload":""}]}},
> "DictionarySuggester":{
> "Nirvana":{
> "numFound":0,
> "suggestions":[]}}}}
>
> /admin/luke/collection/ call status
>
> "index":{
> "numDocs":90564,
> "maxDoc":94583,
> "deletedDocs":4019,
> .......}
>
>
> while other 3 solr node returns
>
> {
> "responseHeader":{
> "status":0,
> "QTime":1},
> "suggest":{
> "AnalyzingSuggester":{
> "Nirvana":{
> "numFound":2,
> "suggestions":[{
> "term":"nirvana",
> "weight":163,
> "payload":""},
> * {*
> * "term":"nirvana cover",*
> * "weight":11,*
> * "payload":""}]}},*
> "DictionarySuggester":{
> "Nirvana":{
> "numFound":0,
> "suggestions":[]}}}}
>
> /admin/luke/collection/ call status on other 3 solr nodes... which
> have different maxDoc that the above solr node.
>
> "index":{
> "numDocs":90564,
> "maxDoc":156760,
> ........}
>
> when i check the built time for suggest directory of the collection on
> each solr node have the same time
>
> ls -lah /mnt/solrdrive/solr/cores/*/data/suggest_analyzing/*
> -rw-r--r-- 1 root root 3.0M May 20 16:00
> /mnt/solrdrive/solr/cores/collection1_shard1_replica3/data/suggest_ana
> lyzing/wfsta.bin
>
> Questions:
> Does the suggester built url i.e, *http://
> $solrnode:8983/solr/collection1/suggest?suggest.build=true
> *consider maxdocs or deleted docs also?
> Does the suggester built from i.e,
> *solr/collection1/suggest?suggest.build=true
> *is different from buildOnCommit=true property ?
> Do any one have better solution to keep the suggester
> current with contents in the index with more frequent softcommits?
>
> Does solr have any component like scheduler like cron
> scheduler to schedule the suggest build and
> scheduling the optimize on daily basis ?
>
>
> *Thanks,*
> *Rajesh**.*
>
Re: solr suggester build issues
Posted by Rajesh Hazari <ra...@gmail.com>.
Thanks Tarala for sharing your solution that you have.
We have had this in our earlier discussions to separate the suggester in to
a different collection, but this would have been good if we have only one
collection. Till date we have to 4 collection out of which 2 are big
collections with about 50 searchable files in each and these may grow in
future.
So managing the suggester in different collection is not wise as they may
be some time inconsistent/unavailable/down/recovering with the actual
searchable collections.
How often are you building your suggester and how are you managing this?
*Thanks,*
*Rajesh**.*
On Mon, Jun 29, 2015 at 3:17 PM, Tarala, Magesh <MT...@bh.com> wrote:
> This may sound crazy, but it works. If there are better ways, all ears for
> it:) Not sure if this fits your use case though.
>
> We created a collection for each suggester and handling separately them
> from the "main" collection. The main collection has about 60 fields. The
> .NET UI front end for search provides the ability to search for specific
> values in 10 of these fields. So, for Field A, as the user starts to type
> in the text box, I need to provide the suggested values. The standalone
> suggester for field A provides the suggested values.
>
> Here's the config in solrconfig.xml
>
> <searchComponent name="suggest" class="solr.SuggestComponent">
> <lst name="suggester">
> <str name="name">mySuggester</str>
>
> <!--
> <str name="lookupImpl">FuzzyLookupFactory</str>
> <str name="storeDir">suggester_fuzzy_dir</str>
> -->
>
> <!-- Substitute these for the two above for another "flavor" -->
> <str name="lookupImpl">AnalyzingInfixLookupFactory</str>
> <str name="indexPath">suggester_infix_dir</str>
>
> <str name="dictionaryImpl">DocumentDictionaryFactory</str>
> <str name="field">contact_suggest</str>
> <str name="weightField">5</str>
> <str name="suggestAnalyzerFieldType">suggestTypeLc</str>
> <str name="buildOnStartup">false</str>
> <str name="buildOnCommit">false</str>
> </lst>
> </searchComponent>
>
>
> Here are the relevant entries in schema.xml
>
> <!-- Field Names -->
> <field name="contact" type="string" indexed="true" stored="true"
> omitNorms="true" omitTermFreqAndPositions="true" multiValued="false"/>
> <field name="contact_suggest" type="suggestTypeLc" indexed="true"
> stored="true"/>
>
> <!-- <uniqueKey>id</uniqueKey> -->
> <uniqueKey>contact</uniqueKey>
> <defaultSearchField>contact</defaultSearchField>
>
> <copyField source="contact" dest="contact_suggest"/>
>
>
> We are keeping one shard and 2 replicas for each suggester.
>
> We have not gone to production yet, but it is working well in the test
> environment.
>
>
>
> -----Original Message-----
> From: Rajesh Hazari [mailto:rajeshhazari@gmail.com]
> Sent: Monday, June 29, 2015 1:21 PM
> To: solr-user@lucene.apache.org
> Subject: solr suggester build issues
>
> Solr : 4.9.x , with simple solr cloud on jetty.
> JDK 1.7
> num of replica : 4 , one replica for each shard num of shards : 1
>
> Hi All,
>
> I have been facing below issues with solr suggester introduced in 4.7.x.
> Do any one have good working solution or
>
> buildOnCommit=true property is suggested not to use with index with more
> frequent softcommits as suggested in the documentation
> https://cwiki.apache.org/confluence/display/solr/Suggester
> So we have disabled this (buildOnCommit=false) and started using
> buildOnOptimize=true, which was not helping us to have latest document
> suggestion (with frequent softcommits), as hardly there was one optimize
> each day. (we have default optimize setting in solrconfig) So we have
> disabled buildOnOptimize (buildOnOptimize=false)
>
> As suggested in the documentation, as of now, we came up with cron jobs to
> build the suggester for every hour.
> These jobs are doing their job, i.e, we are having the latest suggestions
> available every hour, below are issues that we have this implementation.
>
> *Issue#1* : Suggest built url i.e,
> *http://$solrnode:8983/solr/collection1/suggest?suggest.build=true* if
> issued to one replica of solr cloud does not build suggesters in all of the
> replicas in solrcloud.
> Resolution: For which we have separate cron jobs on each of the
> solr instance having the build call to build the suggester, below is the
> raw pictorial representation of this impl
> (which is not the best implementation which
> has many flaws)
>
>
> *http://$solrnode:8983/solr/collection1/suggest?suggest.build=true*
> * |*
> * |--
> suggestcron.job.sh <http://suggestcron.job.sh> (on solr1.aws.instance)*
>
>
> *http://$solrnode:8983/solr/collection1/suggest?suggest.build=true*
> * |*
> * |--
> suggestcron.job.sh <http://suggestcron.job.sh> (on solr2.aws.instance)*
> * .......... similar for other solr nodes*
> * We will be coming up with single script to go this for all
> collection later.*
>
> we were bit happy that we are having a updated suggester in all of the
> instances, *which is not!*
>
> *The issue#2 the suggester built on all solr nodes were not consistent as
> the solr core in each solr replica have difference in max-docs and num-docs
> * *(which is quiet normal **with frequent softcommits , when updates mostly
> have the same documents updated with different data, **i guess , correct me
> if i'm wrong )*
>
> when we query curl -i "http://
> $solrnode:8983/solr/liveaodfuture/suggest?q=Nirvana&wt=json&indent=true"
>
> one of the solr node returns
> {
> "responseHeader":{
> "status":0,
> "QTime":0},
> "suggest":{
> "AnalyzingSuggester":{
> "Nirvana":{
> "numFound":1,
> "suggestions":[{
> "term":"nirvana",
> "weight":6,
> "payload":""}]}},
> "DictionarySuggester":{
> "Nirvana":{
> "numFound":0,
> "suggestions":[]}}}}
>
> /admin/luke/collection/ call status
>
> "index":{
> "numDocs":90564,
> "maxDoc":94583,
> "deletedDocs":4019,
> .......}
>
>
> while other 3 solr node returns
>
> {
> "responseHeader":{
> "status":0,
> "QTime":1},
> "suggest":{
> "AnalyzingSuggester":{
> "Nirvana":{
> "numFound":2,
> "suggestions":[{
> "term":"nirvana",
> "weight":163,
> "payload":""},
> * {*
> * "term":"nirvana cover",*
> * "weight":11,*
> * "payload":""}]}},*
> "DictionarySuggester":{
> "Nirvana":{
> "numFound":0,
> "suggestions":[]}}}}
>
> /admin/luke/collection/ call status on other 3 solr nodes... which have
> different maxDoc that the above solr node.
>
> "index":{
> "numDocs":90564,
> "maxDoc":156760,
> ........}
>
> when i check the built time for suggest directory of the collection on
> each solr node have the same time
>
> ls -lah /mnt/solrdrive/solr/cores/*/data/suggest_analyzing/*
> -rw-r--r-- 1 root root 3.0M May 20 16:00
> /mnt/solrdrive/solr/cores/collection1_shard1_replica3/data/suggest_analyzing/wfsta.bin
>
> Questions:
> Does the suggester built url i.e, *http://
> $solrnode:8983/solr/collection1/suggest?suggest.build=true
> *consider maxdocs or deleted docs also?
> Does the suggester built from i.e,
> *solr/collection1/suggest?suggest.build=true
> *is different from buildOnCommit=true property ?
> Do any one have better solution to keep the suggester current
> with contents in the index with more frequent softcommits?
>
> Does solr have any component like scheduler like cron scheduler
> to schedule the suggest build and
> scheduling the optimize on daily basis ?
>
>
> *Thanks,*
> *Rajesh**.*
>
RE: solr suggester build issues
Posted by "Tarala, Magesh" <MT...@bh.com>.
This may sound crazy, but it works. If there are better ways, all ears for it:) Not sure if this fits your use case though.
We created a collection for each suggester and handling separately them from the "main" collection. The main collection has about 60 fields. The .NET UI front end for search provides the ability to search for specific values in 10 of these fields. So, for Field A, as the user starts to type in the text box, I need to provide the suggested values. The standalone suggester for field A provides the suggested values.
Here's the config in solrconfig.xml
<searchComponent name="suggest" class="solr.SuggestComponent">
<lst name="suggester">
<str name="name">mySuggester</str>
<!--
<str name="lookupImpl">FuzzyLookupFactory</str>
<str name="storeDir">suggester_fuzzy_dir</str>
-->
<!-- Substitute these for the two above for another "flavor" -->
<str name="lookupImpl">AnalyzingInfixLookupFactory</str>
<str name="indexPath">suggester_infix_dir</str>
<str name="dictionaryImpl">DocumentDictionaryFactory</str>
<str name="field">contact_suggest</str>
<str name="weightField">5</str>
<str name="suggestAnalyzerFieldType">suggestTypeLc</str>
<str name="buildOnStartup">false</str>
<str name="buildOnCommit">false</str>
</lst>
</searchComponent>
Here are the relevant entries in schema.xml
<!-- Field Names -->
<field name="contact" type="string" indexed="true" stored="true" omitNorms="true" omitTermFreqAndPositions="true" multiValued="false"/>
<field name="contact_suggest" type="suggestTypeLc" indexed="true" stored="true"/>
<!-- <uniqueKey>id</uniqueKey> -->
<uniqueKey>contact</uniqueKey>
<defaultSearchField>contact</defaultSearchField>
<copyField source="contact" dest="contact_suggest"/>
We are keeping one shard and 2 replicas for each suggester.
We have not gone to production yet, but it is working well in the test environment.
-----Original Message-----
From: Rajesh Hazari [mailto:rajeshhazari@gmail.com]
Sent: Monday, June 29, 2015 1:21 PM
To: solr-user@lucene.apache.org
Subject: solr suggester build issues
Solr : 4.9.x , with simple solr cloud on jetty.
JDK 1.7
num of replica : 4 , one replica for each shard num of shards : 1
Hi All,
I have been facing below issues with solr suggester introduced in 4.7.x. Do any one have good working solution or
buildOnCommit=true property is suggested not to use with index with more frequent softcommits as suggested in the documentation
https://cwiki.apache.org/confluence/display/solr/Suggester
So we have disabled this (buildOnCommit=false) and started using buildOnOptimize=true, which was not helping us to have latest document suggestion (with frequent softcommits), as hardly there was one optimize each day. (we have default optimize setting in solrconfig) So we have disabled buildOnOptimize (buildOnOptimize=false)
As suggested in the documentation, as of now, we came up with cron jobs to build the suggester for every hour.
These jobs are doing their job, i.e, we are having the latest suggestions available every hour, below are issues that we have this implementation.
*Issue#1* : Suggest built url i.e,
*http://$solrnode:8983/solr/collection1/suggest?suggest.build=true* if issued to one replica of solr cloud does not build suggesters in all of the replicas in solrcloud.
Resolution: For which we have separate cron jobs on each of the solr instance having the build call to build the suggester, below is the raw pictorial representation of this impl
(which is not the best implementation which has many flaws)
*http://$solrnode:8983/solr/collection1/suggest?suggest.build=true*
* |*
* |--
suggestcron.job.sh <http://suggestcron.job.sh> (on solr1.aws.instance)*
*http://$solrnode:8983/solr/collection1/suggest?suggest.build=true*
* |*
* |--
suggestcron.job.sh <http://suggestcron.job.sh> (on solr2.aws.instance)*
* .......... similar for other solr nodes*
* We will be coming up with single script to go this for all
collection later.*
we were bit happy that we are having a updated suggester in all of the instances, *which is not!*
*The issue#2 the suggester built on all solr nodes were not consistent as the solr core in each solr replica have difference in max-docs and num-docs * *(which is quiet normal **with frequent softcommits , when updates mostly have the same documents updated with different data, **i guess , correct me if i'm wrong )*
when we query curl -i "http://
$solrnode:8983/solr/liveaodfuture/suggest?q=Nirvana&wt=json&indent=true"
one of the solr node returns
{
"responseHeader":{
"status":0,
"QTime":0},
"suggest":{
"AnalyzingSuggester":{
"Nirvana":{
"numFound":1,
"suggestions":[{
"term":"nirvana",
"weight":6,
"payload":""}]}},
"DictionarySuggester":{
"Nirvana":{
"numFound":0,
"suggestions":[]}}}}
/admin/luke/collection/ call status
"index":{
"numDocs":90564,
"maxDoc":94583,
"deletedDocs":4019,
.......}
while other 3 solr node returns
{
"responseHeader":{
"status":0,
"QTime":1},
"suggest":{
"AnalyzingSuggester":{
"Nirvana":{
"numFound":2,
"suggestions":[{
"term":"nirvana",
"weight":163,
"payload":""},
* {*
* "term":"nirvana cover",*
* "weight":11,*
* "payload":""}]}},*
"DictionarySuggester":{
"Nirvana":{
"numFound":0,
"suggestions":[]}}}}
/admin/luke/collection/ call status on other 3 solr nodes... which have different maxDoc that the above solr node.
"index":{
"numDocs":90564,
"maxDoc":156760,
........}
when i check the built time for suggest directory of the collection on each solr node have the same time
ls -lah /mnt/solrdrive/solr/cores/*/data/suggest_analyzing/*
-rw-r--r-- 1 root root 3.0M May 20 16:00 /mnt/solrdrive/solr/cores/collection1_shard1_replica3/data/suggest_analyzing/wfsta.bin
Questions:
Does the suggester built url i.e, *http://$solrnode:8983/solr/collection1/suggest?suggest.build=true
*consider maxdocs or deleted docs also?
Does the suggester built from i.e, *solr/collection1/suggest?suggest.build=true
*is different from buildOnCommit=true property ?
Do any one have better solution to keep the suggester current with contents in the index with more frequent softcommits?
Does solr have any component like scheduler like cron scheduler to schedule the suggest build and
scheduling the optimize on daily basis ?
*Thanks,*
*Rajesh**.*