Return-Path: Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: (qmail 5116 invoked from network); 16 Feb 2011 08:26:45 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 16 Feb 2011 08:26:45 -0000 Received: (qmail 12573 invoked by uid 500); 16 Feb 2011 08:26:43 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 12394 invoked by uid 500); 16 Feb 2011 08:26:40 -0000 Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@cassandra.apache.org Delivered-To: mailing list user@cassandra.apache.org Received: (qmail 12386 invoked by uid 99); 16 Feb 2011 08:26:40 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 16 Feb 2011 08:26:40 +0000 X-ASF-Spam-Status: No, hits=0.0 required=5.0 tests=FREEMAIL_FROM,SPF_HELO_PASS,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL,UNPARSEABLE_RELAY X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of gcdcu-cassandra-user-1@m.gmane.org designates 80.91.229.12 as permitted sender) Received: from [80.91.229.12] (HELO lo.gmane.org) (80.91.229.12) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 16 Feb 2011 08:26:34 +0000 Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1Ppci9-0000Nh-Lu for user@cassandra.apache.org; Wed, 16 Feb 2011 09:26:09 +0100 Received: from rev-89-111-19-52.deac.net ([rev-89-111-19-52.deac.net]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 16 Feb 2011 09:26:09 +0100 Received: from oleganas by rev-89-111-19-52.deac.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 16 Feb 2011 09:26:09 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: user@cassandra.apache.org From: Oleg Anastasyev Subject: Re: Coordinator node Date: Wed, 16 Feb 2011 08:25:56 +0000 (UTC) Lines: 31 Message-ID: References:

Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: sea.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 89.111.19.52 (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101206 Ubuntu/10.10 (maverick) Firefox/3.6.13) A J gmail.com> writes: > > > Makes sense ! Thanks. > Just a quick follow-up: > Now I understand the write is not made to coordinator (unless it is part of the replica for that key). But does the write column traffic 'flow' through the coordinator node. For a 2G column write, will I see 2G network traffic on the coordinator node or just a few bytes of traffic on the co-ordinator of it reading the key and talking to nodes/client etc ? Yes, if you talk to random (AKA coordinator) node first - all 2G traffic will flow to it first and then forwarded to natural nodes (those owning replicas of a row to be written). If you want to avoid extra traffic, you should determine natural nodes of the row and send your write directly to one of natural nodes (i.e. one of natural nodes became coordinator). This natural coordinator node will accept write locally and submit write to other replicas in parallel. If your client is written in java this can be implemented relatively easy. Look at TokenMetadata.ringIterator(). If you have no requirement on using thrift interface of cassandra, it could be more efficient to write using StorageProxy interface. The latter plays a local coordinator role, so it talks directly to all replicas, so these 2G will be passed directly from your client to all row replicas. > > This will be a factor for us. So need to make sure exactly.