If you have 40ms NTP drift something is VERY VERY wrong. You should have a local NTP server on the same subnet, do not try to use one on the moon.
On Thu, Jan 17, 2013 at 4:42 AM, Sylvain Lebresne <sylv...@datastax.com>wrote: > > So what I want is, Cassandra provide some information for client, to >> indicate A is stored before B, e.g. global unique timestamp, or row order. >> > > The row order is determined by 1) the comparator you use for the column > family and 2) the column names you, the client, choose for A and B. So what > are the column names you use for A and B? > > Now what you could do is use a TimeUUID comparator for that column family > and use a time uuid for A and B column names. In that case, provided A and > B are sent from the same client node and B is sent after A on that client > (which you said is the case), then any non buggy time uuid generator will > guarantee that the uuid generated for A will be smaller than the one for B > and thus that in Cassandra, A will be sorted before B. > > In any case, the point I want to make is that Cassandra itself cannot do > anything for you problem, because by design the row ordering is something > entirely controlled client side (and just so there is no misunderstanding, > I want to make that point not because I'm not trying to suggest you were > wrong asking this mailing list, but because we can't suggest a proper > solution unless we clearly understand what the problem is). > > -- > Sylvain > > >> >> >> >> 2013/1/17 Sylvain Lebresne <sylv...@datastax.com> >> >>> I'm not sure I fully understand your problem. You seem to be talking of >>> ordering the requests, in the order they are generated. But in that case, >>> you will rely on the ordering of columns within whatever row you store >>> request A and B in, and that order depends on the column names, which in >>> turns is client provided and doesn't depend at all of the time >>> synchronization of the cluster nodes. And since you are able to say that >>> request A comes before B, I suppose this means said requests are generated >>> from the same source. In which case you just need to make sure that the >>> column names storing each request respect the correct ordering. >>> >>> The column timestamps Cassandra uses are here to which update *to the >>> same column* is the more recent one. So it only comes into play if you >>> requests A and B update the same column and you're interested in knowing >>> which one of the update will "win" when you read. But even if that's your >>> case (which doesn't sound like it at all from your description), the column >>> timestamp is only generated server side if you use CQL. And even in that >>> latter case, it's a convenience and you can force a timestamp client side >>> if you really wish. In other words, Cassandra dependency on time >>> synchronization is not a strong one even in that case. But again, that >>> doesn't seem at all to be the problem you are trying to solve. >>> >>> -- >>> Sylvain >>> >>> >>> On Thu, Jan 17, 2013 at 2:56 AM, Jason Tang <ares.t...@gmail.com> wrote: >>> >>>> Hi >>>> >>>> I am using Cassandra in a message bus solution, the major >>>> responsibility of cassandra is recording the incoming requests for later >>>> consumming. >>>> >>>> One strategy is First in First out (FIFO), so I need to get the stored >>>> request in reversed order. >>>> >>>> I use NTP to synchronize the system time for the nodes in the cluster. >>>> (4 nodes). >>>> >>>> But the local time of each node are still have some inaccuracy, around >>>> 40 ms. >>>> >>>> The consistency level is write all and read one, and replicate factor >>>> is 3. >>>> >>>> But here is the problem: >>>> A request come to node One at local time PM 10:00:01.000 >>>> B request come to node Two at local time PM 10:00:00.980 >>>> >>>> The correct order is A --> B >>>> But the timestamp is B --> A >>>> >>>> So is there any way for Cassandra to keep the correct order for read >>>> operation? (e.g. logical timestamp ?) >>>> >>>> Or Cassandra strong depence on time synchronization solution? >>>> >>>> BRs >>>> //Tang >>>> >>>> >>>> >>>> >>>> >>> >> >
