Return-Path: X-Original-To: apmail-cassandra-commits-archive@www.apache.org Delivered-To: apmail-cassandra-commits-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id DF59510254 for ; Thu, 19 Dec 2013 02:20:11 +0000 (UTC) Received: (qmail 87679 invoked by uid 500); 19 Dec 2013 02:20:11 -0000 Delivered-To: apmail-cassandra-commits-archive@cassandra.apache.org Received: (qmail 87649 invoked by uid 500); 19 Dec 2013 02:20:11 -0000 Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cassandra.apache.org Delivered-To: mailing list commits@cassandra.apache.org Received: (qmail 87639 invoked by uid 99); 19 Dec 2013 02:20:11 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 19 Dec 2013 02:20:11 +0000 Date: Thu, 19 Dec 2013 02:20:11 +0000 (UTC) From: "Aleksey Yeschenko (JIRA)" To: commits@cassandra.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (CASSANDRA-4775) Counters 2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/CASSANDRA-4775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13852493#comment-13852493 ] Aleksey Yeschenko commented on CASSANDRA-4775: ---------------------------------------------- So, this thread has become quite overloaded. Will summarize it shortly in this comment, and then move the actual work/discussion to CASSANDRA-6504. The initial idea for the new design (a new cell for each increment/decrement, then summing up on reads) and its variations didn't work out, for one reason or another. The largest problems are the required coordination for collapsing the increment history and difficulty in making it backward compatible with the current implementation. We decided to go for incremental improvements instead - namely, stop using 'local' shards altogether, and do explicit read-modify-write with just one shard type ('global') instead. See https://issues.apache.org/jira/browse/CASSANDRA-4775?focusedCommentId=13702042&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13702042 and the comments following it (plus https://issues.apache.org/jira/browse/CASSANDRA-4071?focusedCommentId=13483381&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13483381). This will fix, *at minimum*, the over counting issue with commit log replay, CASSANDRA-4417, and CASSANDRA-4071, and, together with some related improvements, drastically simplify counters code in general. > Counters 2.0 > ------------ > > Key: CASSANDRA-4775 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4775 > Project: Cassandra > Issue Type: New Feature > Components: Core > Reporter: Arya Goudarzi > Assignee: Aleksey Yeschenko > Labels: counters > Fix For: 2.1 > > > The existing partitioned counters remain a source of frustration for most users almost two years after being introduced. The remaining problems are inherent in the design, not something that can be fixed given enough time/eyeballs. > Ideally a solution would give us > - similar performance > - less special cases in the code > - potential for a retry mechanism -- This message was sent by Atlassian JIRA (v6.1.4#6159)