You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Jonathan Ellis (JIRA)" <ji...@apache.org> on 2011/04/27 22:04:03 UTC
[jira] [Commented] (CASSANDRA-2369) support replication decisions
per-key
[ https://issues.apache.org/jira/browse/CASSANDRA-2369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13025976#comment-13025976 ]
Jonathan Ellis commented on CASSANDRA-2369:
-------------------------------------------
The more I think about this the more I suspect that what I'm asking for here is a return to the assumption that keys:tokens are 1:1, i.e., incompatible with CASSANDRA-1034.
It's actually even worse than that, because nodes own token _ranges_: if I have tokens X Y and Z that sort in that order, and a node has range (T, Z] then they all have to be on that node, no matter what the original keys were.
So I think the right approach is not to mess with ReplicationStrategy api, but rather to build some kind of row-aware partitioner that generates tokens with extra metadata, e.g., a (hash, {dc1: 2, dc2: 0, dc3: 1}) tuple. Then the strategy would only have to run logic similar to NTS, except instead of per-keyspace strategy options it would get them from the Token object.
> support replication decisions per-key
> -------------------------------------
>
> Key: CASSANDRA-2369
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2369
> Project: Cassandra
> Issue Type: New Feature
> Reporter: Jonathan Ellis
> Assignee: paul cannon
> Priority: Minor
> Fix For: 1.0
>
>
> Currently the replicationstrategy gets a token and a keyspace with which to decide how to place replicas. for per-row replication this is insufficient because tokenization is lossy (CASSANDRA-1034).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira