Retrieve counter value after update

[ziju feng]

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

[DuyHai Doan]

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

Post by ziju feng
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