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