The Distributed Search feature assumes that a document only exists in one code. Updating a doc in a small core will fail because it may be found twice.
If you are only updating a popularity score, and only need it for boosting (but not for searching on a value), there is a feature called the ExternalFileField: http://www.lucidimagination.com/search/document/CDRG_ch04_4.4.4?q=ExternalFileField http://lucene.apache.org/solr/api/org/apache/solr/schema/ExternalFileField.html On Sun, Jun 6, 2010 at 10:26 PM, Andy <angelf...@yahoo.com> wrote: > Yonik, > > Is there any documentation where I can read more about the big core + small > core setup? > > One issue for me is that I don't just add new documents. Many of the changes > is to update existing documents, such as updating the popularity score of the > documents. Would the big core + small core strategy still work in this case? > If not, is there any other way to mitigate the cache re-building problem of > facet search? > > --- On Sun, 6/6/10, Yonik Seeley <yo...@lucidimagination.com> wrote: > >> From: Yonik Seeley <yo...@lucidimagination.com> >> Subject: Re: Faceted Search Slows Down as index gets larger >> To: solr-user@lucene.apache.org >> Date: Sunday, June 6, 2010, 1:54 PM >> On Sun, Jun 6, 2010 at 1:12 PM, >> Furkan Kuru <furkank...@gmail.com> >> wrote: >> > We try to provide real-time search. So the index is >> changing almost in every >> > minute. >> > >> > We commit for every 100 documents received. >> > >> > The facet search is executed every 5 mins. >> >> OK, that's the problem - pretty much every facet search is >> rebuilding >> the facet cache, which takes most of the time (and facet.fc >> is more >> expensive than facet.enum in this regard). >> >> One strategy is to use distributed search... have some big >> cores that >> don't change often, and then small cores for the new stuff >> that >> changes rapidly. >> >> -Yonik >> http://www.lucidimagination.com >> > > > > -- Lance Norskog goks...@gmail.com
