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 54EF61193A for ; Thu, 22 May 2014 15:29:08 +0000 (UTC) Received: (qmail 84846 invoked by uid 500); 22 May 2014 15:29:06 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 84815 invoked by uid 500); 22 May 2014 15:29:06 -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 84807 invoked by uid 99); 22 May 2014 15:29:06 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 22 May 2014 15:29:06 +0000 X-ASF-Spam-Status: No, hits=3.5 required=5.0 tests=HTML_MESSAGE,SPF_PASS,URI_HEX X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of Andreas.Finke@solvians.com designates 193.239.19.162 as permitted sender) Received: from [193.239.19.162] (HELO mail.solvians.com) (193.239.19.162) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 22 May 2014 15:29:03 +0000 Received: from mail.solvians.com (msex-01-fra9.corp.solvians.com [192.168.48.81]) by mail.solvians.com (Postfix) with ESMTPS id 3E6B38EC for ; Thu, 22 May 2014 15:28:40 +0000 (UTC) Received: from MSEX-02-FRA9.corp.solvians.com ([fe80::a0bb:5919:1b34:a7a1]) by MSEX-01-FRA9.corp.solvians.com ([fe80::69fc:f8c5:fc2d:136d%13]) with mapi id 14.03.0181.006; Thu, 22 May 2014 17:28:06 +0200 From: Andreas Finke To: "user@cassandra.apache.org" Subject: RE: Can SSTables overlap with SizeTieredCompactionStrategy? Thread-Topic: Can SSTables overlap with SizeTieredCompactionStrategy? Thread-Index: AQHPc2au/vIycJSyE0OiJcUUI+3tF5tLDkgAgAAp7b6AADNrgIAACiSAgACgl4CAAKe5jg== Date: Thu, 22 May 2014 15:28:11 +0000 Message-ID: <5kcooo0ubksd0p0v8239lw1y.1400772512801@email.android.com> References: <1400506277450-7594574.post@n2.nabble.com> <1400686964125-7594627.post@n2.nabble.com> <1400707009541-7594641.post@n2.nabble.com> ,<1400743673179-7594644.post@n2.nabble.com> In-Reply-To: <1400743673179-7594644.post@n2.nabble.com> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_5kcooo0ubksd0p0v8239lw1y1400772512801emailandroidcom_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.73 on 192.168.48.24 X-Virus-Checked: Checked by ClamAV on apache.org --_000_5kcooo0ubksd0p0v8239lw1y1400772512801emailandroidcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Phil, I found an interesting blog entry that may address your problem. http://www.datastax.com/dev/blog/optimizations-around-cold-sstables It seems that compaction is skipped for stables which so mit satisfy a cert= ain read rate. Please check. Kind regards Andreas Finke Java Developer Solvians IT-Solutions GmbH ---- Phil Luckhurst wrote ---- Definitely no TTL and records are only written once with no deletions. Phil DuyHai Doan wrote > Are you sure there is no TTL set on your data? It might explain the shrin= k > in sstable size after compaction. -- View this message in context: http://cassandra-user-incubator-apache-org.30= 65146.n2.nabble.com/Can-SSTables-overlap-with-SizeTieredCompactionStrategy-= tp7594574p7594644.html Sent from the cassandra-user@incubator.apache.org mailing list archive at N= abble.com. --_000_5kcooo0ubksd0p0v8239lw1y1400772512801emailandroidcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Phil,

I found an interesting blog entry that may address your prob= lem.

http://www.datastax.com/dev/blog/optimizations-around-c= old-sstables

It seems that compaction is skipped for stables which so mit= satisfy a certain read rate. Please check.

Kind regards

Andreas Finke
Java Developer
Solvians IT-Solutions GmbH



---- Phil Luckhurst wrote ----

Definitely no TTL and records are only written onc= e with no deletions.

Phil


DuyHai Doan wrote
> Are you sure there is no TTL set on your data? It might explain the sh= rink
> in sstable size after compaction.





--
View this message in context: http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/Can-SSTabl= es-overlap-with-SizeTieredCompactionStrategy-tp7594574p7594644.html
Sent from the cassandra-user@incubator.apache.org mailing list archive at N= abble.com.
--_000_5kcooo0ubksd0p0v8239lw1y1400772512801emailandroidcom_--