cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From aaron morton <aa...@thelastpickle.com>
Subject Re: expiring + counter column?
Date Sun, 29 May 2011 10:45:20 GMT
Without commenting on the other parts of the design, this part is not possible "attempts to
add to a dead counter throws an exception "

All write operations are no look operations (write to the log, update memtables) we never
look at the SSTables. It goes against the architecture of the write path to require a read
from disk. 

Cheers
 
-----------------
Aaron Morton
Freelance Cassandra Developer
@aaronmorton
http://www.thelastpickle.com

On 29 May 2011, at 20:04, Yang wrote:

> 
> sorry in the notation, instead of "ttl" I mean "timestamp"
> 
> 
> On Sun, May 29, 2011 at 12:24 AM, Yang <teddyyyy123@gmail.com> wrote:
> sorry to beat on the dead horse.
> 
> I looked at the link referred from #2103 : https://issues.apache.org/jira/browse/CASSANDRA-2101
> I agree with the reasoning in #2101 that the ultimate issue is that delete and counter
adds are not commutative. since by definition we can't achieve 
> predictable behavior with deletes + counter, can we redefine the behavior of counter
deletes, so that we can always guarantee the declared behavior? --- specifically:
> 
> 
> we define that once a counter column is deleted, you can never add to it again.  attempts
to add to a dead counter throws an exception  ---- all future adds are just ignored.  i.e.
a counter column has only one life, until all tombstones are purged from system, after which
it is possible for the counter  to have a new incarnation.  basically instead of solving the
problem raised in #2103, we declare openly that it's unsolvable (which is true), and make
the code reflect this fact.
> 
> 
> 
> I think this behavior would satisfy most use cases of counters. so instead of relying
on the advice to developers: "do not do updates for a period after deletes, otherwise it probably
wont' work", we enforce this into the code. 
> 
> 
> the same logic can be carried over into expiring column, since they are essentially automatically
inserted deletes. that way #2103 could be "solved"
> 
> 
> I'm attaching an example below, you can refer to them if needed.
> 
> Thanks  a lot
> Yang
> 
> 
> example:
> for simplicity we assume there is only one column family , one column, so we omit column
name and cf name in our notation, assume all counterColumns have a delta value of 1, we only
mark their ttl now. so c(123) means a counter column of ttl=1, adding a delta of 1. d(456)
means a tombstone with ttl=456. 
> 
> then we can have the following operations
> 
> operation                    result after operation
> ----------------------------------------------------------------------
> c(1)                            count=1
> d(2)                            count = null ( counter not present )                
  
> c(3)                            count = null ( add on dead counter ignored)
> ---------------------------------------------------
> 
> 
> if the 2 adds arrive out of order ,  we would still guarantee eventual consistency:
> 
> operation                    result after operation
> --------------------------------------------------------------------------------
> c(1)                            count=1
> c(3)                            count=2   (we have 2 adds, each with delta=1)
> d(2)                            count=null (deleted)
> --------------------------------------------------------------
> at the end of both scenarios, the result is guaranteed to be null;
> note that in the second scenario, line 2 shows a snapshot where we have a state with
count=2, which scenario 1 never sees this. this is fine, since even regular columns can have
this situation (just consider if the counter columns were inserts/overwrites instead )
> 
> 
> 
> On Fri, May 27, 2011 at 5:57 PM, Jonathan Ellis <jbellis@gmail.com> wrote:
> > No. See comments to https://issues.apache.org/jira/browse/CASSANDRA-2103
> >
> > On Fri, May 27, 2011 at 7:29 PM, Yang <teddyyyy123@gmail.com> wrote:
> >> is this combination feature available , or on track ?
> >>
> >> thanks
> >> Yang
> >>
> >
> >
> >
> > --
> > Jonathan Ellis
> > Project Chair, Apache Cassandra
> > co-founder of DataStax, the source for professional Cassandra support
> > http://www.datastax.com
> >
> 
> 


Mime
View raw message