Re: User click count

multiple parallel threads trying to increment the counter as users >>>>>>> click the links). >>>>>>> >>>>>>> Thanks >>>>>>> Ajay >>>>>>> >>>>>>> >>>>>>&g

Re: User click count

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

Re: User click count

etwork 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 >>>&g

Re: User click count

On Mon, Dec 29, 2014 at 6:05 AM, Ajay wrote: > In my case, Cassandra is the only storage. If the counters get incorrect, > it could't be corrected. > Cassandra counters are not appropriate for this use case, if correctness is a requirement. =Rob

Re: User click count

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

Re: User click count

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

Re: User click count

gt;>> 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 Thin

Re: User click count

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

Re: User click count

portant 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

Re: User click count

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

Re: User click count

r 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

User click count

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