cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jaakko Laine (JIRA)" <>
Subject [jira] Commented: (CASSANDRA-620) Add per-keyspace replication factor (possibly even replication strategy)
Date Thu, 07 Jan 2010 14:16:54 GMT


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

View raw message