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 <pkdog...@gmail.com> 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? > >
