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 E2193DEC6 for ; Sat, 15 Sep 2012 18:52:44 +0000 (UTC) Received: (qmail 2926 invoked by uid 500); 15 Sep 2012 18:52:42 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 2905 invoked by uid 500); 15 Sep 2012 18:52:42 -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 2896 invoked by uid 99); 15 Sep 2012 18:52:42 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 15 Sep 2012 18:52:42 +0000 X-ASF-Spam-Status: No, hits=2.2 required=5.0 tests=FSL_RCVD_USER,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [209.85.220.172] (HELO mail-vc0-f172.google.com) (209.85.220.172) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 15 Sep 2012 18:52:37 +0000 Received: by vcbfo14 with SMTP id fo14so6584687vcb.31 for ; Sat, 15 Sep 2012 11:52:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=eDK9ULdozGA43VOEEaQbuY5aw0DAfb7GiK7cWoTLQJ0=; b=of9NAC3441Tp12lWs156pm5R+241ccv6vkDkkfsgclQxtIVDbYdioJTswtvz3TuLnC YfNHShnmL3N6BdwTgaUdMckWVOyr8qqoSFPb2SCfYM9+HkGhwdfO5mp9weqxWuYKw5sr CtG+P7osH4hQu4el75s84e65JV+Rfkeh/yWubyP4JPVslmRRmSNILHv5zD60KqpR65/N p2SmRfKw09N4O3lViJlsyrqailpdJR+626PaRqxa2EGvZGSrFATJAJJ6EMUvNFl7g2X8 q2V7w9wB66NvDblB+GDrU9RwnVSpX3lkgttXMiSE11bpq4wQ7WoYa2rBWMlSr7ra+VA2 03tA== MIME-Version: 1.0 Received: by 10.52.92.11 with SMTP id ci11mr1389549vdb.7.1347735135254; Sat, 15 Sep 2012 11:52:15 -0700 (PDT) Received: by 10.58.64.100 with HTTP; Sat, 15 Sep 2012 11:52:15 -0700 (PDT) In-Reply-To: References: Date: Sat, 15 Sep 2012 20:52:15 +0200 Message-ID: Subject: Re: Long-life TTL and extending TTL From: Robin Verlangen To: user@cassandra.apache.org Content-Type: multipart/alternative; boundary=20cf3071ce0afcfa3c04c9c20996 X-Gm-Message-State: ALoCoQk41L1q707F+LGGZkkvyZ0g56LgI9xKmvDVghxybUOexRYMsR61kVSoDzrwBw3Ghb83af4e X-Virus-Checked: Checked by ClamAV on apache.org --20cf3071ce0afcfa3c04c9c20996 Content-Type: text/plain; charset=ISO-8859-1 Hi Sergey, That's exactly what I mean. I really hope that this will get released soon! 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. 2012/9/15 Sergey Tryuber > Hi Robin, > > We have the same headache and hope that > https://issues.apache.org/jira/browse/CASSANDRA-3974 will be a balsam. > > > On 10 September 2012 13:47, Robin Verlangen wrote: > >> 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. >> >> > --20cf3071ce0afcfa3c04c9c20996 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Sergey,

That's exactly what I mean. I really hope= that this will get released soon!

Best regards= ,=A0

Robin Verlangen
Software engineer<= /i>


= Disclaimer: The information contained in this messa= ge and attachments is intended solely for the attention and use of the name= d 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 imme= diately and irrevocably delete this message and any copies.



2012/9/15 Sergey Tryuber <stryuber@gma= il.com>
Hi Robin,

We have the same headache and hope that https://is= sues.apache.org/jira/browse/CASSANDRA-3974 will be a balsam.


On 10 September 2012 13:47, Robin Verlangen <robin@us2.nl> wrot= e:
Hi there,

I'm working on a project that might want t= o 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 overhe= ad for this.

If not, is running a Map/Reduce task on the whole=A0dat= a set=A0the "best" option or should I think in a difference appro= ach for this challenge?

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

Best regards,=A0

Robin Verlan= gen
Software engineer

W http://www.robinve= rlangen.nl
E robin@us2.nl

Disclaimer: The information= contained in this message and attachments is intended solely for the atten= tion 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.



--20cf3071ce0afcfa3c04c9c20996--