[
https://issues.apache.org/jira/browse/CASSANDRA-620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12797635#action_12797635
]
Jaakko Laine commented on CASSANDRA-620:
----------------------------------------
I think one tokenMetadata is enough. When replication strategies construct
endpoint lists, they just get token/endpoint information from token metadata
and then pick the nodes they want from that list. I think there is no need to
duplicate this information.
The problem that needs to be addressed is pending ranges, but I think we can do
that relatively easily inside "one" token metadata: In order to address
multiple replication strategies and replication factors, we'll need to be able
to support any combination of those two. The easiest way to address this would
probably be to always calculate pending ranges for all replication strategies
in use, and for maximum replica count for each replication strategy.
That is, if we have following replication strategies in use:
Table1: RackAware, factor 3
Table2: RackUnaware, factor 2
Table3: RackAware, factor 2
We would calculate pending ranges for RackAware using factor 3 and for
RackUnaware using factor 2. This would prepare tokenmetadata to serve any
pending range query possible and would need only as many separate lists as
there are strategies in use. Pending ranges would be stored in ordered list, so
when replication strategy (getWriteEndPoints) is considering Table3, it would
only look for first two ranges in the list for RackAware (naturally for Table1
full list would be considered)
> Add per-keyspace replication factor (possibly even replication strategy)
> ------------------------------------------------------------------------
>
> Key: CASSANDRA-620
> URL: https://issues.apache.org/jira/browse/CASSANDRA-620
> Project: Cassandra
> Issue Type: New Feature
> Reporter: Jonathan Ellis
> Fix For: 0.9
>
>
> (but partitioner may only be cluster-wide, still)
> not 100% sure this makes sense but it would allow maintaining system metadata
> in a replicated-across-entire-cluster keyspace (without ugly special casing),
> as well as making Cassandra more flexible as a shared resource for multiple
> apps
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
