For multi-tenant, all customers share the same words for text fields. A customer's search relevance might be useless.
Also, spelling & autosuggest recommendations come from all of the entries in a field, so the customers can see each other's words. There are other quirks in memory and cache management. And taking updates. 1 core/tenant has operational scripting problems. You'll have to write all your own ops software, there is no help. Lance On Tue, Oct 12, 2010 at 2:59 AM, Tharindu Mathew <mcclou...@gmail.com> wrote: > Basically, for a large number of users would using a single index or using a > multi core approach be better? > > On Tue, Oct 12, 2010 at 11:39 AM, Tharindu Mathew <mcclou...@gmail.com>wrote: > >> Hi everyone, >> >> I'm sort of looking in to a deployment which will support multi tenancy. >> This means that there will be 1000s of tenant domains each having 1000s of >> users. I need to figure out which approach is better for this deployment >> when using the solr server. >> >> Approach #1 - Use multi cores for each tenant and thereby use separate >> indexes for each. If necessary use filter queries with user ids for users. >> Approach #2 - Use filter queries with tenant ids to filter out results of >> different tenant domains. Similarly, as above, use user ids as needed. >> >> My concern comes on aspects of performance and security. >> >> Will using approach #1 be a killer for performance? With this many number >> of users, this setup has to scale smoothly for so many number of users. When >> the deployment potentially will have 1000s of cores, how can I prevent a >> security vulnerability appearing between cores? >> >> What are the implications of using approach #2? Will I have to constantly >> check around for code with security checks since only a single index is >> used? >> >> Any feedback for the above concerns would be really appreciated. >> >> Thanks in advance. >> >> -- >> Regards, >> >> Tharindu >> > > > > -- > Regards, > > Tharindu > -- Lance Norskog goks...@gmail.com
