You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cassandra.apache.org by Attila Wind <at...@swf.technology> on 2021/03/06 16:02:48 UTC
moving away from Counters - strategy?
Hi guys,
We do use Counter tables a lot because in our app we have several things
to count (business logic)
More time we work with Cassandra we keep hearing more and more: "you
should not use counter tables because ....."
Yes, we also feel here and there the trade off is too much restrictive -
for us what hurts now days is that deleting counters it seems not that
simple... Also the TTL possibility we do miss a lot.
But I have to confess I do not see an obvious migration strategy here...
What bothers me e.g.: concurrency, and wrong results thanks to that
namely
If I want to fulfill the mission "UPDATE table SET mycounter = mycounter
+ x WHERE ..." does
with traditional table (with an int column) I need to do this:
1. read the value of "mycounter"
2. add x to the value I readc(in memory)
3. update mycounter = new value
Needless to say that if I have a race condition so ThreadA and ThreadB
are executing the above sequence ~ the same time then the mycounter
value will be wrong...
I started to wonder: how do you solve this problem?
Is anyone aware of any nice post/article regarding migration strategy -
stepping away from counters?
thanks!
--
Attila Wind
http://www.linkedin.com/in/attilaw <http://www.linkedin.com/in/attilaw>
Mobile: +49 176 43556932
Re: moving away from Counters - strategy?
Posted by Attila Wind <at...@swf.technology>.
Ahh forgot to mention we have RF=2, sorry!
LWT requires RF >= 3 otherwise we can not tolerate losing a node (because
of LOCAL_QUORUM is working in the background which you can not really
change AFAIK...)
Or am I wrong?
Plus in a highly concurrent setup writing the same PK this optimistic
locking fashion would end up in lots of retries I'm afraid. Eventually
making this strategy much more expensive.
Or am I wrong here too?
Cheers
Attila
On Sun, 7 Mar 2021, 05:20 Jeff Jirsa, <jj...@gmail.com> wrote:
>
> You can do this with conditional (CAS) updates - update ... set c=y if c=x
>
> Requires serial writes and serial reads, so a bit more expensive, but
> allows TTL.
>
>
> On Mar 6, 2021, at 8:03 AM, Attila Wind <at...@swf.technology> wrote:
>
>
>
> Hi guys,
>
> We do use Counter tables a lot because in our app we have several things
> to count (business logic)
>
> More time we work with Cassandra we keep hearing more and more: "you
> should not use counter tables because ....."
> Yes, we also feel here and there the trade off is too much restrictive -
> for us what hurts now days is that deleting counters it seems not that
> simple... Also the TTL possibility we do miss a lot.
>
> But I have to confess I do not see an obvious migration strategy here...
> What bothers me e.g.: concurrency, and wrong results thanks to that
> namely
>
> If I want to fulfill the mission "UPDATE table SET mycounter = mycounter +
> x WHERE ..." does
> with traditional table (with an int column) I need to do this:
> 1. read the value of "mycounter"
> 2. add x to the value I readc(in memory)
> 3. update mycounter = new value
>
> Needless to say that if I have a race condition so ThreadA and ThreadB are
> executing the above sequence ~ the same time then the mycounter value will
> be wrong...
>
> I started to wonder: how do you solve this problem?
> Is anyone aware of any nice post/article regarding migration strategy -
> stepping away from counters?
>
> thanks!
>
>
> --
> Attila Wind
>
> http://www.linkedin.com/in/attilaw
> Mobile: +49 176 43556932
>
>
>
Re: moving away from Counters - strategy?
Posted by Jeff Jirsa <jj...@gmail.com>.
You can do this with conditional (CAS) updates - update ... set c=y if c=x
Requires serial writes and serial reads, so a bit more expensive, but allows TTL.
> On Mar 6, 2021, at 8:03 AM, Attila Wind <at...@swf.technology> wrote:
>
>
> Hi guys,
>
> We do use Counter tables a lot because in our app we have several things to count (business logic)
>
> More time we work with Cassandra we keep hearing more and more: "you should not use counter tables because ....."
> Yes, we also feel here and there the trade off is too much restrictive - for us what hurts now days is that deleting counters it seems not that simple... Also the TTL possibility we do miss a lot.
>
> But I have to confess I do not see an obvious migration strategy here...
> What bothers me e.g.: concurrency, and wrong results thanks to that
> namely
>
> If I want to fulfill the mission "UPDATE table SET mycounter = mycounter + x WHERE ..." does
> with traditional table (with an int column) I need to do this:
> 1. read the value of "mycounter"
> 2. add x to the value I readc(in memory)
> 3. update mycounter = new value
>
> Needless to say that if I have a race condition so ThreadA and ThreadB are executing the above sequence ~ the same time then the mycounter value will be wrong...
>
> I started to wonder: how do you solve this problem?
> Is anyone aware of any nice post/article regarding migration strategy - stepping away from counters?
>
> thanks!
>
>
>
> --
> Attila Wind
>
> http://www.linkedin.com/in/attilaw
> Mobile: +49 176 43556932
>
>