On Tue, Apr 5, 2011 at 10:45 PM, Yudong Gao <st...@umich.edu> wrote:
>> A better solution would be to just push the DecoratedKey into the
>> ReplicationStrategy so it can make its decision before information is
>> thrown away.
>
> I agree. So in this case, I guess the hashed based token ring is still
> preserved to avoid hot spot, but we further use the DecoratedKey to
> guide the replication strategy. For example, replica 2 is placed in
> the first node along the ring the belongs the desirable data center
> (based on the location hint embedded DecoratedKey). But we may not be
> able to control the primary replica. Do you think this will be a
> reasonable design?
calculateNaturalEndpoints has complete freedom to generate all
replicas any way it likes. Thinking of an endpoint as "primary"
because it was generated first by one algorithm is dangerous.
As one of the docstrings explains, replica destinations ("endpoints")
should be considered a Set even though we use a List for efficiency.
None of them are special at the ReplicationStrategy level.
> Just curious, are they happy with the current
> solution with keyspace, and is there some requests for per-row
> placement control?
Enough people want to try it that we have the ticket open. :)
--
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder of DataStax, the source for professional Cassandra support
http://www.datastax.com
