Hi, So you mean to say counters are not accurate? (It is highly likely that multiple parallel threads trying to increment the counter as users click the links).
Thanks Ajay On Mon, Dec 29, 2014 at 4:49 PM, Janne Jalkanen <janne.jalka...@ecyrd.com> wrote: > > 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 > >
