cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "sankalp kohli (JIRA)" <>
Subject [jira] [Created] (CASSANDRA-7979) Acceptable time skew for C*
Date Fri, 19 Sep 2014 05:04:33 GMT
sankalp kohli created CASSANDRA-7979:

             Summary: Acceptable time skew for C*
                 Key: CASSANDRA-7979
             Project: Cassandra
          Issue Type: Improvement
            Reporter: sankalp kohli
            Priority: Minor

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

Note: For the sake of argument, I am not talking about back date deletes or application modified

This message was sent by Atlassian JIRA

View raw message