Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>[Update] Looks like counter support will be ready for primetime in 0.8!</p> <p>I definitely wouldn't use get_count, as that is an O(n) operation which is ran every time you read the "counter." Worse than it being just O(n) it may span multiple nodes which would introduce network latency. And finally, why tie up all that disk space when all you care about is a single number?</p> <p>For right now, I wouldn't use Cassandra for counters at all. They are working on this functionality, but it's not ready for prime time yet.</p> <p><a href="https://issues.apache.org/jira/browse/CASSANDRA-1072" rel="nofollow noreferrer">https://issues.apache.org/jira/browse/CASSANDRA-1072</a></p> <p>You've got a few options in the mean time.</p> <p>1) (Bad) Store your count in a single record and have one and only one thread of your application be responsible for counter management.</p> <p>2) (Better) Split the counter into n shards, and have n threads manage each shard as a separate counter. You can randomize which thread is used by your app each time for stateless load balancing across these threads. Just make sure that each thread is responsible for exactly one shard.</p> <p>3a) (Best) Use a separate tool that is either transactional (aka an RDBMS) or that supports atomic increment operations (memcached, redis).</p> <p>[Update.2] I would avoid using a distributed lock (see memcached and zookeeper mutexes), as this is very intolerant to node failure or network partitioning if improperly implemented.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload