cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yang <teddyyyy...@gmail.com>
Subject Re: expiring + counter column?
Date Sun, 29 May 2011 08:04:49 GMT
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