cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From aaron morton <aa...@thelastpickle.com>
Subject Re: Measure Latency
Date Wed, 25 May 2011 22:37:05 GMT
I can get down and dirty in the SQL Server world :)

Best analogy is that cassandra is doing "high safety mode synchronous mirroring" http://msdn.microsoft.com/en-us/library/ms189852.aspx
The replicating is effectively inside the Transaction commit, cassandra does not have transactions
but you get the idea.  

And in cassandra data is not replicated from a central point, it is written to all replicas
at once. Mutations travel from the coordinator to the replicas (which may include the coordinator),
never between the replicas. Except for forwarded mutations used when crossing data centre
boundaries.  

If you've got a non error return for a write it has been committed at at least Consistency
Level replicas. Network latency is included in the latency of the request. 

After that the changes may be sent to replicas at did not receive the original mutation at
some point in the future. Depending on the mix of Read Repair, Hinted Handoff and nodetool
repair. 
 
Hope that helps. 
 
-----------------
Aaron Morton
Freelance Cassandra Developer
@aaronmorton
http://www.thelastpickle.com

On 26 May 2011, at 05:56, Stephan P wrote:

> Thanks for the reply.
> 
> I agree about the eventual consistency feature but in "addition" I'm trying to have an
oversight if there is a slowness between nodes in a cluster meaning sometimes "some" network
slowness won't translate in CA slowness and sometimes it will. I guess I'm looking for a process
that tells me what the actual travel time between CA Node A and B is.
> 
> Here is very simple way how the same is done with SQL Server replication (sorry to wonder
off into the RDBMS world):
> I insert a single timestamp into a small table and let SQL server replicate it to nodes.
Upon arrival on each node the insert will automatically generate a default timestamp value
into the same table/row. Taking the diff between original inserted (source) and default insert
(target) timestamp I know precisely how long it took to push that content along within SQL
Server.
> 
> 
> 
> On Tue, May 24, 2011 at 11:46 PM, Aaron Morton <aaron@thelastpickle.com> wrote:
> Once the cluster has returned to the client you know the write has been committed to
Consistency Level  number of nodes. 
> 
> i.e. If you send an insert using QUORUM consistency to a cluster with Replication Factor
3, and you get a non error response you know the write has occurred on at least 2 nodes (one
may be the one the client is connected to.)
> 
> After the initial request has completed it's up the "Eventual Consistency" features of
Read Repair, Hinted Handoff and Anti-Entropy to distribute changes. 
> 
> Does that help or are you thinking of something else?  
> -----------------
> Aaron Morton
> Freelance Cassandra Developer
> @aaronmorton
> http://www.thelastpickle.com
> 
> On 25 May, 2011,at 03:11 PM, Stephan Pfammatter <steplmi4124@gmail.com> wrote:
> 
>> What’s the recommended way of measuring latency between nodes in a cluster?
>> By that I’m not referring to read/write latency for a given KS/CF. 
>> 
>> Basically I want to inject a row in a node A and want to see how long it takes to
get to node B (assuming proper RF is set). 
>> 
>> 
>> 
>> I have already some network monitoring in our windows environment between my distributed
nodes in place. But I still would like to get a handle on how a potential network and/or cassandra
slowness affects inter-node latency. Maybe there is a tool/cmd that I'm not aware of? Tx.
>> 
> 


Mime
View raw message