Retrieve counter value after update

[ziju feng <pk...@gmail.com>]

Hi All,

I was wondering if there is a planned feature in Cassandra to return the
current counter value after the update statement?

Our project is using counter column to count and since counter column
cannot reside in the same table with regular columns, we have to
denormalize the counter value as integer into other tables that need to
display the value.

Our current way of denormalization is to read the current value and
writetime from the counter table after the update and then batch update
other tables with the value and timestamp (to resolve wrtie conflict).

I don't know if this is a common requirement but I think if update to
counter table can return the current value and timestamp (or counter column
can reside in regular table in the first place), we can save this extra
read, which can reduce cluster load and update latency.

Thanks,

Ziju

Re: Retrieve counter value after update

[DuyHai Doan <do...@gmail.com>]

Hello Ziju

 First, you can read this excellent blog post explaining how counters work
under the hood:
http://www.datastax.com/dev/blog/whats-new-in-cassandra-2-1-a-better-implementation-of-counters

 Now, considering your request, you'd like Cassandra to return the current
counter value on update. It would require reading local shard (already done
in 2.1) and remote shards upon update to return the "current" counter
value. It sound like distributed read-after-write and I'm not sure it's a
good idea performance-wise...

Regards


On Thu, May 29, 2014 at 9:47 PM, ziju feng <pk...@gmail.com> wrote:

> Hi All,
>
> I was wondering if there is a planned feature in Cassandra to return the
> current counter value after the update statement?
>
> Our project is using counter column to count and since counter column
> cannot reside in the same table with regular columns, we have to
> denormalize the counter value as integer into other tables that need to
> display the value.
>
> Our current way of denormalization is to read the current value and
> writetime from the counter table after the update and then batch update
> other tables with the value and timestamp (to resolve wrtie conflict).
>
> I don't know if this is a common requirement but I think if update to
> counter table can return the current value and timestamp (or counter column
> can reside in regular table in the first place), we can save this extra
> read, which can reduce cluster load and update latency.
>
> Thanks,
>
> Ziju
>