Return-Path: Delivered-To: apmail-lucene-solr-user-archive@minotaur.apache.org Received: (qmail 34143 invoked from network); 12 Oct 2010 21:15:09 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 12 Oct 2010 21:15:09 -0000 Received: (qmail 8731 invoked by uid 500); 12 Oct 2010 21:15:06 -0000 Delivered-To: apmail-lucene-solr-user-archive@lucene.apache.org Received: (qmail 8693 invoked by uid 500); 12 Oct 2010 21:15:06 -0000 Mailing-List: contact solr-user-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: solr-user@lucene.apache.org Delivered-To: mailing list solr-user@lucene.apache.org Received: (qmail 8685 invoked by uid 99); 12 Oct 2010 21:15:05 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 12 Oct 2010 21:15:05 +0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of goksron@gmail.com designates 74.125.82.176 as permitted sender) Received: from [74.125.82.176] (HELO mail-wy0-f176.google.com) (74.125.82.176) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 12 Oct 2010 21:14:58 +0000 Received: by wyb38 with SMTP id 38so4666504wyb.35 for ; Tue, 12 Oct 2010 14:14:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=RDTq3bbCpB04FjW1tE+zm0UiA++3aCfZB8KDe7TYzBg=; b=AjXvjJgYijXGI/r8gzHkWp13dFcTxJwQuF5I4c07vXzWXVdC6n4m8mRazMaBmutMmN BwTnthClQAMj/0C6K5+1uPES01nf3r7jylYhkm5VnolylgePLWYjl3JvPuVjt2A/nR17 vXj6ayVZpv+xeZk5+O+bQxDhalDukPhx7mit8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=kgD+I2Fg9rNArqKBkN6+UoX7t1XJStyGOGNWpBTYNjnzCGao/kaeNNsTbOe2nckaTB k3hiZ0ON4n0glUFQCRDqg8MvjQdyJkf2PG+w27aymDp+n/D7pTa0X6oNYjCJkYf8wWtE i3sIOONFiVHlVA4sqDaeNmoXk/jIbuUbmE2V4= MIME-Version: 1.0 Received: by 10.216.54.73 with SMTP id h51mr362283wec.100.1286918077938; Tue, 12 Oct 2010 14:14:37 -0700 (PDT) Received: by 10.216.160.78 with HTTP; Tue, 12 Oct 2010 14:14:37 -0700 (PDT) In-Reply-To: References: Date: Tue, 12 Oct 2010 14:14:37 -0700 Message-ID: Subject: Re: multi cores vs filter queries for a multi tenant deployment From: Lance Norskog To: solr-user@lucene.apache.org Content-Type: text/plain; charset=UTF-8 X-Virus-Checked: Checked by ClamAV on apache.org 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 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 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 goksron@gmail.com