cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kelvin Kakugawa (JIRA)" <>
Subject [jira] Commented: (CASSANDRA-1546) (Yet another) approach to counting
Date Tue, 05 Oct 2010 16:43:36 GMT


Kelvin Kakugawa commented on CASSANDRA-1546:


I read through your patches.  I'd like to discuss two aspects of #1546:
1) the counter storage strategy, and
2) the effectiveness of uuids.

The counter storage strategy moves the complexity away from the column class and into the
surrounding mutation and read logic.  The problem this causes is that to understand a column-specific
property--it's partitioned value, we have to read code in mutation and read commands and put
together the logic in conjunction w/ how it interacts w/ the cassandra data model, at large.
 The other challenge is that the existing cassandra data model is co-opted, so the end user
has to learn a modified data model that is counter-specific.  I don't believe this is the
right encapsulation.

A better encapsulation would be to re-use the context-based partition value from #1072 in
a custom Column sub-class.  All the logic has already been implemented, they just need to
be refactored out of the clock class.  I understand that the context-based logic is relatively
complex.  However, it has far better unit test coverage than the rest of the cassandra codebase
and, more importantly, has been deployed successfully in production at scale.  ntm, the existing
cassandra data model would not be modified.  I feel like this would be a better encapsulation
that is easier to reason about.

The uuid strategy is worth investigating.  However, a limitation of its design is that uuids
are not coordinated across replicas.  i.e. you cannot re-try and update w/ a given uuid on
multiple replicas.  The leader for a given uuid must be coordinated, at the client or coordinator
level, to always correspond to the same replica.  e.g. if this is done at the coordinator
level, on a failed write, the leader has to be maintained and the mutation has to go through
hinted hand-off.  However, a limitation of this is that if the chosen leader goes down permanently,
there may be orphaned HH mutations.  However, it at least permits retries on the same replica
and may be interesting for certain use cases.

> (Yet another) approach to counting
> ----------------------------------
>                 Key: CASSANDRA-1546
>                 URL:
>             Project: Cassandra
>          Issue Type: New Feature
>          Components: Core
>            Reporter: Sylvain Lebresne
>            Assignee: Sylvain Lebresne
>             Fix For: 0.7.0
>         Attachments: 0001-Remove-IClock-from-internals.patch, 0001-v2-Remove-IClock-from-internals.patch,
0002-Counters.patch, 0002-v2-Counters.patch, 0003-Generated-thrift-files-changes.patch, 0003-v2-Thrift-changes.patch
> This could be described as a mix between CASSANDRA-1072 without clocks and CASSANDRA-1421.
> More details in the comment below.

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

View raw message