cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aditya Narayan <>
Subject Re: Sorting in time order without using TimeUUID type column names
Date Thu, 03 Feb 2011 12:35:37 GMT
If I use : <TimestampOfDueTimeInFuture>| <UserId> | <ReminderCountOfThisUser>
as key pattern for the rows of reminders, then I am storing the key,
just as it is, as the column name and thus column values  need not
contain a link to the row containing the reminder details.

I think UserId would be required along with timestamp in the key
pattern to provide uniqueness to the key as there may be several
reminders generated, at the same time by other users on the

But my question is about whether it is really advisable to even
generate the keys like this pattern ... instead of going with
timeuuids ?
Are there are any downsides which I am not perhaps not aware of ?

On Thu, Feb 3, 2011 at 5:43 PM, Sylvain Lebresne <> wrote:
> On Thu, Feb 3, 2011 at 11:27 AM, Aditya Narayan <> wrote:
>> Hey all,
>> I want to store some columns that are reminders to the users on my
>> application, in time sorted order in a row(timeline row of the user).
>> Would it be recommended to store these reminder columns in the
>> timeline row with column names like: combination of timestamp(of time
>> when the reminder gets due) + UserId+ Reminders Count of that user;
>> Column Name= <TimestampOfDueTimeInFuture>: <UserId> :
>> <ReminderCountOfThisUser>
> If you have one row by user (which is a good idea), why keep the UserId in
> the column name ?
>> Then what comparator could I use to sort them in order of the their
>> due time ? This comparator should be able to sort no. in descending
>> order.(I guess ascii type would do the opposite order) (Reminders need
>> to be sorted in the timeline in the order of their due time.)
> *The* solution is write a custom comparator.
> Have a look at
> and for instance.
> As a side note, the fact that the comparator sort in ascending order when
> you
> need descending order would be that much of a problem, since you can always
> do slice queries in reversed order. But even then, asciiType is not a very
> satisfying solution as you would have to be careful about the padding of
> your
> timestamp for it to work correctly. So again, custom comparator is the way
> to go.
>> Basically I am trying to avoid 16 bytes long timeUUID first because
>> they are too long and the above defined key pattern is guaranteeing me
>> a unique key/Id for the reminder row always.
>> Thanks
>> Aditya Narayan
> --
> Sylvain

View raw message