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

Counter table in Cassandra

[Garvit Sharma]

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.