cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stu Hood (JIRA)" <j...@apache.org>
Subject [jira] Commented: (CASSANDRA-1072) Increment counters
Date Fri, 20 Aug 2010 20:27:24 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-1072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12900848#action_12900848
] 

Stu Hood commented on CASSANDRA-1072:
-------------------------------------

I don't see a clear solution to prevent the read-before-write step inherent in #580, but if
read-before-write / CAS loop is a common enough step (for this issue and 1311), perhaps pushing
the CAS loop to the server would be useful. I'll comment on 1311 with some thoughts.

----

I think I agree with jbellis on this one: implementing write scaling (striping?) in a way
that isn't generic breaks EC, so I'd like to see a solution there.

> Because 1072 "shards" the increments across multiple machines
A generic way to improve write throughput would be to implement striping. The outcome would
essentially be duplicated rings overlaid on one another, so that multiple replica sets "own"
the same tokens. For example, with N = 3, and a "striping factor" of 2, a single range would
have 2 stripes of 3 nodes each, where each stripe holds disjoint data, and must be queried
at read time. Writes go to a random stripe, so W=1 would block for 1 node in a stripe, and
W=ALL would block for all 3 nodes in a stripe. Reads would need to touch both stripes, so
a R=1 read would need to block for 2 nodes (one from each stripe).

(The write throughput problem also heavily affects timeseries data, because users currently
have to implement their own striping to prevent overloading the range receiving current data.)

> Increment counters
> ------------------
>
>                 Key: CASSANDRA-1072
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-1072
>             Project: Cassandra
>          Issue Type: Sub-task
>          Components: Core
>            Reporter: Johan Oskarsson
>            Assignee: Kelvin Kakugawa
>         Attachments: CASSANDRA-1072-2.patch, CASSANDRA-1072-2.patch, CASSANDRA-1072.patch,
CASSANDRA-1072.patch, Incrementcountersdesigndoc.pdf
>
>
> Break out the increment counters out of CASSANDRA-580. Classes are shared between the
two features but without the plain version vector code the changeset becomes smaller and more
manageable.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message