Hi Utku,
If I'm not mistaken, I think for this case redis would be a good use case
for keeping counters. The actual data is (I believe) still being stored In
Cassandra. The data could be copied out of redis back into Cassandra every
night / hour / minute depending on the users need, and removed f
Hi Benjamin, as far as I know both memcache and redis does not support range
queries on keys. So it would be really hard to update the cassandra columns
reading from these and then updating them to cassandra.
On Thu, Jul 1, 2010 at 3:57 AM, Benjamin Black wrote:
> ZK is way overkill for counters
ZK is way overkill for counters. memcache and redis are much better at the job.
On Tue, Jun 29, 2010 at 12:32 PM, Jonathan Shook wrote:
> Until then, a pragmatic solution, however undesirable, would be to
> only have a single logical thread/task/actor that is allowed to
> read,modify,update. If
Until then, a pragmatic solution, however undesirable, would be to
only have a single logical thread/task/actor that is allowed to
read,modify,update. If this doesn't work for your application, then a
(distributed) lock manager may be used until such time that you can
take it out. Some are using Zo
On Tue, Jun 29, 2010 at 9:42 AM, Utku Can Topçu wrote:
> Hey Guys,
>
> Currently in a project I'm involved in, I need to have some columns holding
> incremented data.
> The easy approach for implementing a counter with increments is right now as
> I figured out is "read -> increment -> insert" how
