> 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 >>> >>> >>> >>> >>> >> >
