Return-Path: Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: (qmail 87526 invoked from network); 8 Feb 2011 16:39:49 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 8 Feb 2011 16:39:49 -0000 Received: (qmail 91808 invoked by uid 500); 8 Feb 2011 16:39:47 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 91670 invoked by uid 500); 8 Feb 2011 16:39:44 -0000 Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@cassandra.apache.org Delivered-To: mailing list user@cassandra.apache.org Received: (qmail 91661 invoked by uid 99); 8 Feb 2011 16:39:44 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 08 Feb 2011 16:39:44 +0000 X-ASF-Spam-Status: No, hits=2.2 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [209.85.213.172] (HELO mail-yx0-f172.google.com) (209.85.213.172) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 08 Feb 2011 16:39:36 +0000 Received: by yxt33 with SMTP id 33so2635044yxt.31 for ; Tue, 08 Feb 2011 08:39:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.236.103.145 with SMTP id f17mr4613352yhg.47.1297183147513; Tue, 08 Feb 2011 08:39:07 -0800 (PST) Received: by 10.147.41.10 with HTTP; Tue, 8 Feb 2011 08:39:07 -0800 (PST) X-Originating-IP: [88.183.33.171] In-Reply-To: References: Date: Tue, 8 Feb 2011 17:39:07 +0100 Message-ID: Subject: Re: time to live rows From: Sylvain Lebresne To: user@cassandra.apache.org Content-Type: multipart/alternative; boundary=0023547c9023b8aa81049bc7fc80 X-Virus-Checked: Checked by ClamAV on apache.org --0023547c9023b8aa81049bc7fc80 Content-Type: text/plain; charset=ISO-8859-1 Not very logically, It's actually gc_grace, not gc_grace_seconds in the CLI. On Tue, Feb 8, 2011 at 5:34 PM, Kallin Nagelberg wrote: > I'm trying to set the gc_grace_seconds column family parameter but no > luck.. I got the name of it from the comment in cassandra.yaml: > > # - gc_grace_seconds: specifies the time to wait before garbage > # collecting tombstones (deletion markers). defaults to 864000 (10 > # days). See http://wiki.apache.org/cassandra/DistributedDeletes > > create column family Session > with comparator = UTF8Type > and keys_cached = 10000 > and memtable_flush_after = 1440 > and memtable_throughput = 32 > and gc_grace_seconds = 60; > > error is 'No enum const class > > org.apache.cassandra.cli.CliUserHelp$ColumnFamilyArgument.GC_GRACE_SECONDS'. > > Thanks, > -Kal > > On Tue, Feb 8, 2011 at 11:02 AM, Sylvain Lebresne > wrote: > >> I hope you don't consider this a hijack of the thread... > >> > >> What I'd like to know is the following: > >> > >> The GC removes TTL rows some time after they expire, at its convenience. > >> But will they stop being returned as soon as they expire? (This is the > >> expected behavior...) > > > > It is the individual column that have TTL. When a column expires, it > becomes > > a delete tombstone. Now, a row with tombstones (even only them) will show > > during range request. But the explanation is > > here: http://wiki.apache.org/cassandra/FAQ#range_ghosts > > > >> > >> On Tue, Feb 8, 2011 at 5:11 PM, Kallin Nagelberg > >> wrote: > >>> > >>> So the empty row will be ultimately removed then? Is there a way to > >>> for the GC to verify this? > >>> > >>> Thanks, > >>> -Kal > >>> > >>> On Tue, Feb 8, 2011 at 2:21 AM, Stu Hood wrote: > >>> > The expired columns were converted into tombstones, which will live > for > >>> > the > >>> > GC timeout. The "empty" row will be cleaned up when those tombstones > >>> > are > >>> > removed. > >>> > Returning the empty row is unfortunate... we'd love to find a more > >>> > appropriate solution that might not involve endless scanning. > >>> > See > >>> > http://wiki.apache.org/cassandra/FAQ#i_deleted_what_gives > >>> > http://wiki.apache.org/cassandra/FAQ#range_ghosts > >>> > > >>> > On Mon, Feb 7, 2011 at 1:49 PM, Kallin Nagelberg > >>> > wrote: > >>> >> > >>> >> I also tried forcing a major compaction on the column family using > JMX > >>> >> but the row remains. > >>> >> > >>> >> On Mon, Feb 7, 2011 at 4:43 PM, Kallin Nagelberg > >>> >> wrote: > >>> >> > I tried that but I still see the row coming back on a list > >>> >> > in the CLI. My concern is that there will be a > >>> >> > pointer > >>> >> > to an empty row for all eternity. > >>> >> > > >>> >> > -Kal > >>> >> > > >>> >> > On Mon, Feb 7, 2011 at 4:38 PM, Aaron Morton > >>> >> > > >>> >> > wrote: > >>> >> >> Deleting all the columns in a row via TTL has the same affect as > >>> >> >> deleting th > >>> >> >> row, the data will physically by removed during compaction. > >>> >> >> > >>> >> >> Aaron > >>> >> >> > >>> >> >> > >>> >> >> On 08 Feb, 2011,at 10:24 AM, Bill Speirs > >>> >> >> wrote: > >>> >> >> > >>> >> >> I don't think this is supported (but I could be completely > wrong). > >>> >> >> However, I'd love to see this functionality as well. > >>> >> >> > >>> >> >> How would one go about requesting such a feature? > >>> >> >> > >>> >> >> Bill- > >>> >> >> > >>> >> >> On Mon, Feb 7, 2011 at 4:15 PM, Kallin Nagelberg > >>> >> >> wrote: > >>> >> >>> Hey, > >>> >> >>> > >>> >> >>> I have read about the new TTL columns in Cassandra 0.7. In my > case > >>> >> >>> I'd > >>> >> >>> like to expire an entire row automatically after a certain > amount > >>> >> >>> of > >>> >> >>> time. Is this possible as well? > >>> >> >>> > >>> >> >>> Thanks, > >>> >> >>> -Kal > >>> >> >>> > >>> >> >> > >>> >> > > >>> > > >>> > > >> > > > > > --0023547c9023b8aa81049bc7fc80 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Not very logically,=A0It's actually gc_grace, not gc_grace_seconds= in the CLI.


On Tue= , Feb 8, 2011 at 5:34 PM, Kallin Nagelberg <kallin.nagelberg@gmail.com> wrote:
I'm trying to set the gc_grace_seconds = column family parameter but no
luck.. I got the name of it from the comment in cassandra.yaml:

# =A0 =A0 - gc_grace_seconds: specifies the time to wait before garbage
# =A0 =A0 =A0 =A0collecting tombstones (deletion markers). defaults to 8640= 00 (10
# =A0 =A0 =A0 =A0days). See http://wiki.apache.org/cassandra/Distrib= utedDeletes

create column family Session
=A0 =A0with comparator =3D UTF8Type
=A0 =A0and keys_cached =3D 10000
=A0 =A0and memtable_flush_after =3D 1440
=A0 =A0and memtable_throughput =3D 32
=A0 =A0 =A0 =A0and gc_grace_seconds =3D 60;

error is 'No enum const class
org.apache.cassandra.cli.CliUserHelp$ColumnFamilyArgument.GC_GRACE_SECONDS&= #39;.

Thanks,
-Kal

On Tue, Feb 8, 2011 at 11:02 AM, Sylvain Lebresne <sylvain@datastax.com> wrote:
>> I hope you don't consider this a hijack of the thread...
>>
>> What I'd like to know is the following:
>>
>> The GC removes TTL rows some time after they expire, at its conven= ience.
>> But will they stop being returned as soon as they expire? (This is= the
>> expected behavior...)
>
> It is the individual column that have TTL. When a column expires, it b= ecomes
> a delete tombstone. Now, a row with tombstones (even only them) will s= how
> during range request. But the explanation is
> here:=A0http://wiki.apache.org/cassandra/FAQ#range_ghosts
>
>>
>> On Tue, Feb 8, 2011 at 5:11 PM, Kallin Nagelberg
>> <kallin.nagelberg= @gmail.com> wrote:
>>>
>>> So the empty row will be ultimately removed then? Is there a w= ay to
>>> for the GC to verify this?
>>>
>>> Thanks,
>>> -Kal
>>>
>>> On Tue, Feb 8, 2011 at 2:21 AM, Stu Hood <stuhood@gmail.com> wrote:
>>> > The expired columns were converted into tombstones, which= will live for
>>> > the
>>> > GC timeout. The "empty" row will be cleaned up = when those tombstones
>>> > are
>>> > removed.
>>> > Returning the empty row is unfortunate... we'd love t= o find a more
>>> > appropriate solution that might not involve endless scann= ing.
>>> > See
>>> > http://wiki.apache.org/cassandra/FAQ#i_delet= ed_what_gives
>>> > http://wiki.apache.org/cassandra/FAQ#range_ghosts
>>> >
>>> > On Mon, Feb 7, 2011 at 1:49 PM, Kallin Nagelberg
>>> > <kallin.= nagelberg@gmail.com> wrote:
>>> >>
>>> >> I also tried forcing a major compaction on the column= family using JMX
>>> >> but the row remains.
>>> >>
>>> >> On Mon, Feb 7, 2011 at 4:43 PM, Kallin Nagelberg
>>> >> <kal= lin.nagelberg@gmail.com> wrote:
>>> >> > I tried that but I still see the row coming back= on a list
>>> >> > <columnfamily> in the CLI. My concern is t= hat there will be a
>>> >> > pointer
>>> >> > to an empty row for all eternity.
>>> >> >
>>> >> > -Kal
>>> >> >
>>> >> > On Mon, Feb 7, 2011 at 4:38 PM, Aaron Morton
>>> >> > <a= aron@thelastpickle.com>
>>> >> > wrote:
>>> >> >> Deleting all the columns in a row via TTL ha= s the same affect as
>>> >> >> deleting th
>>> >> >> row, the data will physically by removed dur= ing compaction.
>>> >> >>
>>> >> >> Aaron
>>> >> >>
>>> >> >>
>>> >> >> On 08 Feb, 2011,at 10:24 AM, Bill Speirs <= ;bill.speirs@gmail.com>
>>> >> >> wrote:
>>> >> >>
>>> >> >> I don't think this is supported (but I c= ould be completely wrong).
>>> >> >> However, I'd love to see this functional= ity as well.
>>> >> >>
>>> >> >> How would one go about requesting such a fea= ture?
>>> >> >>
>>> >> >> Bill-
>>> >> >>
>>> >> >> On Mon, Feb 7, 2011 at 4:15 PM, Kallin Nagel= berg
>>> >> >> <kallin.nagelberg@gmail.com> wrote:
>>> >> >>> Hey,
>>> >> >>>
>>> >> >>> I have read about the new TTL columns in= Cassandra 0.7. In my case
>>> >> >>> I'd
>>> >> >>> like to expire an entire row automatical= ly after a certain amount
>>> >> >>> of
>>> >> >>> time. Is this possible as well?
>>> >> >>>
>>> >> >>> Thanks,
>>> >> >>> -Kal
>>> >> >>>
>>> >> >>
>>> >> >
>>> >
>>> >
>>
>
>

--0023547c9023b8aa81049bc7fc80--