[
https://issues.apache.org/jira/browse/CASSANDRA-1546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12918065#action_12918065
]
Kelvin Kakugawa commented on CASSANDRA-1546:
--------------------------------------------
Sylvain,
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: https://issues.apache.org/jira/browse/CASSANDRA-1546
> 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.
