cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-2369) support replication decisions per-key
Date Wed, 27 Apr 2011 20:04:03 GMT


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:
>             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

This message is automatically generated by JIRA.
For more information on JIRA, see:

View raw message