You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cassandra.apache.org by Christian Decker <de...@gmail.com> on 2010/11/05 23:54:26 UTC

Key to Token clarification

Hi all,

I'm trying to figure out some minor understanding problems. As I see it for
each Keyspace each node takes care about a certain tokenRange (describe_ring
gives me the assignment), these TokenRanges have a list of nodes that hold
replicas, a start token and an end token. The tokens are of type byte[] and
can be interpreted as BigInteger. Tokens are usually taken care of at the
node with the next higher token, and the previous (replicas-1)-nodes. Should
a token be larger than the largest token of a node it'll wrap around to the
smallest. So if I have a single node it'll tell me that it has TokenRange X
to X (X being the same token in both cases), that means that it basically
takes care of the entire possible token range, right?

So far it's all DHT as usual, the point I'm having problems is the mapping
of the byte[] keys of the Column Family system to the token system used to
identify the responsible nodes for a given key. You guessed it I want to be
able to, given a key, find the node that is storing the value that goes with
it.

Also how reliable are the informations I'm getting from describe_ring are.
What actions trigger a token assignment change and what affects which nodes
change the nodes holding the replicas (new node join aside)?

Regards,
Chris

Re: Key to Token clarification

Posted by Tyler Hobbs <ty...@riptano.com>.
Minor correction: instead of replicating at the 'previous (replicas-1)
nodes' it's replicated to the next (RF - 1) nodes clockwise, assuming you're
using SimpleStrategy.  NetworkTopologyStrategy and similar skip nodes in the
ring to make sure you meet your cross-datacenter requirements.

Which node a key goes to depends on the partitioner.  If you're using
RandomPartitioner, then you take an MD5 hash of the key, and that gives you
a location on the ring.  The order preserving partitioners use the actual
key instead of a hash.

- Tyler

On Fri, Nov 5, 2010 at 5:54 PM, Christian Decker <decker.christian@gmail.com
> wrote:

> Hi all,
>
> I'm trying to figure out some minor understanding problems. As I see it for
> each Keyspace each node takes care about a certain tokenRange (describe_ring
> gives me the assignment), these TokenRanges have a list of nodes that hold
> replicas, a start token and an end token. The tokens are of type byte[] and
> can be interpreted as BigInteger. Tokens are usually taken care of at the
> node with the next higher token, and the previous (replicas-1)-nodes. Should
> a token be larger than the largest token of a node it'll wrap around to the
> smallest. So if I have a single node it'll tell me that it has TokenRange X
> to X (X being the same token in both cases), that means that it basically
> takes care of the entire possible token range, right?
>
> So far it's all DHT as usual, the point I'm having problems is the mapping
> of the byte[] keys of the Column Family system to the token system used to
> identify the responsible nodes for a given key. You guessed it I want to be
> able to, given a key, find the node that is storing the value that goes with
> it.
>
> Also how reliable are the informations I'm getting from describe_ring are.
> What actions trigger a token assignment change and what affects which nodes
> change the nodes holding the replicas (new node join aside)?
>
> Regards,
> Chris
>