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 C442FDD27 for ; Wed, 28 Nov 2012 09:21:50 +0000 (UTC) Received: (qmail 59920 invoked by uid 500); 28 Nov 2012 09:21:48 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 59610 invoked by uid 500); 28 Nov 2012 09:21:47 -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 59577 invoked by uid 99); 28 Nov 2012 09:21:46 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 28 Nov 2012 09:21:46 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [209.85.210.172] (HELO mail-ia0-f172.google.com) (209.85.210.172) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 28 Nov 2012 09:21:40 +0000 Received: by mail-ia0-f172.google.com with SMTP id j26so10552514iaf.31 for ; Wed, 28 Nov 2012 01:21:20 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=os4ORhEAdoEjlCbzdf3wX3p1khQ0diBV9EZyZj02N1Y=; b=jonPILpFXay4EHIvnAYuavCkQVPA87MVY0Ka1GOQPg3PuZSDxFsCIEhnnp6ZJXWtHt M7UxDqefY9ktx5d++AcbS5xqfSHwZ5LjpomXJN4ILs7o3B3x8HaYiKoK1LvelDjrGR4R DXw9zm91wOosWsvIjExtVnAaz6JaCHfhfebuq96ThXV+MsgsmUO9Icy3dF7laKpy4ILS 1Ah3duDzm7XRQy7eaJ0go3ZnW9gg8LREJe4LLfFH8+WVHYzpmx4gYeKkF9JAdScaXYz5 E3kNcSEKuH/vBLnbuqW2RO+ppfXklW/0cw67E8xp22BzH70yhCT3ZVP9R7DWYO+mXh4q eo8w== MIME-Version: 1.0 Received: by 10.50.157.162 with SMTP id wn2mr18568182igb.27.1354094479944; Wed, 28 Nov 2012 01:21:19 -0800 (PST) Received: by 10.50.192.138 with HTTP; Wed, 28 Nov 2012 01:21:19 -0800 (PST) In-Reply-To: References: <1354038762579-7583996.post@n2.nabble.com> <50B5491C.9020101@mailchannels.com> Date: Wed, 28 Nov 2012 01:21:19 -0800 Message-ID: Subject: Re: counters + replication = awful performance? From: Rob Coli To: user@cassandra.apache.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlLh4YC/MoW7e2PnIz5L+v3PdvIaagafVlGKf8qQfUsPM7z9k8oH+ba6iJ8YPSmtMPABbtN X-Virus-Checked: Checked by ClamAV on apache.org On Tue, Nov 27, 2012 at 3:21 PM, Edward Capriolo wrote: > I mispoke really. It is not dangerous you just have to understand what it > means. this jira discusses it. > > https://issues.apache.org/jira/browse/CASSANDRA-3868 Per Sylvain on the referenced ticket : " I don't disagree about the efficiency of the valve, but at what price? 'Bootstrapping a node will make you lose increments (you don't know which ones, you don't know how many and this even if nothing goes wrong)' is a pretty bad drawback. That is pretty much why that option makes me uncomfortable: it does give you better performance, so people may be tempted to use it. Now if it was only a matter of replicating writes only through read-repair/repair, then ok, it's pretty dangerous but it's rather easy to explain/understand the drawback (if you don't lose a disk, you don't lose increments, and you'd better use CL.ALL or have read_repair_chance to 1). But the fact that it doesn't work with bootstrap/move makes me wonder if having the option at all is not making a disservice to users. " To me anything that can be described as "will make you lose increments (you don't know which ones, you don't know how many and this even if nothing goes wrong)" and which therefore "doesn't work with bootstrap/move" is correctly described as "dangerous." :D =Rob -- =Robert Coli AIM>ALK - rcoli@palominodb.com YAHOO - rcoli.palominob SKYPE - rcoli_palominodb