From user-return-36612-apmail-cassandra-user-archive=cassandra.apache.org@cassandra.apache.org Wed Sep 18 14:38:04 2013 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 A31521072C for ; Wed, 18 Sep 2013 14:38:04 +0000 (UTC) Received: (qmail 47124 invoked by uid 500); 18 Sep 2013 14:38:02 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 47103 invoked by uid 500); 18 Sep 2013 14:38:01 -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 47093 invoked by uid 99); 18 Sep 2013 14:38:01 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 18 Sep 2013 14:38:01 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of chris.wirt@struq.com designates 74.125.83.42 as permitted sender) Received: from [74.125.83.42] (HELO mail-ee0-f42.google.com) (74.125.83.42) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 18 Sep 2013 14:37:53 +0000 Received: by mail-ee0-f42.google.com with SMTP id b45so3567344eek.1 for ; Wed, 18 Sep 2013 07:37:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :content-type:thread-index:content-language; bh=AvvxJx68iA+LKYfsGxCnTqQfoDLBalkrcqXC5nGbSXc=; b=DWuiUvIYDFDUz+ZflN5Tf82QJjVnZyLxr1XwcWSvonyQpJuwG6ASWrlbIRJ700xI/g JVVoU8CxLRkcFm587Xlp6aZ6MEPHgKTyMQYT1mphi0IUq+4qrqREu14rZA2k68Qa5+JA kK5JyZA76xr9MZrxEGhd5RRRzw+VxOUJjYyfegsweDDHFBHSVboD1kE9N1gMPVJj8aKh NLRe6uXyb5WXJKY1SvvXmOzS2l5V+muDqkUEdXYeql5j4YYMGUnbiGQRlqwmMtaW9Tp9 6KNs/mMCOGqzbwBbsL2uT0oniS+/VzEQlPGxBhaZJMiDb5XxOrtOWd88HGRk0An5cGDl Z/9g== X-Gm-Message-State: ALoCoQkMFJqPEfvyuWaMxuoM0/8beWKpXVBA+8nsox8gbxGfuX/W/eFPNvt2zoTT2sGGl4MyPtBT X-Received: by 10.15.76.73 with SMTP id m49mr1768486eey.91.1379514592172; Wed, 18 Sep 2013 07:29:52 -0700 (PDT) Received: from StevePereiraPC (host81-133-200-21.in-addr.btopenworld.com. [81.133.200.21]) by mx.google.com with ESMTPSA id b45sm3243318eef.4.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 18 Sep 2013 07:29:51 -0700 (PDT) From: "Christopher Wirt" To: Subject: TTL and gc_grace_Seconds Date: Wed, 18 Sep 2013 15:29:50 +0100 Message-ID: <013c01ceb47b$893d5c00$9bb81400$@struq.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_013D_01CEB483.EB034AA0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac60eVLcd0uv56OiSMaDmD8COpOZMQ== Content-Language: en-gb X-Virus-Checked: Checked by ClamAV on apache.org This is a multipart message in MIME format. ------=_NextPart_000_013D_01CEB483.EB034AA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I have a column family contains time series events, all columns have a 24 hour TTL and gc_grace_seconds is currently 20 days. There is a TimeUUID in part of the key. It takes 15 days to repair the entire ring. Consistency is not my main worry. Speed is. We currently write to this CF at LOCAL_QUORUM and read at ONE. Is there any reason to have gc_grace_seconds higher than the TTL? Feels like I'm just wasting resources all over given my consistency and speed requirements. Second question. Does anyone vary their read repair ratio throughout the day.. i.e. at peak turn off read repairs, turn to 0.7 for the grave yard shift. Cheers, Chris ------=_NextPart_000_013D_01CEB483.EB034AA0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have a = column family contains time series events, all columns have a 24 hour = TTL and gc_grace_seconds is currently 20 days. There is a TimeUUID in = part of the key.

 

It takes 15 = days to repair the entire ring.

 

Consistency = is not my main worry. Speed is. We currently write to this CF at = LOCAL_QUORUM and read at ONE.

 

Is there any = reason to have gc_grace_seconds higher than the TTL? Feels like = I’m just wasting resources all over given my consistency and speed = requirements.

 

 

Second = question.

Does anyone vary their read = repair ratio throughout the day.. i.e. at peak turn off read repairs, = turn to 0.7 for the grave yard shift.

 

 

Cheers,

Chris

------=_NextPart_000_013D_01CEB483.EB034AA0--