Return-Path: X-Original-To: apmail-cassandra-user-archive@www.apache.org Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id D6D149FE8 for ; Mon, 10 Sep 2012 11:25:27 +0000 (UTC) Received: (qmail 92815 invoked by uid 500); 10 Sep 2012 11:25:25 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 92383 invoked by uid 500); 10 Sep 2012 11:25:23 -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 92339 invoked by uid 99); 10 Sep 2012 11:25:21 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 10 Sep 2012 11:25:21 +0000 X-ASF-Spam-Status: No, hits=2.2 required=5.0 tests=FSL_RCVD_USER,HTML_MESSAGE,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of gcdcu-cassandra-user-1@m.gmane.org designates 80.91.229.3 as permitted sender) Received: from [80.91.229.3] (HELO plane.gmane.org) (80.91.229.3) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 10 Sep 2012 11:25:14 +0000 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1TB26m-0000Mt-8Y for user@cassandra.apache.org; Mon, 10 Sep 2012 13:24:52 +0200 Received: from c-68-32-133-231.hsd1.nj.comcast.net ([68.32.133.231]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 10 Sep 2012 13:24:52 +0200 Received: from oleg.dulin by c-68-32-133-231.hsd1.nj.comcast.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 10 Sep 2012 13:24:52 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: user@cassandra.apache.org From: Oleg Dulin Subject: Re: Long-life TTL and extending TTL Date: Mon, 10 Sep 2012 07:24:35 -0400 Lines: 108 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=--------------3013833921835846298 X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: c-68-32-133-231.hsd1.nj.comcast.net User-Agent: Unison/2.1.9 This is a multi-part message in MIME format. ----------------3013833921835846298 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8bit You should create an index where you store references to your records. You can use composite column names where column name=composite(timestamp,key) then you would get a slice of all columns where timestamp part of the composite is >= TTL in the past, and then iterate through them and delete the items. Regards, Oleg On 2012-09-10 09:47:31 +0000, Robin Verlangen said: > Hi there, > > I'm working on a project that might want to set TTL to roughly 7 years. > However it might occur that the TTL should be reduced or extended. Is > there any way of updating the TTL without being in need of rewriting > the data back again? This would cause way to much overhead for this. > > If not, is running a Map/Reduce task on the whole�data set�the "best" > option or should I think in a difference approach for this challenge? > > My last question is regarding to a long term TTL, does this have any > negative impact on the cluster? Maybe during compaction, repair, > reading/writing? > > Best regards,� > > Robin Verlangen > Software engineer > > W http://www.robinverlangen.nl > E robin@us2.nl > > Disclaimer: The information contained in this message and attachments > is intended solely for the attention and use of the named addressee and > may be confidential. If you are not the intended recipient, you are > reminded that the information remains the property of the sender. You > must not use, disclose, distribute, copy, print or rely on this e-mail. > If you have received this message in error, please contact the sender > immediately and irrevocably delete this message and any copies. ----------------3013833921835846298 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit

You should create an index where you store references to your records. You can use composite column names where column name=composite(timestamp,key)


then you would get a slice of all columns where timestamp part of the composite is >= TTL in the past, and then iterate through them and delete the items.


Regards,

Oleg



On 2012-09-10 09:47:31 +0000, Robin Verlangen said:


Hi there,


I'm working on a project that might want to set TTL to roughly 7 years. However it might occur that the TTL should be reduced or extended. Is there any way of updating the TTL without being in need of rewriting the data back again? This would cause way to much overhead for this.


If not, is running a Map/Reduce task on the whole�data set�the "best" option or should I think in a difference approach for this challenge?


My last question is regarding to a long term TTL, does this have any negative impact on the cluster? Maybe during compaction, repair, reading/writing?


Best regards,�


Robin Verlangen

Software engineer


W http://www.robinverlangen.nl

E robin@us2.nl


Disclaimer: The information contained in this message and attachments is intended solely for the attention and use of the named addressee and may be confidential. If you are not the intended recipient, you are reminded that the information remains the property of the sender. You must not use, disclose, distribute, copy, print or rely on this e-mail. If you have received this message in error, please contact the sender immediately and irrevocably delete this message and any copies.




----------------3013833921835846298--