cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeremy Hanna (JIRA)" <j...@apache.org>
Subject [jira] Updated: (CASSANDRA-1066) DatacenterShardStrategy needs enforceable and keyspace based RF
Date Wed, 16 Jun 2010 15:42:24 GMT

     [ https://issues.apache.org/jira/browse/CASSANDRA-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Jeremy Hanna updated CASSANDRA-1066:
------------------------------------

    Attachment: tentative-1066-changes.txt

Attaching a tentative way to handle this.  Most of the files modified are just renaming variables,
but a few of them have more substantial changes.

Essentially, since there is a 1:1 relationship between replication strategies and keyspaces,
it seems natural to add the replication strategy to the keyspace data structure.  That way
the independent map of quasi-singletons of replication strategies can be removed and everything
is handled by the keyspace metadata object.  That cleans up some other instances when things
like removing keyspaces happens.  It also makes it nice when new keyspaces are created because
it's all handled in one place - the system add keyspace call.  Otherwise, we would run into
the condition that the configuration for DSS would have to be done before the keyspace is
created in order for it to have a working strategy.  Additionally, whenever we handle the
alter keyspace functionality, it's nice to have that together.

Another approach would have been to handle initialization within the keyspace metadata class
itself, but Gary seemed opposed to doing that in there.  That does mean that since the keyspace
metadata object has the full strategy object, it will need to handle serialization/deserialization
for it, but that would need to happen in any case where we tie the two together (strategy
and KSM).

Gary - btw is there any reason why we're writing our own serialization code for the KSM object
rather than just relying on Java's serialization?

I've commented out some things and haven't done the avro binding fully just because this is
a rough patch to get feedback about the approach.

> DatacenterShardStrategy needs enforceable and keyspace based RF
> ---------------------------------------------------------------
>
>                 Key: CASSANDRA-1066
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-1066
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>            Reporter: Jeremy Hanna
>            Assignee: Jeremy Hanna
>            Priority: Minor
>             Fix For: 0.7
>
>         Attachments: tentative-1066-changes.txt
>
>
> Currently, the DatacenterShardStrategy reads in a properties file - datacenters.properties
- to get a per-datacenter replication factor.  So any keyspace that is using the DSS in the
cluster is using that same properties file to configure its replication factor.  The implementation
doesn't take into account the per-keyspace replication factor, but it is assumed that the
sum of all the datacenter RF values equals the per-keyspace replication value that is part
of the keyspace metadata.
> It seems that an improvement could be two-fold:
> 1. Enforce the replication factor for the keyspace as always equal the sum of all the
datacenter RF values.  Otherwise, if they aren't equal, bad things (tm) can happen.
> 2. Make the datacenter RF values part of the keyspace metadata rather than a global value.
 Again, currently if any keyspace in the cluster is configured to use DSS, it will be using
the global DC RF values found in the properties file.  An improvement could be to instead
of having the properties file, configure that on a per keyspace basis.  That would make the
cluster more multi-tenant friendly so it could be flexible with multiple keyspaces.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message