Return-Path: X-Original-To: apmail-cassandra-user-archive@www.apache.org Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id E4E4010B88 for ; Thu, 19 Dec 2013 08:39:12 +0000 (UTC) Received: (qmail 19486 invoked by uid 500); 19 Dec 2013 08:39:08 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 19372 invoked by uid 500); 19 Dec 2013 08:39:08 -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 19363 invoked by uid 99); 19 Dec 2013 08:39:06 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 19 Dec 2013 08:39:06 +0000 X-ASF-Spam-Status: No, hits=2.2 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of sylvain@datastax.com designates 209.85.192.171 as permitted sender) Received: from [209.85.192.171] (HELO mail-pd0-f171.google.com) (209.85.192.171) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 19 Dec 2013 08:39:01 +0000 Received: by mail-pd0-f171.google.com with SMTP id z10so825610pdj.30 for ; Thu, 19 Dec 2013 00:38:40 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=Li3FNt4GmiA2xF6hTMP9SgujggCNP60TFjq8jVD0kg8=; b=Wf99RescjXyVDnpCj2u5fRJXSuhumvh/rBLwl+JRQdMB19gpqENxlbqlMtS6dGTUka Ndx2/77UzmHgx/mjG+dLR0nabaAUbNBdGpNUVIxzqRYOZy5t3Ie3VzYAGHYNMD2tlCw1 s44b1WzTsWykW3JAUO50xhBVLHaSIdHv0rxP+LmaizIFWgZjRPrk0EuIk8bi22BY3r2C 4Sjpm9TB3KgVI364Iqw+73SFcsIXDd91yMio7iDNls76LFVXWL5FzRRB5fJm3FJER3hw UL8a9sbdtaEvjlNQm0GVMkDcJJcbVeQhT9BeD5Bv1xCFta4G1iiXvdG6Wb72MeNu6bLE elsg== X-Gm-Message-State: ALoCoQkOyFtvtKWWMpwmpL8V1PmVM0nmgzWR7h16Lrd8wB3XhzmfXOx/RaUx7qe08GMZ6cjFYnn7 MIME-Version: 1.0 X-Received: by 10.66.154.75 with SMTP id vm11mr293593pab.124.1387442320604; Thu, 19 Dec 2013 00:38:40 -0800 (PST) Received: by 10.68.23.105 with HTTP; Thu, 19 Dec 2013 00:38:40 -0800 (PST) In-Reply-To: References: Date: Thu, 19 Dec 2013 09:38:40 +0100 Message-ID: Subject: Re: Setting up Cassandra to store on a specific node and not replicate From: Sylvain Lebresne To: "user@cassandra.apache.org" Content-Type: multipart/alternative; boundary=047d7b6d907eaa919104eddf16e5 X-Virus-Checked: Checked by ClamAV on apache.org --047d7b6d907eaa919104eddf16e5 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Dec 18, 2013 at 7:31 PM, Robert Coli wrote: > On Wed, Dec 18, 2013 at 2:44 AM, Sylvain Lebresne wrote: > >> As Janne said, you could still have hint being written by other nodes if >> the one storage node is dead, but you can use the system >> property cassandra.maxHintTTL to 0 to disable hints. >> > > If one uses a Token Aware client with RF=1, that would seem to preclude > hinting even without disabling HH for the entire system; if the coordinator > is always the single replica, why would it send a copy anywhere else? > Colin explicitly said that he would several nodes and I said I wasn't going to judge, so I implicitly assumed there was a reason for having multiple nodes. If you're going to always ever hit one node, then using a token aware client is over-complicating it. Just use a one node cluster and you'll have nothing to worry about or to configure. That being said, Colin, do be aware that as far as I can tell there is indeed relatively little benefit to having a multi-node cluster on which all data is on one node (in particular, there is no cache at the coordinator level, so that even if your client hit other nodes, everything will still be forwarded to the one node that stores it all, the other nodes won't store anything really, not even in memory). -- Sylvain --047d7b6d907eaa919104eddf16e5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Dec 18, 2013 at 7:31 PM, Robert Coli <rcoli@ev= entbrite.com> wrote:
On Wed, D= ec 18, 2013 at 2:44 AM, Sylvain Lebresne <sylvain@datastax.com><= /span> wrote:
As Janne said, you cou= ld still have hint being written by other nodes if the one storage node is = dead, but you can use the system property=A0cassandra.maxHintTTL to 0 to di= sable hints.

If one uses a Token Aware clie= nt with RF=3D1, that would seem to preclude hinting even without disabling = HH for the entire system; if the coordinator is always the single replica, = why would it send a copy anywhere else?

Colin explicitly said th= at he would several nodes and I said I wasn't going to judge, so I impl= icitly assumed there was a reason for having multiple nodes.

If you're going to always ever hit one node, then using = a token aware client is over-complicating it. Just use a one node cluster a= nd you'll have nothing to worry about or to configure.

That being said, Colin, do be aware that as far as I can= tell there is indeed relatively little benefit to having a multi-node clus= ter on which all data is on one node (in particular, there is no cache at t= he coordinator level, so that even if your client hit other nodes, everythi= ng will still be forwarded to the one node that stores it all, the other no= des won't store anything really, not even in memory).

--
Sylvain
--047d7b6d907eaa919104eddf16e5--