Mailing-List: contact solr-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: solr-dev@lucene.apache.org
Received-SPF: pass (herse.apache.org: local policy)
Mime-Version: 1.0 (Apple Message framework v752.3)
In-Reply-To: <638370.15224.qm@web50304.mail.yahoo.com>
References: <638370.15224.qm@web50304.mail.yahoo.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <FFADB568-85BB-4012-9329-D96C613E15C1@ehatchersolutions.com>
Content-Transfer-Encoding: 7bit
From: Erik Hatcher <erik@ehatchersolutions.com>
Subject: Re: finer granularity of configuration
Date: Thu, 15 Feb 2007 20:59:05 -0500
To: solr-dev@lucene.apache.org


On Feb 15, 2007, at 7:59 PM, Otis Gospodnetic wrote:

> Hi,
>
> ----- Original Message ----
> From: Yonik Seeley <yonik@apache.org>
>
> On 2/15/07, Otis Gospodnetic <otis_gospodnetic@yahoo.com> wrote:
>> Sorry, this was meant for Erik (relates to some direct emails).   
>> Now everyone knows my secret desire: 1 Solr to serve N indices  
>> with the same config, just a different directory.  I'm thinking  
>> Simpy here:
>>    http://simpy-index-server/solr/search/erik/links?q=ruby
>>    http://simpy-index-server/solr/search/otis/notes?q=recipe
>>    http://simpy-index-server/solr/search/otis/links?q=cookies
>> Where each of this is really a separate Lucene index: erik's links  
>> index, otis' notes index, and otis' links index.
>
> Each user has a separate index???  While this makes for fast search
> within a single user, don't you ever need to search across all of them
> at once?
>
> OG: Most searches are going against a single user's data, so a  
> separate index works well for that.  A separate index is also good  
> to have in case something gets foobared - a lot less data to reindex.
> OG: A separate index is used for searching across all users.  This  
> index has a different structure (fields, analyzer, update rates...)
>
> OG: How hard would it be to add support for multiple indices?   
> Having 1 Solr for N indices + an "index location resolver" would, I  
> think, really allow one to scale a number of indices over a number  
> of Solr servers:
>
> client --- http://resolver/search/?q=... ---> resolves  &  
> dispatches to the right Solr server --> solrN
>
> Each Solr instance is a front end to a number of indices.  Of  
> course, the resolver could be completely internal (in-JVM).

Sounds like what we need is a tie-in to NetKernel :)

	Erik