You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cassandra.apache.org by Chris Goffinet <go...@digg.com> on 2009/11/04 22:32:54 UTC
Incr/Decr Counters in Cassandra
Hey,
At Digg we've been thinking about counters in Cassandra. In a lot of
our use cases we need this type of support from a distributed storage
system. Anyone else out there who has such needs as well? Zookeeper
actually has such support and we might use that if we can't get the
support in Cassandra.
---
Chris Goffinet
goffinet@digg.com
Re: Incr/Decr Counters in Cassandra
Posted by Jonathan Mischo <jm...@quagility.com>.
Hey Chris,
I've been thinking along the same lines. I've got multiple
applications for counters where they'd be a lot faster as a single
operation than as a fetch and update chain. If you implement it, the
key is to have the ability to not just outright increment or
decrement, but also be able to have ops for "retrieve and increment"
and "retrieve and decrement".
-Jon
On Nov 4, 2009, at 3:32 PM, Chris Goffinet wrote:
> Hey,
>
> At Digg we've been thinking about counters in Cassandra. In a lot of
> our use cases we need this type of support from a distributed
> storage system. Anyone else out there who has such needs as well?
> Zookeeper actually has such support and we might use that if we
> can't get the support in Cassandra.
>
> ---
> Chris Goffinet
> goffinet@digg.com
>
>
>
>
>
Re: Cassandra latency question
Posted by Jonathan Ellis <jb...@gmail.com>.
something is screwed up if writes are 10x slower than reads
On Mon, Mar 8, 2010 at 5:52 PM, David Dabbs <dm...@gmail.com> wrote:
>
> Hello. I've been running the vPork load generator against two Cassandra
> nodes running in VMs.
> I'm running a trunk build with W=2 and R=1 and out-of-the-box JVM_OPTS which
> should be fine,
> or so I thought. Throughput is lower than I expected. Are my expectations
> out-of-line?
>
> Thanks,
>
> David
>
>
> Writing results to: /home/vpork/results/30-thread-pork-39
> NumThreads : 30
> Iterations : 2000
> ReadOdds : 0.8
> WriteOdds : 0.1
> RewriteOdds : 0.1
> Data Size : 24000 B
> Nodes file given: [configs/cassandra/nodes.conf]
> Attempting to read nodes file: /home/vpork/configs/cassandra/nodes.conf
> Using node: dev-a01
> Using node: dev-a02
> Testing if our store even works ...
> %0.50 num=1 rGB=0.00 wGB=0.00 rFail=0 wFail=0 notFound=0
> -------------
> Elapsed time: 2.71 sec
>
> Writes:
> Num Writes: 202
> Write Throughput: 74.54 writes / sec
> Write Failures: 0
> Write Latency: 125.78 ms
> Write Latency (%99): 454.67 ms
> Write Latency stdDev: 102.78
> Bytes Written: 4.62 MB
> Thread w/Throughput: 0.19 KB / sec
> Total w/Throughput: 1747.00 KB / sec
>
> Reads:
> Num Read: 1602
> Read Throughput: 591.14 reads / sec
> Read Failures: 0
> Read Latency: 30.57 ms
> Read Latency (%99): 273.68 ms
> Read Latency stdDev: 50.19
> Read Not Found: 29 (%1.81)
> Bytes Read: 20.19 MB
> Thread r/Throughput: 0.77 KB / sec
> Total r/Throughput: 7628.00 KB / sec
>
>
>
>
>
Cassandra latency question
Posted by David Dabbs <dm...@gmail.com>.
Hello. I've been running the vPork load generator against two Cassandra
nodes running in VMs.
I'm running a trunk build with W=2 and R=1 and out-of-the-box JVM_OPTS which
should be fine,
or so I thought. Throughput is lower than I expected. Are my expectations
out-of-line?
Thanks,
David
Writing results to: /home/vpork/results/30-thread-pork-39
NumThreads : 30
Iterations : 2000
ReadOdds : 0.8
WriteOdds : 0.1
RewriteOdds : 0.1
Data Size : 24000 B
Nodes file given: [configs/cassandra/nodes.conf]
Attempting to read nodes file: /home/vpork/configs/cassandra/nodes.conf
Using node: dev-a01
Using node: dev-a02
Testing if our store even works ...
%0.50 num=1 rGB=0.00 wGB=0.00 rFail=0 wFail=0 notFound=0
-------------
Elapsed time: 2.71 sec
Writes:
Num Writes: 202
Write Throughput: 74.54 writes / sec
Write Failures: 0
Write Latency: 125.78 ms
Write Latency (%99): 454.67 ms
Write Latency stdDev: 102.78
Bytes Written: 4.62 MB
Thread w/Throughput: 0.19 KB / sec
Total w/Throughput: 1747.00 KB / sec
Reads:
Num Read: 1602
Read Throughput: 591.14 reads / sec
Read Failures: 0
Read Latency: 30.57 ms
Read Latency (%99): 273.68 ms
Read Latency stdDev: 50.19
Read Not Found: 29 (%1.81)
Bytes Read: 20.19 MB
Thread r/Throughput: 0.77 KB / sec
Total r/Throughput: 7628.00 KB / sec
Re: Incr/Decr Counters in Cassandra
Posted by Jonathan Ellis <jb...@gmail.com>.
On Sat, Mar 6, 2010 at 4:59 PM, simon.reavely <si...@gmail.com> wrote:
> Is there a place on the Cassandra wiki where the proposals/thinking on these
> issues has been captured in one place?
The wiki is a terrible place for proposals. Use the ML for those, and
use JIRA when you start to actually generate code.
https://issues.apache.org/jira/browse/CASSANDRA-580 is where Kelvin is
working on vector clock support, which will handle eventually
consistent increments.
There is also a zookeeper module in contrib/ that you can implement
atomic increment on top of.
> p.s. I don't want to go off on a tangent, but out of interest, given the
> original Dynamo article and comments in posts like
> this: http://www.allthingsdistributed.com/2008/12/eventually_consistent.html,
> what makes you think SimpleDB is not based on Dynamo?
SimpleDB is key/row; dynamo is key/value. SimpleDB is Erlang; dynamo
is Java. SimpleDB has a limit of 10GB/domain; there would be no need
for such a low limit if it were based on Dynamo.
-Jonathan
Re: Incr/Decr Counters in Cassandra
Posted by "simon.reavely" <si...@gmail.com>.
I am very new to Cassandra so I certainly don't have any credibility in
commenting on implementation
(FYI...reading stuff from you and other committers like Eric Evans is
certainly helping...cheers)
However, having hacked on top of DBMS's and custom in memory solutions I
think we can probably look at the following:
1. Obviously the first is availability. Thank you CAP Theorem...duh! I feel
like I need to write something deeper to maintain my credibility but instead
I'll just concur with "devil in details" and move on until I understand
Cassandra better to provide even a smidgen of help!
2. Build very specialized support for specific use-cases e.g. counters that
can be used in applications like mine where we just want to perform an
action when a threshold is exceeded. In my case we can maybe tolerate a
client being slightly out of date i.e. we can handle stale reads for
decision making, but also want to (eventually) capture every increment i.e.
the operation has to be INCR(column, incr_value) rather than
"SET(column)=new_value". Obviously this is easier since the increments can
be replayed in any order.
I noticed some similar comments and thoughts about common lock free
approaches that you've probably already reviewed:
http://www.mail-archive.com/cassandra-user@incubator.apache.org/msg01102.html
My justification for wanting some of this is really:
1. I want to minimize the number of database systems I use from a single
application. Naturally, I really need a lot of what Cassandra offers today
to get the availability and "big data" support needed in my application so
maximizing its use is a good thing as long as we avoid the "square peg,
round hole".
2. As a rule of thumb, I am not a big fan of trying to solve the difficult
problems at the expense of providing useful features that are easier to
implement in a shorter time frame.
Is there a place on the Cassandra wiki where the proposals/thinking on these
issues has been captured in one place?
Cheers,
Simon
p.s. I don't want to go off on a tangent, but out of interest, given the
original Dynamo article and comments in posts like this:
http://www.allthingsdistributed.com/2008/12/eventually_consistent.html, what
makes you think SimpleDB is not based on Dynamo?
On Sat, Mar 6, 2010 at 9:19 AM, Jonathan Ellis-3 [via
cassandra-user@incubator.apache.org] <
ml-node+4686374-1732917648-463190@n2.nabble.com<ml...@n2.nabble.com>
> wrote:
> First, SimpleDB is probably not built on Dynamo.
>
> And the devil is in the details. I haven't seen anyone propose a
> reasonable model for how Conditional Puts work (that is the tough
> one).
>
> On Sat, Mar 6, 2010 at 8:11 AM, simon.reavely <[hidden email]<http://n2.nabble.com/user/SendEmail.jtp?type=node&node=4686374&i=0>>
> wrote:
>
> >
> > Werner Vogels had a recent post around Amazon's support for primitives in
>
> > SimpleDB that can be used to build counters. Given the historical
> influences
> > from Amazon
> > s Dynamo to Cassandra I would think a similar approach might work well.
> >
> http://www.allthingsdistributed.com/2010/02/strong_consistency_simpledb.html
> >
> > BTW...I would be VERY interested in such support.
> > --
> > View this message in context:
> http://n2.nabble.com/Incr-Decr-Counters-in-Cassandra-tp3948361p4686353.html
> > Sent from the [hidden email]<http://n2.nabble.com/user/SendEmail.jtp?type=node&node=4686374&i=1>mailing list archive at Nabble.com.
> >
>
>
> ------------------------------
> View message @
> http://n2.nabble.com/Incr-Decr-Counters-in-Cassandra-tp3948361p4686374.html
> To unsubscribe from Re: Incr/Decr Counters in Cassandra, click here< (link removed) >.
>
>
>
-----
Simon Reavely
simon.reavely@gmail.com
--
View this message in context: http://n2.nabble.com/Incr-Decr-Counters-in-Cassandra-tp3948361p4688165.html
Sent from the cassandra-user@incubator.apache.org mailing list archive at Nabble.com.
Re: Incr/Decr Counters in Cassandra
Posted by Jonathan Ellis <jb...@gmail.com>.
First, SimpleDB is probably not built on Dynamo.
And the devil is in the details. I haven't seen anyone propose a
reasonable model for how Conditional Puts work (that is the tough
one).
On Sat, Mar 6, 2010 at 8:11 AM, simon.reavely <si...@gmail.com> wrote:
>
> Werner Vogels had a recent post around Amazon's support for primitives in
> SimpleDB that can be used to build counters. Given the historical influences
> from Amazon
> s Dynamo to Cassandra I would think a similar approach might work well.
> http://www.allthingsdistributed.com/2010/02/strong_consistency_simpledb.html
>
> BTW...I would be VERY interested in such support.
> --
> View this message in context: http://n2.nabble.com/Incr-Decr-Counters-in-Cassandra-tp3948361p4686353.html
> Sent from the cassandra-user@incubator.apache.org mailing list archive at Nabble.com.
>
Re: Incr/Decr Counters in Cassandra
Posted by "simon.reavely" <si...@gmail.com>.
Werner Vogels had a recent post around Amazon's support for primitives in
SimpleDB that can be used to build counters. Given the historical influences
from Amazon
s Dynamo to Cassandra I would think a similar approach might work well.
http://www.allthingsdistributed.com/2010/02/strong_consistency_simpledb.html
BTW...I would be VERY interested in such support.
--
View this message in context: http://n2.nabble.com/Incr-Decr-Counters-in-Cassandra-tp3948361p4686353.html
Sent from the cassandra-user@incubator.apache.org mailing list archive at Nabble.com.
Re: Incr/Decr Counters in Cassandra
Posted by Chris Goffinet <go...@digg.com>.
We'll be submitting patches for vector clocks soon on jira, stay tuned.
-Chris
On Mar 12, 2010, at 11:21 PM, Vijay wrote:
> Badly need it for my work let me know if i can do something to speed it up :)
>
> Regards,
> </VJ>
>
>
>
> On Wed, Nov 4, 2009 at 1:32 PM, Chris Goffinet <go...@digg.com> wrote:
> Hey,
>
> At Digg we've been thinking about counters in Cassandra. In a lot of our use cases we need this type of support from a distributed storage system. Anyone else out there who has such needs as well? Zookeeper actually has such support and we might use that if we can't get the support in Cassandra.
>
> ---
> Chris Goffinet
> goffinet@digg.com
>
>
>
>
>
>
Re: Incr/Decr Counters in Cassandra
Posted by Chris Goffinet <go...@digg.com>.
We'll be submitting patches for vector clocks soon on jira, stay tuned.
-Chris
On Mar 12, 2010, at 11:21 PM, Vijay wrote:
> Badly need it for my work let me know if i can do something to speed it up :)
>
> Regards,
> </VJ>
>
>
>
> On Wed, Nov 4, 2009 at 1:32 PM, Chris Goffinet <go...@digg.com> wrote:
> Hey,
>
> At Digg we've been thinking about counters in Cassandra. In a lot of our use cases we need this type of support from a distributed storage system. Anyone else out there who has such needs as well? Zookeeper actually has such support and we might use that if we can't get the support in Cassandra.
>
> ---
> Chris Goffinet
> goffinet@digg.com
>
>
>
>
>
>
Re: Incr/Decr Counters in Cassandra
Posted by Tim Estes <ti...@digitalreasoning.com>.
+1 over here too...
--
Tim Estes
CEO
Digital Reasoning Systems
On Mar 13, 2010, at 3:06 PM, Ryan Daum wrote:
> I also desperately need this, and row/column TTLs. Let me know if there's
> anything I can do to help with the release of either in the near-term time
> frame.
>
> R
>
> On Sat, Mar 13, 2010 at 2:21 AM, Vijay <vi...@gmail.com> wrote:
>
>> Badly need it for my work let me know if i can do something to speed it up
>> :)
>>
>> Regards,
>> </VJ>
>>
>>
>>
>> On Wed, Nov 4, 2009 at 1:32 PM, Chris Goffinet <go...@digg.com> wrote:
>>
>>> Hey,
>>>
>>> At Digg we've been thinking about counters in Cassandra. In a lot of our
>>> use cases we need this type of support from a distributed storage system.
>>> Anyone else out there who has such needs as well? Zookeeper actually has
>>> such support and we might use that if we can't get the support in
>> Cassandra.
>>>
>>> ---
>>> Chris Goffinet
>>> goffinet@digg.com
>>>
>>>
>>>
>>>
>>>
>>>
>>
Re: Incr/Decr Counters in Cassandra
Posted by Ryan Daum <ry...@thimbleware.com>.
I also desperately need this, and row/column TTLs. Let me know if there's
anything I can do to help with the release of either in the near-term time
frame.
R
On Sat, Mar 13, 2010 at 2:21 AM, Vijay <vi...@gmail.com> wrote:
> Badly need it for my work let me know if i can do something to speed it up
> :)
>
> Regards,
> </VJ>
>
>
>
> On Wed, Nov 4, 2009 at 1:32 PM, Chris Goffinet <go...@digg.com> wrote:
>
> > Hey,
> >
> > At Digg we've been thinking about counters in Cassandra. In a lot of our
> > use cases we need this type of support from a distributed storage system.
> > Anyone else out there who has such needs as well? Zookeeper actually has
> > such support and we might use that if we can't get the support in
> Cassandra.
> >
> > ---
> > Chris Goffinet
> > goffinet@digg.com
> >
> >
> >
> >
> >
> >
>
Re: Incr/Decr Counters in Cassandra
Posted by Ryan Daum <ry...@thimbleware.com>.
I also desperately need this, and row/column TTLs. Let me know if there's
anything I can do to help with the release of either in the near-term time
frame.
R
On Sat, Mar 13, 2010 at 2:21 AM, Vijay <vi...@gmail.com> wrote:
> Badly need it for my work let me know if i can do something to speed it up
> :)
>
> Regards,
> </VJ>
>
>
>
> On Wed, Nov 4, 2009 at 1:32 PM, Chris Goffinet <go...@digg.com> wrote:
>
> > Hey,
> >
> > At Digg we've been thinking about counters in Cassandra. In a lot of our
> > use cases we need this type of support from a distributed storage system.
> > Anyone else out there who has such needs as well? Zookeeper actually has
> > such support and we might use that if we can't get the support in
> Cassandra.
> >
> > ---
> > Chris Goffinet
> > goffinet@digg.com
> >
> >
> >
> >
> >
> >
>
Re: Incr/Decr Counters in Cassandra
Posted by Vijay <vi...@gmail.com>.
Badly need it for my work let me know if i can do something to speed it up
:)
Regards,
</VJ>
On Wed, Nov 4, 2009 at 1:32 PM, Chris Goffinet <go...@digg.com> wrote:
> Hey,
>
> At Digg we've been thinking about counters in Cassandra. In a lot of our
> use cases we need this type of support from a distributed storage system.
> Anyone else out there who has such needs as well? Zookeeper actually has
> such support and we might use that if we can't get the support in Cassandra.
>
> ---
> Chris Goffinet
> goffinet@digg.com
>
>
>
>
>
>
Re: Incr/Decr Counters in Cassandra
Posted by Dan Di Spaltro <da...@gmail.com>.
We would appreciate the use of counters and I think is something that
would anyone could appreciate, adding atomic operations like this
doesn't seem out of scope.
-Dan
On Wed, Nov 4, 2009 at 1:32 PM, Chris Goffinet <go...@digg.com> wrote:
> Hey,
>
> At Digg we've been thinking about counters in Cassandra. In a lot of our use
> cases we need this type of support from a distributed storage system. Anyone
> else out there who has such needs as well? Zookeeper actually has such
> support and we might use that if we can't get the support in Cassandra.
>
> ---
> Chris Goffinet
> goffinet@digg.com
>
>
>
>
>
>
--
Dan Di Spaltro
Re: Incr/Decr Counters in Cassandra
Posted by kevin <ke...@gmail.com>.
counters in cassandra will be awesome!
On Wed, Nov 4, 2009 at 1:32 PM, Chris Goffinet <go...@digg.com> wrote:
> Hey,
>
> At Digg we've been thinking about counters in Cassandra. In a lot of our
> use cases we need this type of support from a distributed storage system.
> Anyone else out there who has such needs as well? Zookeeper actually has
> such support and we might use that if we can't get the support in Cassandra.
>
> ---
> Chris Goffinet
> goffinet@digg.com
>
>
>
>
>
>
Re: Incr/Decr Counters in Cassandra
Posted by Jonathan Mischo <jm...@quagility.com>.
This is actually why retrieve and incr/decr ops are so important...you
still have your consistency level, and that drives how accurate the
returned data is, but since you're sending an operation, not
alteration of the data, there's no conflict, you just have to make
sure you don't miss an op. In this case, though, there'd have to be
an additional mechanism for the commit log, so if there was a
conflict, read repair would be able to pull a list of ops since the
last agreement, and figure out what the right value is. Highly active
counters don't work in eventually consistent models if you rely on the
client.
On Nov 4, 2009, at 3:57 PM, Stu Hood wrote:
> This type of problem is one of the primary examples of something
> that should be handled by pluggable/client-side conflict resolution
> in an eventually consistent system. Currently, all conflicts in
> Cassandra are handled with "highest timestamp wins"
>
> Rather than attempting to add atomic operations, I think we should
> support one of the following in the (near) future:
> 1) Client side resolution
> * When two writes conflict (ex: two clients simultaneously read
> the counter at "2", and then write it at "3"), the next client
> receives a callback with the old value and both new values, and can
> then do application specific resolution (ex: both clients
> incremented by "1", so use "4").
> 2) Pluggable resolution
> * When two writes conflict, pluggable logic on the server side
> decides how to merge the writes. You could implement the same
> algorithm used in the example above, but the code would have to
> exist on the server side.
>
> Personally, I think (1) is the better approach, and for backwards
> compatibility in the API, you could make the resolution optional.
>
>
> -----Original Message-----
> From: "Chris Goffinet" <go...@digg.com>
> Sent: Wednesday, November 4, 2009 3:32pm
> To: cassandra-user@incubator.apache.org
> Cc: cassandra-dev@incubator.apache.org
> Subject: Incr/Decr Counters in Cassandra
>
> Hey,
>
> At Digg we've been thinking about counters in Cassandra. In a lot of
> our use cases we need this type of support from a distributed storage
> system. Anyone else out there who has such needs as well? Zookeeper
> actually has such support and we might use that if we can't get the
> support in Cassandra.
>
> ---
> Chris Goffinet
> goffinet@digg.com
>
>
>
>
>
>
>
>
Re: Incr/Decr Counters in Cassandra
Posted by Jonathan Mischo <jm...@quagility.com>.
Sure, that's why you say in the docs, "This isn't a sequence, it's a
counter." Just because in RDBMS land sequences are safe to use that
way doesn't meaning in NRDBMS land counters have to work the same
way. Eventually consistent models don't work very well for sequences,
but counters should be just fine, unless you're using them for keys or
usage counters (which are dangerous unless you're using ALL, which is
costly).
On Nov 4, 2009, at 4:12 PM, Bill de hOra wrote:
> Christian Vest Hansen wrote:
>> Numeric addition and subtraction are commutable operations: they can
>> be performed in any order without conflict, which I think is a key
>> performance promise.
>
> Correct, but a common use case for incr/decr counting is issuing
> numeric keys, which requires a global lock or total ordering
> (something I think ZK can do). So this approach doesn't work for
> that, and people might get nasty surprises.
>
> Bill
Re: Incr/Decr Counters in Cassandra
Posted by Bill de hOra <bi...@dehora.net>.
Christian Vest Hansen wrote:
> Numeric addition and subtraction are commutable operations: they can
> be performed in any order without conflict, which I think is a key
> performance promise.
Correct, but a common use case for incr/decr counting is issuing numeric
keys, which requires a global lock or total ordering (something I think
ZK can do). So this approach doesn't work for that, and people might get
nasty surprises.
Bill
Re: Incr/Decr Counters in Cassandra
Posted by Christian Vest Hansen <ka...@gmail.com>.
Numeric addition and subtraction are commutable operations: they can
be performed in any order without conflict, which I think is a key
performance promise. So sending the computation to the data, instead
of the data to the computation is the way to go if at all possible, I
think.
Not that your conflict resolution isn't useful, I just don't see this
particular case as a good example for it :)
On Wed, Nov 4, 2009 at 10:57 PM, Stu Hood <st...@rackspace.com> wrote:
> This type of problem is one of the primary examples of something that should be handled by pluggable/client-side conflict resolution in an eventually consistent system. Currently, all conflicts in Cassandra are handled with "highest timestamp wins"
>
> Rather than attempting to add atomic operations, I think we should support one of the following in the (near) future:
> 1) Client side resolution
> * When two writes conflict (ex: two clients simultaneously read the counter at "2", and then write it at "3"), the next client receives a callback with the old value and both new values, and can then do application specific resolution (ex: both clients incremented by "1", so use "4").
> 2) Pluggable resolution
> * When two writes conflict, pluggable logic on the server side decides how to merge the writes. You could implement the same algorithm used in the example above, but the code would have to exist on the server side.
>
> Personally, I think (1) is the better approach, and for backwards compatibility in the API, you could make the resolution optional.
>
>
> -----Original Message-----
> From: "Chris Goffinet" <go...@digg.com>
> Sent: Wednesday, November 4, 2009 3:32pm
> To: cassandra-user@incubator.apache.org
> Cc: cassandra-dev@incubator.apache.org
> Subject: Incr/Decr Counters in Cassandra
>
> Hey,
>
> At Digg we've been thinking about counters in Cassandra. In a lot of
> our use cases we need this type of support from a distributed storage
> system. Anyone else out there who has such needs as well? Zookeeper
> actually has such support and we might use that if we can't get the
> support in Cassandra.
>
> ---
> Chris Goffinet
> goffinet@digg.com
>
>
>
>
>
>
>
>
--
Venlig hilsen / Kind regards,
Christian Vest Hansen.
RE: Incr/Decr Counters in Cassandra
Posted by Stu Hood <st...@rackspace.com>.
This type of problem is one of the primary examples of something that should be handled by pluggable/client-side conflict resolution in an eventually consistent system. Currently, all conflicts in Cassandra are handled with "highest timestamp wins"
Rather than attempting to add atomic operations, I think we should support one of the following in the (near) future:
1) Client side resolution
* When two writes conflict (ex: two clients simultaneously read the counter at "2", and then write it at "3"), the next client receives a callback with the old value and both new values, and can then do application specific resolution (ex: both clients incremented by "1", so use "4").
2) Pluggable resolution
* When two writes conflict, pluggable logic on the server side decides how to merge the writes. You could implement the same algorithm used in the example above, but the code would have to exist on the server side.
Personally, I think (1) is the better approach, and for backwards compatibility in the API, you could make the resolution optional.
-----Original Message-----
From: "Chris Goffinet" <go...@digg.com>
Sent: Wednesday, November 4, 2009 3:32pm
To: cassandra-user@incubator.apache.org
Cc: cassandra-dev@incubator.apache.org
Subject: Incr/Decr Counters in Cassandra
Hey,
At Digg we've been thinking about counters in Cassandra. In a lot of
our use cases we need this type of support from a distributed storage
system. Anyone else out there who has such needs as well? Zookeeper
actually has such support and we might use that if we can't get the
support in Cassandra.
---
Chris Goffinet
goffinet@digg.com
Re: Incr/Decr Counters in Cassandra
Posted by kevin <ke...@gmail.com>.
counters in cassandra will be awesome!
On Wed, Nov 4, 2009 at 1:32 PM, Chris Goffinet <go...@digg.com> wrote:
> Hey,
>
> At Digg we've been thinking about counters in Cassandra. In a lot of our
> use cases we need this type of support from a distributed storage system.
> Anyone else out there who has such needs as well? Zookeeper actually has
> such support and we might use that if we can't get the support in Cassandra.
>
> ---
> Chris Goffinet
> goffinet@digg.com
>
>
>
>
>
>
Re: Incr/Decr Counters in Cassandra
Posted by Joe Stump <jo...@joestump.net>.
SimpleGeo would be interested.
--Joe
On Nov 4, 2009, at 2:32 PM, Chris Goffinet wrote:
> Hey,
>
> At Digg we've been thinking about counters in Cassandra. In a lot of
> our use cases we need this type of support from a distributed
> storage system. Anyone else out there who has such needs as well?
> Zookeeper actually has such support and we might use that if we
> can't get the support in Cassandra.
>
> ---
> Chris Goffinet
> goffinet@digg.com
>
>
>
>
>
Re: Incr/Decr Counters in Cassandra
Posted by Ray Slakinski <ra...@mahalo.com>.
+1 for this, we currently use memcachedb for this type of counter and would
love to move off of it.
Ray
On Wed, Nov 4, 2009 at 5:09 PM, Bill de hOra <bi...@dehora.net> wrote:
> incr/decr for counters maybe doesn't fit with EC (as you might need a
> global lock for some use cases ), but plus/minus are slightly different as
> they're commutative and don't require a total ordering.
>
> Bill
>
>
> Michael Greene wrote:
>
>> This has come up before at http://markmail.org/thread/w3mrh4h64xpf3vuj
>> and http://markmail.org/message/vnmsuddlrhaziq7g
>> I am in favor of adding eventually-consistent atomic operations such
>> as this, but I'm not sure how one would implement it. Some sort of
>> UUID + bloomfilter for the individual atomic operations? I tend to
>> think "retrieve and increment" as requested by Jon is at odds with
>> eventual consistency, but maybe I'm wrong.
>>
>> Michael
>>
>> On Wed, Nov 4, 2009 at 3:51 PM, Bill de hOra <bi...@dehora.net> wrote:
>>
>>>
>>> Chris Goffinet wrote:
>>>
>>>> Hey,
>>>>
>>>> At Digg we've been thinking about counters in Cassandra. In a lot of our
>>>> use cases we need this type of support from a distributed storage
>>>> system.
>>>> Anyone else out there who has such needs as well? Zookeeper actually has
>>>> such support and we might use that if we can't get the support in
>>>> Cassandra.
>>>>
>>> I tend to need a generalization on incr/decr which is plus/minus (eg for
>>> quota management). Having these in Cassandra would be great.
>>>
>>> Bill
>>>
>>>
>
Re: Incr/Decr Counters in Cassandra
Posted by Jonathan Mischo <jm...@quagility.com>.
incr/decr actually fit with EC, since they're just add n or sub n ops
that can be replayed in any order...it's just less costly to do it as
a get and incr or get and decr than as separate operations...the only
difference between a get on the value followed by an incr is the
overhead of the additional request, so it just seems to make a lot
more sense to make it a single call. It's done in the SQL world a
lot, and it's just good form, since a lot of times you're going to see
an incr or decr tied to a get with a counter (but not
always...sometimes you'll see just a get or an incr or decr...if you
just have incr or decr return the new value, that works just as well,
and the client can decide whether or not to discard the value).
On Nov 4, 2009, at 4:09 PM, Bill de hOra wrote:
> incr/decr for counters maybe doesn't fit with EC (as you might need
> a global lock for some use cases ), but plus/minus are slightly
> different as they're commutative and don't require a total ordering.
>
> Bill
>
> Michael Greene wrote:
>> This has come up before at http://markmail.org/thread/
>> w3mrh4h64xpf3vuj
>> and http://markmail.org/message/vnmsuddlrhaziq7g
>> I am in favor of adding eventually-consistent atomic operations such
>> as this, but I'm not sure how one would implement it. Some sort of
>> UUID + bloomfilter for the individual atomic operations? I tend to
>> think "retrieve and increment" as requested by Jon is at odds with
>> eventual consistency, but maybe I'm wrong.
>> Michael
>> On Wed, Nov 4, 2009 at 3:51 PM, Bill de hOra <bi...@dehora.net> wrote:
>>>
>>> Chris Goffinet wrote:
>>>> Hey,
>>>>
>>>> At Digg we've been thinking about counters in Cassandra. In a lot
>>>> of our
>>>> use cases we need this type of support from a distributed storage
>>>> system.
>>>> Anyone else out there who has such needs as well? Zookeeper
>>>> actually has
>>>> such support and we might use that if we can't get the support in
>>>> Cassandra.
>>> I tend to need a generalization on incr/decr which is plus/minus
>>> (eg for
>>> quota management). Having these in Cassandra would be great.
>>>
>>> Bill
>>>
>
Re: Incr/Decr Counters in Cassandra
Posted by Bill de hOra <bi...@dehora.net>.
incr/decr for counters maybe doesn't fit with EC (as you might need a
global lock for some use cases ), but plus/minus are slightly different
as they're commutative and don't require a total ordering.
Bill
Michael Greene wrote:
> This has come up before at http://markmail.org/thread/w3mrh4h64xpf3vuj
> and http://markmail.org/message/vnmsuddlrhaziq7g
> I am in favor of adding eventually-consistent atomic operations such
> as this, but I'm not sure how one would implement it. Some sort of
> UUID + bloomfilter for the individual atomic operations? I tend to
> think "retrieve and increment" as requested by Jon is at odds with
> eventual consistency, but maybe I'm wrong.
>
> Michael
>
> On Wed, Nov 4, 2009 at 3:51 PM, Bill de hOra <bi...@dehora.net> wrote:
>>
>> Chris Goffinet wrote:
>>> Hey,
>>>
>>> At Digg we've been thinking about counters in Cassandra. In a lot of our
>>> use cases we need this type of support from a distributed storage system.
>>> Anyone else out there who has such needs as well? Zookeeper actually has
>>> such support and we might use that if we can't get the support in Cassandra.
>> I tend to need a generalization on incr/decr which is plus/minus (eg for
>> quota management). Having these in Cassandra would be great.
>>
>> Bill
>>
Re: Incr/Decr Counters in Cassandra
Posted by Bill de hOra <bi...@dehora.net>.
incr/decr for counters maybe doesn't fit with EC (as you might need a
global lock for some use cases ), but plus/minus are slightly different
as they're commutative and don't require a total ordering.
Bill
Michael Greene wrote:
> This has come up before at http://markmail.org/thread/w3mrh4h64xpf3vuj
> and http://markmail.org/message/vnmsuddlrhaziq7g
> I am in favor of adding eventually-consistent atomic operations such
> as this, but I'm not sure how one would implement it. Some sort of
> UUID + bloomfilter for the individual atomic operations? I tend to
> think "retrieve and increment" as requested by Jon is at odds with
> eventual consistency, but maybe I'm wrong.
>
> Michael
>
> On Wed, Nov 4, 2009 at 3:51 PM, Bill de hOra <bi...@dehora.net> wrote:
>>
>> Chris Goffinet wrote:
>>> Hey,
>>>
>>> At Digg we've been thinking about counters in Cassandra. In a lot of our
>>> use cases we need this type of support from a distributed storage system.
>>> Anyone else out there who has such needs as well? Zookeeper actually has
>>> such support and we might use that if we can't get the support in Cassandra.
>> I tend to need a generalization on incr/decr which is plus/minus (eg for
>> quota management). Having these in Cassandra would be great.
>>
>> Bill
>>
Re: Incr/Decr Counters in Cassandra
Posted by Michael Greene <mi...@gmail.com>.
This has come up before at http://markmail.org/thread/w3mrh4h64xpf3vuj
and http://markmail.org/message/vnmsuddlrhaziq7g
I am in favor of adding eventually-consistent atomic operations such
as this, but I'm not sure how one would implement it. Some sort of
UUID + bloomfilter for the individual atomic operations? I tend to
think "retrieve and increment" as requested by Jon is at odds with
eventual consistency, but maybe I'm wrong.
Michael
On Wed, Nov 4, 2009 at 3:51 PM, Bill de hOra <bi...@dehora.net> wrote:
>
>
> Chris Goffinet wrote:
>>
>> Hey,
>>
>> At Digg we've been thinking about counters in Cassandra. In a lot of our
>> use cases we need this type of support from a distributed storage system.
>> Anyone else out there who has such needs as well? Zookeeper actually has
>> such support and we might use that if we can't get the support in Cassandra.
>
> I tend to need a generalization on incr/decr which is plus/minus (eg for
> quota management). Having these in Cassandra would be great.
>
> Bill
>
Re: Incr/Decr Counters in Cassandra
Posted by Michael Greene <mi...@gmail.com>.
This has come up before at http://markmail.org/thread/w3mrh4h64xpf3vuj
and http://markmail.org/message/vnmsuddlrhaziq7g
I am in favor of adding eventually-consistent atomic operations such
as this, but I'm not sure how one would implement it. Some sort of
UUID + bloomfilter for the individual atomic operations? I tend to
think "retrieve and increment" as requested by Jon is at odds with
eventual consistency, but maybe I'm wrong.
Michael
On Wed, Nov 4, 2009 at 3:51 PM, Bill de hOra <bi...@dehora.net> wrote:
>
>
> Chris Goffinet wrote:
>>
>> Hey,
>>
>> At Digg we've been thinking about counters in Cassandra. In a lot of our
>> use cases we need this type of support from a distributed storage system.
>> Anyone else out there who has such needs as well? Zookeeper actually has
>> such support and we might use that if we can't get the support in Cassandra.
>
> I tend to need a generalization on incr/decr which is plus/minus (eg for
> quota management). Having these in Cassandra would be great.
>
> Bill
>
Re: Incr/Decr Counters in Cassandra
Posted by Bill de hOra <bi...@dehora.net>.
Chris Goffinet wrote:
> Hey,
>
> At Digg we've been thinking about counters in Cassandra. In a lot of our
> use cases we need this type of support from a distributed storage
> system. Anyone else out there who has such needs as well? Zookeeper
> actually has such support and we might use that if we can't get the
> support in Cassandra.
I tend to need a generalization on incr/decr which is plus/minus (eg for
quota management). Having these in Cassandra would be great.
Bill
Re: Incr/Decr Counters in Cassandra
Posted by Vijay <vi...@gmail.com>.
Badly need it for my work let me know if i can do something to speed it up
:)
Regards,
</VJ>
On Wed, Nov 4, 2009 at 1:32 PM, Chris Goffinet <go...@digg.com> wrote:
> Hey,
>
> At Digg we've been thinking about counters in Cassandra. In a lot of our
> use cases we need this type of support from a distributed storage system.
> Anyone else out there who has such needs as well? Zookeeper actually has
> such support and we might use that if we can't get the support in Cassandra.
>
> ---
> Chris Goffinet
> goffinet@digg.com
>
>
>
>
>
>
Re: Incr/Decr Counters in Cassandra
Posted by Bill de hOra <bi...@dehora.net>.
Chris Goffinet wrote:
> Hey,
>
> At Digg we've been thinking about counters in Cassandra. In a lot of our
> use cases we need this type of support from a distributed storage
> system. Anyone else out there who has such needs as well? Zookeeper
> actually has such support and we might use that if we can't get the
> support in Cassandra.
I tend to need a generalization on incr/decr which is plus/minus (eg for
quota management). Having these in Cassandra would be great.
Bill
Re: Incr/Decr Counters in Cassandra
Posted by Joe Stump <jo...@joestump.net>.
SimpleGeo would be interested.
--Joe
On Nov 4, 2009, at 2:32 PM, Chris Goffinet wrote:
> Hey,
>
> At Digg we've been thinking about counters in Cassandra. In a lot of
> our use cases we need this type of support from a distributed
> storage system. Anyone else out there who has such needs as well?
> Zookeeper actually has such support and we might use that if we
> can't get the support in Cassandra.
>
> ---
> Chris Goffinet
> goffinet@digg.com
>
>
>
>
>
Re: Incr/Decr Counters in Cassandra
Posted by Dan Di Spaltro <da...@gmail.com>.
We would appreciate the use of counters and I think is something that
would anyone could appreciate, adding atomic operations like this
doesn't seem out of scope.
-Dan
On Wed, Nov 4, 2009 at 1:32 PM, Chris Goffinet <go...@digg.com> wrote:
> Hey,
>
> At Digg we've been thinking about counters in Cassandra. In a lot of our use
> cases we need this type of support from a distributed storage system. Anyone
> else out there who has such needs as well? Zookeeper actually has such
> support and we might use that if we can't get the support in Cassandra.
>
> ---
> Chris Goffinet
> goffinet@digg.com
>
>
>
>
>
>
--
Dan Di Spaltro