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.christ...@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 >
