cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "sankalp kohli (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-7979) Acceptable time skew for C*
Date Fri, 19 Dec 2014 15:56:14 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-7979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14253565#comment-14253565
] 

sankalp kohli commented on CASSANDRA-7979:
------------------------------------------

"Now I'm using this extreme use case, but this goes to show, this number is only even "roughly"
accurate when there is no time skew, and it's wildly inaccurate and misleading when there
is time skew, so in the case where it would be MOST USEFUL, it has NO VALUE, and all other
cases where it's roughly accurate (because there is no time skew) no one would care. Therefore,
I would file this idea under the category of "bad experience for new users"."

This won't be accurate when there is a time skew. But you can use this with measured clock
skew among your machines. 
There are applications which update the same columns minutes apart and some which will update
it within a few mills. This tells you which application is what. This help you decide which
time infrastructure you will need in your DC.  

> Acceptable time skew for C*
> ---------------------------
>
>                 Key: CASSANDRA-7979
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-7979
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: sankalp kohli
>            Assignee: sankalp kohli
>            Priority: Minor
>             Fix For: 2.0.12, 2.1.2, 3.0
>
>         Attachments: 2.0_7979.diff, 2.0_7979_v2.txt, 2.0_7979_v3.txt, 2.1_7979_v2.txt,
trunk_7979.diff, trunk_7979_v2.txt
>
>
> It is very hard to know the bounds on clock skew required for C* to work properly. Since
the resolution is based on time and is at thrift column level, it depends on the application.
How fast is the application updating the same column. If you update a column say after 5 millisecond
and the clock skew is more than that, you might not see the updates in correct order. 
> In this JIRA, I am proposing a change which will answer this question: "How much clock
skew is acceptable for a given application". This will help answer the question whether the
system needs some alternate NTP algorithms to keep time in sync. 
> If we measure the time difference between two updates to the same column,  we will be
able to answer the question on clock skew. 
> We can implement this in memtable(AtomicSortedColumns.addColumn). If we find that a column
is updated within say 100 millisecond, add the diff to a histogram. Since this might have
performance issues, we might want to have some throttling like randomization or only enable
it for a small time via nodetool. 
> With this histogram, we will know what is an acceptable clock skew. 
> Also apart from column resolution, is there any other area which will be affected by
clock skew? 
> Note: For the sake of argument, I am not talking about back date deletes or application
modified timestamps. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message