cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vijay <vijay2...@gmail.com>
Subject Re: Cassandra Consistency problem with NTP
Date Sun, 27 Jan 2013 23:21:52 GMT
Just FYI,
For one of the projects, i got around the NTP Drift problem by always
reading more than i need,
For example i want to read all the messages before x seconds then i would
query cassandra for (x seconds + 500ms) then filter the duplicates in the
client.

Yes it does more network and yes client needs more logic to handle it.

Regards,
</VJ>


On Thu, Jan 17, 2013 at 10:47 AM, Edward Capriolo <edlinuxguru@gmail.com>wrote:

> 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 <sylvain@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 <sylvain@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.tang@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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>

Mime
View raw message