Hi! It’s really a tradeoff between accurate and fast and your read access patterns; if you need it to be fairly fast, use counters by all means, but accept the fact that they will (especially in older versions of cassandra or adverse network conditions) drift off from the true click count. If you need accurate, use a timeuuid and count the rows (this is fairly safe for replays too). However, if using timeuuids your storage will need lots of space; and your reads will be slow if the click counts are huge (because Cassandra will need to read every item). Using counters makes it easy to just grab a slice of the time series data and shove it to a client for visualization.
You could of course do a hybrid system; use timeuuids and then periodically count and add the result to a regular column, and then remove the columns. Note that you might want to optimize this so that you don’t end up with a lot of tombstones, e.g. by bucketing the writes so that you can delete everything with just a single partition delete. At Thinglink some of the more important counters that we use are backed up by the actual data. So for speed purposes we use always counters for reads, but there’s a repair process that fixes the counter value if we suspect it starts drifting off the real data too much. (You might be able to tell that we’ve been using counters for quite some time :-P) /Janne On 29 Dec 2014, at 13:00, Ajay <ajay.ga...@gmail.com> wrote: > Hi, > > Is it better to use Counter to User click count than maintaining creating new > row as user id : timestamp and count it. > > Basically we want to track the user clicks and use the same for > hourly/daily/monthly report. > > Thanks > Ajay
