Short-circuit attempt. Why put 3 shards on a single server in the first place? If you are working with large index and need to break it into smaller shards, break it in shards where each shard fully utilizes the server it is on.
Other than my thought above, I think you hit the main differences below. The only other thing I'd add is that multi-core Solr is not one's only option - servlet containers with Solr homes defined via JNDI is another route. I've used this with a lot of success with Jetty (piece of cake to configure and works beautifully). Otis -- Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch ----- Original Message ---- > From: Jeremy Hinegardner <[EMAIL PROTECTED]> > To: solr-user@lucene.apache.org > Sent: Monday, June 16, 2008 10:42:25 PM > Subject: multicore vs. multiple instances > > I'm sitting here looking over some ideas and one thing just occurred to > me, what would be the benefits of using a MultiCore approache for > sharding vs. multiple instances of solr? > > That is, say I wanted to have 3 shards on a single piece of hardware, > what would be the advantages / disadvantages of using 1 instance of Solr > with 3 cores, vs 3 instances of Solr. In the latter case, with the > additional thought of each in its own servlet container, or each as a > different webapp inside a single servlet container. > > A few comparison I can think of right now are: > > * 1 JVM in multicore vs. 3 in multi-instances, with 3 servlet > containers > * future possibility of dynamically allocating and loading of > additional cores in multicore > * snapshotting with MultiCore? I'm assuming that will just work, but > I haven't tested it yet. > * configuration may be the easiest and most maintainable with multicore ? > > Any other thoughts people have on the subject? What considerations > would you use to decide between multicore vs. multiple instances ? > > enjoy, > > -jeremy > > -- > ======================================================================== > Jeremy Hinegardner [EMAIL PROTECTED]
