Your first thought was pretty much correct: 1. The node which is called by the client is the coordinator 2. The coordinator determines the nodes in the ring which can handle the request ordered by expected latency (via snitch). The coordinator may or may not be part of these nodes 3. Given the consistency level and read repair chance the coordinator calculates the min amount of node to ask and sends read requests to them 4. As soon as the minimum count (according to consistency) of responses is collected the coordinator will respond to the request. Mismatches will lead to repair write requests to the corresponding nodes
Thus the minimal depth is one (CL = 1 and coordinator can handle the request itself) or two otherwise. Hope that helps On Jan 23, 2012, at 4:47 PM, Peter Dijkshoorn wrote: > > Hi guys, > > I got an architectural question about how a write operation flows > through the nodes. > > As far as I understand now, a client sends its write operation to > whatever node it was set to use and if that node does not contain the > data for this key K, then this node forwards the operation to the first > node given by the hash function. This first node having key K then > contacts the replication nodes depending on the selected consistency level. > > This means that in the unlucky event you always have a network call > sequence depth of 2 (consistency level one), or 3 (assumed that the > replication nodes are contacted in parallel) > > This is more than I expected, so I am not sure whether this is correct? > can someone help me out? > > At first I thought that the receiver was the coordinator, and thus doing > all further calls in parallel, the depth as described above would always > be 2. But I just discovered that I was wrong and that it should be > something like above. > > Another possibility would be that the client learnt the layout of the > cluster at connection time and thereby tries per request to contact the > coordinator directly, but I never read or see something like this happening. > > Remembering the picture of Dean about network and hard disk latencies, > is this 3-sequential-network-call still faster? > > Thanks for any thoughts :) > > Peter > > -- > Peter Dijkshoorn > Adyen - Payments Made Easy > www.adyen.com > > Visiting Address: Mail Address: > Stationsplein 57 - 4th floor P.O. Box 10095 > 1012 AB Amsterdam 1001 EB Amsterdam > The Netherlands The Netherlands > > Office +31.20.240.1240 > Email peter.dijksho...@adyen.com >
