cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From DuyHai Doan <>
Subject Re: Store counter with non-counter column in the same column family?
Date Mon, 22 Dec 2014 11:58:09 GMT
It's not possible to mix counter and non counter columns because currently
the semantic of counter is only increment/decrement (thus NOT idempotent)
and requires some special handling compared to other C* columns.

On Mon, Dec 22, 2014 at 11:33 AM, ziju feng <> wrote:

> ​I was wondering if there is plan to allow ​creating counter column and
> standard column in the same table.
> Here is my use case:
> I want to use counter to count how many users like a given item in my
> application. The like count needs to be returned along with details of item
> in query. To support querying items in different ways, I use both
> application-maintained denormalized index tables and DSE search for
> indexing. (DSE search is also used for text searching)
> Since current counter implementation doesn't allow having counter columns
> and non-counter columns in the same table, I have to propagate the current
> count from counter table to the main item table and index tables, so that
> like counts can be returned by those index tables without sending extra
> requests to counter table and DSE search is able to build index on like
> count column in the main item table to support like count related queries
> (such as sorting by like count).
> IMHO, the only way to sync data between counter table and normal table
> within a reasonable time (sub-seconds) currently is to read the current
> value from counter table right after the update. However it suffers from
> several issues:
> 1. Read-after-write may not return the correct count when replication
> factor > 1 unless consistency level ALL/LOCAL_ALL is used
> 2. There are two extra non-parallelizable round-trips between the
> application server and cassandra, which can have great impact on
> performance.
> If it is possible to store counter in standard column family, only one
> write will be needed to update like count in the main table. Counter value
> will also be eventually synced between replicas so that there is no need
> for application to use extra mechanism like scheduled task to get the
> correct counts.
> A related issue is lifting the limitation of not allowing updating counter
> columns and normal columns in one batch, since it is quite common to not
> only have a counter for statistics but also store the details, such as
> storing the relation of which user likes which items in my user case.
> Any idea?

View raw message