We have a multi-tenant Solr deployment with a core for each user. Due to the limitations we are facing with number of cores, lazy-loading (and associated warm-up times), we are researching about consolidating several users into one core with queries limited by user-id field.
My question is about autosuggest. 1. Are there ways we can limit the autosuggest to only documents with matching ids? 2. What other SOLR operations like these which need further consideration when merging multiple indices and limiting by a field? -- Vikram On Sat, Jan 22, 2011 at 4:02 PM, Erick Erickson <erickerick...@gmail.com> wrote: > See below. > > On Wed, Jan 19, 2011 at 7:26 PM, Joscha Feth <jos...@feth.com> wrote: > >> Hello Erick, >> >> Thanks for your answer! >> >> But I question why you *require* many different indexes. [...] including >> > isolating one >> > users' >> > data from all others, [...] >> >> >> Yes, thats exactly what I am after - I need to make sure that indexes don't >> mix, as every user shall only be able to query his own data (index). >> > > well, this can also be handled by simply appending the equivalent of > +user:theuser > to each query. This solution does have some "interesting" side effects > though. > In particular if you autosuggest based on combined documents, users will see > terms NOT in documents they own. > > >> >> And even using lots of cores can be made to work if you don't pre-warm >> > newly-opened >> > cores, assuming that the response time when using "cold searchers" is >> > adequate. >> > >> >> Could you explain that further or point me to some documentation? Are you >> talking about: http://wiki.apache.org/solr/CoreAdmin#UNLOAD? if yes, LOAD >> does not seem to be implemented, yet. Or has this something to do with >> http://wiki.apache.org/solr/SolrCaching#autowarmCount only? About what >> time >> per X documents are we talking here for delay if auto warming is disabled? >> Is there more documentation about this setting? >> >> > It's the autoWarm parameter. When you open a core the first few queries that > run > on it will pay some penalty for filling caches etc. If your cores are small > enough, > then this penalty may not be noticeable to your users, in which case you can > just > not bother autowarming (see <firstSearcher> , <newSearcher>). You might also > be able to get away with having very small caches, it mostly depends on your > usage patterns. If your pattern as that a user signs on, makes one search > and > signs off, there may not be much good in having large caches. On the other > and, > if users sign on and search for hours continually, their experience may be > enhanced > by having significant caches. It all depends. > > Hopt that helps > Erick > > >> Kind regards, >> Joscha >> > -- - Vikram
