You can also easily abuse shards to query multiple cores that share parts of 
the schema. This way you have isolation with the ability to query them all. 
The same can, of course, also be achieved using a sinlge index with a simple 
field identying the application and using fq on that one.

> Yes, you're right, from now on when I say that, I'll say "except
> shards". It is true.
> 
> My understanding is that shards functionality's intended use case is for
> when your index is so large that you want to split it up for
> performance. I think it works pretty well for that, with some
> limitations as you mention.
> 
>  From reading the list, my impression is that when people try to use
> shards to solve some _other_ problem, they generally run into problems.
> But maybe that's just because the people with the problems are the ones
> who appear on the list?
> 
> My personal advice is still to try and put everything together in one
> big index, Solr will give you the least trouble with that, it's what
> Solr "likes" to do best;  move to shards certainly if your index is so
> large that moving to shards will give you performance advantage you
> need, that's what they're for; be very cautious moving to shards for
> other challenges that 'one big index' is giving you that you're thinking
> shards will solve. Shards is, as I understand it, _not_ intended as a
> general purpose "federation" function, it's specifically intended to
> split an index accross multiple hosts for performance.
> 
> Jonathan
> 
> On 2/16/2011 4:37 PM, Bob Sandiford wrote:
> > Hmmm.  Maybe I'm not understanding what you're getting at, Jonathan, when
> > you say 'There is no good way in Solr to run a query across multiple
> > Solr indexes'.
> > 
> > What about the 'shards' parameter?  That allows searching across multiple
> > cores in the same instance, or shards across multiple instances.
> > 
> > There are certainly implications here (like Relevance not being
> > consistent across cores / shards), but it works pretty well for us...
> > 
> > Thanks!
> > 
> > Bob Sandiford | Lead Software Engineer | SirsiDynix
> > P: 800.288.8020 X6943 | bob.sandif...@sirsidynix.com
> > www.sirsidynix.com
> > 
> >> -----Original Message-----
> >> From: Jonathan Rochkind [mailto:rochk...@jhu.edu]
> >> Sent: Wednesday, February 16, 2011 4:09 PM
> >> To: solr-user@lucene.apache.org
> >> Cc: Thumuluri, Sai
> >> Subject: Re: Solr multi cores or not
> >> 
> >> Solr multi-core essentially just lets you run multiple seperate
> >> distinct
> >> Solr indexes in the same running Solr instance.
> >> 
> >> It does NOT let you run queries accross multiple cores at once. The
> >> cores are just like completely seperate Solr indexes, they are just
> >> conveniently running in the same Solr instance. (Which can be easier
> >> and
> >> more compact to set up than actually setting up seperate Solr
> >> instances.
> >> And they can share some config more easily. And it _may_ have
> >> implications on JVM usage, not sure).
> >> 
> >> There is no good way in Solr to run a query accross multiple Solr
> >> indexes, whether they are multi-core or single cores in seperate Solr
> >> doesn't matter.
> >> 
> >> Your first approach should be to try and put all the data in one Solr
> >> index. (one Solr 'core').
> >> 
> >> Jonathan
> >> 
> >> On 2/16/2011 3:45 PM, Thumuluri, Sai wrote:
> >>> Hi,
> >>> 
> >>> I have a need to index multiple applications using Solr, I also have
> >> 
> >> the
> >> 
> >>> need to share indexes or run a search query across these application
> >>> indexes. Is solr multi-core - the way to go?  My server config is
> >>> 2virtual CPUs @ 1.8 GHz and has about 32GB of memory. What is the
> >>> recommendation?
> >>> 
> >>> Thanks,
> >>> Sai Thumuluri

Reply via email to