Re: Counter table in Cassandra

[Paul Chandler]

Hi Garvit,

When updating counters, Cassandra does a read then a write, so there is an 
overhead of using counters. This is all explained here: 
https://www.datastax.com/dev/blog/whats-new-in-cassandra-2-1-a-better-implementation-of-counters
 


There is a design pattern that can be used instead of counters, this will not 
work if you need instant accuracy, but if you are looking for a count value to 
be “eventually" correct then it will be a lot less taxing on cassandra. I have 
outlined this pattern in a blog post, when I wrote it I was advising a team 
that was performing a lot of count(*) on a table, so it starts from that 
premise rather than using counters, but the result is the same. This can be 
found here: http://www.redshots.com/cassandra-counting-without-using-counters/ 


I hope these links help.

Regards

Paul Chandler



> On 29 May 2019, at 10:18, Attila Wind  wrote:
> 
> Hi Garvit,
> 
> I can not answer your main question but when I read your lines one thing was 
> popping up constantly: "why do you ask this?" 
> 
> So what is the background of this question? Do you see anything smelly?
> 
> Actually
> a) I always assumed so naturally there are of course lots of in-parallel 
> activities (writes) against any tables includin counters. So of course there 
> is a race condition and probably threads yes
> 
> b) Cassandra do not have isolated transactions so of course in a complex flow 
> (using multiple tables) there is no business data consistency guarantee for 
> sure
> 
> c) until you are doing just +/- ops it is a mathematical fact that execution 
> order of writes is not really important. Repeating +1 increase 5 times will 
> result in higher counter by num 5...
> 
> Please share your background I am interested in it!
> 
> Cheers
> Attila
> 
> 2019. máj. 29., Sze 2:34 dátummal Garvit Sharma  > ezt írta:
> Hi,
> 
> I am using counter tables in Cassandra and I want to understand how the 
> concurrent updates to counter table are handled in Cassandra.
> 
> There are more than one threads who are responsible for updating the counter 
> for a partition key. Multiple threads can also update the counter for the 
> same key.
> 
> In case when more than one threads updating the counter for the same key, how 
> Cassandra is handling the race condition?
> 
> UPDATE cycling.popular_count
>  SET popularity = popularity + 1
>  WHERE id = 6ab09bec-e68e-48d9-a5f8-97e6fb4c9b47;
> 
> Are there overheads of using counter tables? 
> Are there alternatives to counter tables?
> 
> Thanks,
> -- 
> 
> Garvit Sharma
> github.com/garvitlnmiit/ 
> 
> No Body is a Scholar by birth, its only hard work and strong determination 
> that makes him master.

Re: Counter table in Cassandra

[Attila Wind]

Hi Garvit,

I can not answer your main question but when I read your lines one thing
was popping up constantly: "why do you ask this?"

So what is the background of this question? Do you see anything smelly?

Actually
a) I always assumed so naturally there are of course lots of in-parallel
activities (writes) against any tables includin counters. So of course
there is a race condition and probably threads yes

b) Cassandra do not have isolated transactions so of course in a complex
flow (using multiple tables) there is no business data consistency
guarantee for sure

c) until you are doing just +/- ops it is a mathematical fact that
execution order of writes is not really important. Repeating +1 increase 5
times will result in higher counter by num 5...

Please share your background I am interested in it!

Cheers
Attila

2019. máj. 29., Sze 2:34 dátummal Garvit Sharma  ezt
írta:

> Hi,
>
> I am using counter tables in Cassandra and I want to understand how the
> concurrent updates to counter table are handled in Cassandra.
>
> There are more than one threads who are responsible for updating the
> counter for a partition key. Multiple threads can also update the counter
> for the same key.
>
> In case when more than one threads updating the counter for the same key,
> how Cassandra is handling the race condition?
>
> UPDATE cycling.popular_count
>  SET popularity = popularity + 1
>  WHERE id = 6ab09bec-e68e-48d9-a5f8-97e6fb4c9b47;
>
>
> Are there overheads of using counter tables?
> Are there alternatives to counter tables?
>
> Thanks,
> --
>
> Garvit Sharma
> github.com/garvitlnmiit/
>
> No Body is a Scholar by birth, its only hard work and strong determination
> that makes him master.
>