Return-Path: X-Original-To: apmail-lucene-solr-user-archive@minotaur.apache.org Delivered-To: apmail-lucene-solr-user-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id C86C0F9CC for ; Wed, 3 Apr 2013 16:37:38 +0000 (UTC) Received: (qmail 66142 invoked by uid 500); 3 Apr 2013 16:35:56 -0000 Delivered-To: apmail-lucene-solr-user-archive@lucene.apache.org Received: (qmail 65575 invoked by uid 500); 3 Apr 2013 16:35:51 -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 60073 invoked by uid 99); 3 Apr 2013 16:31:41 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 03 Apr 2013 16:31:41 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of solr@elyograg.org designates 166.70.79.219 as permitted sender) Received: from [166.70.79.219] (HELO frodo.elyograg.org) (166.70.79.219) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 03 Apr 2013 16:31:37 +0000 Received: from localhost (localhost [127.0.0.1]) by frodo.elyograg.org (Postfix) with ESMTP id 541ED33F6 for ; Wed, 3 Apr 2013 10:31:16 -0600 (MDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=elyograg.org; h= content-transfer-encoding:content-type:content-type:in-reply-to :references:subject:subject:mime-version:user-agent:from:from :date:date:message-id:received:received; s=mail; t=1365006676; bh=8gDd3LNYn2DsHk/QkujjCJ3+vWpdWgBtbU/a9/1AgFQ=; b=SIfI7yPYBMJg MejRc34ZZYOrXp4jS9b+GyzARumMVQ7Z/eCibE26EXyYtQ84hDpiYq2IKS4hkhpt GxqfKpdI/Edpsn8QJH9rl1ejYyUMcbWUIlyN0uPEoofHIHMMvIRbg58/pUogNZVN keECkq7DH25Y2UP21lmLjF68dhYitZA= X-Virus-Scanned: Debian amavisd-new at frodo.elyograg.org Received: from frodo.elyograg.org ([127.0.0.1]) by localhost (frodo.elyograg.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id S9Pkh3iGWW49 for ; Wed, 3 Apr 2013 10:31:16 -0600 (MDT) Received: from [192.168.1.102] (102.int.elyograg.org [192.168.1.102]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: elyograg@elyograg.org) by frodo.elyograg.org (Postfix) with ESMTPSA id E869A24B4 for ; Wed, 3 Apr 2013 10:31:15 -0600 (MDT) Message-ID: <515C5954.7090405@elyograg.org> Date: Wed, 03 Apr 2013 10:31:16 -0600 From: Shawn Heisey User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: solr-user@lucene.apache.org Subject: Re: Filtering Search Cloud References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org On 4/1/2013 3:02 PM, Furkan KAMACI wrote: > I want to separate my cloud into two logical parts. One of them is indexer > cloud of SolrCloud. Second one is Searcher cloud of SolrCloud. > > My first question is that. Does separating my cloud system make sense about > performance improvement. Because I think that when indexing, searching make > time to response and if I separate them I get a performance improvement. On > the other hand maybe using all Solr machines as whole (I mean not > partitioning as I mentioned) SolrCloud can make a better load balancing, I > would want to learn it. > > My second question is that. Let's assume that I have separated my machines > as I mentioned. Can I filter some indexes to be searchable or not from > Searcher SolrCloud? SolrCloud gets rid of the master and slave designations. It also gets rid of the line between indexing and querying. Each shard has a replica that is designated the leader, but that has no real impact on searching and indexing, only on deciding which data to use when replicas get out of sync. In the old master-slave architecture, you indexed to the master and the updated index files were replicated to the slave. The slave did not handle the analysis for indexing, so it was usually better to send queries to slaves and let the master only do indexing. SolrCloud is very different. When you index, the documents are indexed on all replicas at about the same time. When you query, the requests are load balanced across all replicas. During normal operation, SolrCloud does not use replication at all. The replication feature is only used when a replica gets out of sync with the leader, and in that case, the entire index is replicated. Thanks, Shawn