Return-Path: 
 <user-return-41002-apmail-cassandra-user-archive=cassandra.apache.org@cassandra.apache.org>
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 6B0A211E9D
	for <apmail-cassandra-user-archive@www.apache.org>;
 Wed,  4 Jun 2014 17:57:02 +0000 (UTC)
Received: (qmail 57862 invoked by uid 500); 4 Jun 2014 17:56:58 -0000
Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org
Received: (qmail 57816 invoked by uid 500); 4 Jun 2014 17:56:58 -0000
Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:user-help@cassandra.apache.org>
List-Unsubscribe: <mailto:user-unsubscribe@cassandra.apache.org>
List-Post: <mailto:user@cassandra.apache.org>
List-Id: <user.cassandra.apache.org>
Reply-To: user@cassandra.apache.org
Delivered-To: mailing list user@cassandra.apache.org
Received: (qmail 57808 invoked by uid 99); 4 Jun 2014 17:56:58 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 04 Jun 2014 17:56:58 +0000
X-ASF-Spam-Status: No, hits=3.2 required=5.0
	tests=FREEMAIL_REPLY,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: domain of rbradberry@gmail.com
 designates 209.85.192.175 as permitted sender)
Received: from [209.85.192.175] (HELO mail-pd0-f175.google.com)
 (209.85.192.175)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 04 Jun 2014 17:56:53 +0000
Received: by mail-pd0-f175.google.com with SMTP id z10so6348902pdj.6
        for <user@cassandra.apache.org>; Wed, 04 Jun 2014 10:56:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=date:from:to:message-id:in-reply-to:references:subject:mime-version
         :content-type;
        bh=ltetbZ/9W6aHnDH0dgjrd2qNebty+dJWT8nKCdtSJ8E=;
        b=idMVwV+Mif/XK0zpHZQ/OJL2mKB8IVfRW66X363LVEMBoJUHVD3eZZyaHXWgb1wwhL
         C68D2IQZsD7CgIX331hEcHmsCh7n1Hk384nfM2l5IehE//dOX4HvOgCMIXNwup2FbuSO
         V/eZTcqSOMNGDeW6ncCTwknJQcKF5myWoyuNj/X+t39bAszanF+MrIbzS5U1u6tJKM1u
         P30rgegsQWgwhF/k7KF6JVLGFB0L9EjePTvEo94fqEAdU67qL0hW1CeubNevM3LXssJZ
         zag46HsZ8a0KT9VtZK/OazguRAJp4odeF7q/9r2Yk/qCUfsyp1frbfnXxi1ZTPDMjflg
         QTLA==
X-Received: by 10.68.200.133 with SMTP id js5mr66719831pbc.138.1401904593021;
        Wed, 04 Jun 2014 10:56:33 -0700 (PDT)
Received: from Russells-iMac.local (rrcs-24-136-119-106.nyc.biz.rr.com.
 [24.136.119.106])
        by mx.google.com with ESMTPSA id
 ee5sm12529155pbc.47.2014.06.04.10.56.30
        for <multiple recipients>
        (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
        Wed, 04 Jun 2014 10:56:31 -0700 (PDT)
Date: Wed, 4 Jun 2014 13:56:28 -0400
From: Russell Bradberry <rbradberry@gmail.com>
To: Redmumba <redmumba@gmail.com>, user@cassandra.apache.org
Message-ID: <etPan.538f5dcc.542289ec.1dd@Russells-iMac.local>
In-Reply-To: 
 <CAPwXK79Z7GOBVH3=8pUMPz7mnBhyU+smexgL_pX8Gv=mMvhPEA@mail.gmail.com>
References: 
 <CAPwXK799p=6Rmu0ikgf6ROUL=m1YJEMUwP8cbJpp7RK0PjU9nw@mail.gmail.com>
 <etPan.538f4d98.6a2342ec.1dd@Russells-iMac.local>
 <CAPwXK7_9iFujk1suY4Vuw+pmJsc+yykdJogA3=mpwgAYEsw+zg@mail.gmail.com>
 <etPan.538f51b7.1d4ed43b.1dd@Russells-iMac.local>
 <CAPwXK78jQ7TVV_4KUT7VAi-zidJXQWLC2FdNwq_dw7jcp2e0bg@mail.gmail.com>
 <etPan.538f5669.2cd89a32.1dd@Russells-iMac.local>
 <CAPwXK7_fPyHrN58j_7hXiaJLvc+M3vitZt7xyfsswppCvS=gVw@mail.gmail.com>
 <etPan.538f5a11.7a6d8d3c.1dd@Russells-iMac.local>
 <CAPwXK7_Z242xpg5gtu8r+MoQhkppb9eMaucPKqELPDuVA5NbGA@mail.gmail.com>
 <CACUnPaD2Va_pUS6y9eY7-2aMNPv8k4pZ5LZj45OO=DGD90kM6Q@mail.gmail.com>
 <CAPwXK79Z7GOBVH3=8pUMPz7mnBhyU+smexgL_pX8Gv=mMvhPEA@mail.gmail.com>
Subject: Re: Customized Compaction Strategy: Dev Questions
X-Mailer: Airmail (237)
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="538f5dcc_6de91b18_1dd"
X-Virus-Checked: Checked by ClamAV on apache.org

--538f5dcc_6de91b18_1dd
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Well, DELETE will not free up disk space until after GC grace has passed =
and the next major compaction has run. So in essence, if you need to free=
 up space right away, then creating daily/monthly tables would be one way=
 to go. =C2=A0Just remember to clear your snapshots after dropping though=
.



On June 4, 2014 at 1:54:05 PM, Redmumba (redmumba=40gmail.com) wrote:

That still involves quite a bit of infrastructure work--it also means tha=
t to query the data, I would have to make N queries, one per table, to qu=
ery for audit information (audit information is sorted by a key identifyi=
ng the item, and then the date).=C2=A0 I don't think this would yield any=
 benefit (to me) over simply tombstoning the values or creating a seconda=
ry index on date and simply doing a DELETE, right=3F

Is there something internally preventing me from implementing this as a s=
eparate Strategy=3F


On Wed, Jun 4, 2014 at 10:47 AM, Jonathan Haddad <jon=40jonhaddad.com> wr=
ote:
I'd suggest creating 1 table per day, and dropping the tables you don't n=
eed once you're done.


On Wed, Jun 4, 2014 at 10:44 AM, Redmumba <redmumba=40gmail.com> wrote:
Sorry, yes, that is what I was looking to do--i.e., create a =22Topologic=
alCompactionStrategy=22 or similar.


On Wed, Jun 4, 2014 at 10:40 AM, Russell Bradberry <rbradberry=40gmail.co=
m> wrote:
Maybe I=E2=80=99m misunderstanding something, but what makes you think th=
at running a major compaction every day will cause they data from January=
 1st to exist in only one SSTable and not have data from other days in th=
e SSTable as well=3F Are you talking about making a new compaction strate=
gy that creates SSTables by day=3F



On June 4, 2014 at 1:36:10 PM, Redmumba (redmumba=40gmail.com) wrote:

Let's say I run a major compaction every day, so that the =22oldest=22 ss=
table contains only the data for January 1st.=C2=A0 Assuming all the node=
s are in-sync and have had at least one repair run before the table is dr=
opped (so that all information for that time period is =22the same=22), w=
ouldn't it be safe to assume that the same data would be dropped on all n=
odes=3F=C2=A0 There might be a period when the compaction is running wher=
e different nodes might have an inconsistent view of just that days' data=
 (in that some would have it and others would not), but the cluster would=
 still function and become eventually consistent, correct=3F

Also, if the entirety of the sstable is being dropped, wouldn't the tombs=
tones be removed with it=3F=C2=A0 I wouldn't be concerned with individual=
 rows and columns, and this is a write-only table, more or less--the only=
 deletes that occur in the current system are to delete the old data.


On Wed, Jun 4, 2014 at 10:24 AM, Russell Bradberry <rbradberry=40gmail.co=
m> wrote:
I=E2=80=99m not sure what you want to do is feasible. =C2=A0At a high lev=
el I can see you running into issues with R=46 etc. =C2=A0The SSTables no=
de to node are not identical, so if you drop a full SSTable on one node t=
here is no one corresponding SSTable on the adjacent nodes to drop. =C2=A0=
 =C2=A0You would need to choose data to compact out, and ensure it is rem=
oved on all replicas as well. =C2=A0But if your problem is that you=E2=80=
=99re low on disk space then you probably won=E2=80=99t be able to write =
out a new SSTable with the older information compacted out. Also, there i=
s more to an SSTable than just data, the SSTable could have tombstones an=
d other relics that haven=E2=80=99t been cleaned up from nodes coming or =
going.=C2=A0




On June 4, 2014 at 1:10:58 PM, Redmumba (redmumba=40gmail.com) wrote:

Thanks, Russell--yes, a similar concept, just applied to sstables.=C2=A0 =
I'm assuming this would require changes to both major compactions, and pr=
obably GC (to remove the old tables), but since I'm not super-familiar wi=
th the C* internals, I wanted to make sure it was feasible with the curre=
nt toolset before I actually dived in and started tinkering.

Andrew


On Wed, Jun 4, 2014 at 10:04 AM, Russell Bradberry <rbradberry=40gmail.co=
m> wrote:
hmm, I see. So something similar to Capped Collections in MongoDB.



On June 4, 2014 at 1:03:46 PM, Redmumba (redmumba=40gmail.com) wrote:

Not quite; if I'm at say 90% disk usage, I'd like to drop the oldest ssta=
ble rather than simply run out of space.

The problem with using TTLs is that I have to try and guess how much data=
 is being put in--since this is auditing data, the usage can vary wildly =
depending on time of year, verbosity of auditing, etc..=C2=A0 I'd like to=
 maximize the disk space--not optimize the cleanup process.

Andrew


On Wed, Jun 4, 2014 at 9:47 AM, Russell Bradberry <rbradberry=40gmail.com=
> wrote:
You mean this:

https://issues.apache.org/jira/browse/CASSANDRA-5228

=3F



On June 4, 2014 at 12:42:33 PM, Redmumba (redmumba=40gmail.com) wrote:

Good morning=21

I've asked (and seen other people ask) about the ability to drop old ssta=
bles, basically creating a =46I=46O-like clean-up process.=C2=A0 Since we=
're using Cassandra as an auditing system, this is particularly appealing=
 to us because it means we can maximize the amount of auditing data we ca=
n keep while still allowing Cassandra to clear old data automatically.

My idea is this: perform compaction based on the range of dates available=
 in the sstable (or just metadata about when it was created).=C2=A0 =46or=
 example, a major compaction could create a combined sstable per day--so =
that, say, 60 days of data after a major compaction would contain 60 ssta=
bles.

My question then is, will this be possible by simply implementing a separ=
ate AbstractCompactionStrategy=3F=C2=A0 Does this sound feasilble at all=3F=
=C2=A0 Based on the implementation of Size and Leveled strategies, it loo=
ks like I would have the ability to control what and how things get compa=
cted, but I wanted to verify before putting time into it.

Thank you so much for your time=21

Andrew







--
Jon Haddad
http://www.rustyrazorblade.com
skype: rustyrazorblade


--538f5dcc_6de91b18_1dd
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<html><head><style>body=7Bfont-family:Helvetica,Arial;font-size:13px=7D</=
style></head><body style=3D=22word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;=22><div id=3D=22bloop=5Fcust=
omfont=22 style=3D=22font-family:Helvetica,Arial;font-size:13px; color: r=
gba(0,0,0,1.0); margin: 0px; line-height: auto;=22>Well, DELETE will not =
free up disk space until after GC grace has passed and the next major com=
paction has run. So in essence, if you need to free up space right away, =
then creating daily/monthly tables would be one way to go. &nbsp;Just rem=
ember to clear your snapshots after dropping though.</div> <div id=3D=22b=
loop=5Fsign=5F1401904505231099136=22 class=3D=22bloop=5Fsign=22><br><br><=
span style=3D=22font-family:helvetica,arial;font-size:13px=22></span><spa=
n></span></div> <br><p style=3D=22color:=23000;=22>On June 4, 2014 at 1:5=
4:05 PM, Redmumba (<a href=3D=22mailto:redmumba=40gmail.com=22>redmumba=40=
gmail.com</a>) wrote:</p> <blockquote type=3D=22cite=22 class=3D=22clean=5F=
bq=22><span><div><div></div><div>


<title></title>


<div dir=3D=22ltr=22>That still involves quite a bit of infrastructure
work--it also means that to query the data, I would have to make N
queries, one per table, to query for audit information (audit
information is sorted by a key identifying the item, and then the
date).&nbsp; I don't think this would yield any benefit (to me)
over simply tombstoning the values or creating a secondary index on
date and simply doing a DELETE, right=3F<br>
<br>
Is there something internally preventing me from implementing this
as a separate Strategy=3F<br></div>
<div class=3D=22gmail=5Fextra=22><br>
<br>
<div class=3D=22gmail=5Fquote=22>On Wed, Jun 4, 2014 at 10:47 AM, Jonatha=
n
Haddad <span dir=3D=22ltr=22>&lt;<a href=3D=22mailto:jon=40jonhaddad.com=22=
 target=3D=22=5Fblank=22>jon=40jonhaddad.com</a>&gt;</span> wrote:<br>
<blockquote class=3D=22gmail=5Fquote=22 style=3D=22margin:0 0 0 .8ex;bord=
er-left:1px =23ccc solid;padding-left:1ex=22>
<div dir=3D=22ltr=22>I'd suggest creating 1 table per day, and dropping
the tables you don't need once you're done.</div>
<div class=3D=22gmail=5Fextra=22>
<div>
<div class=3D=22h5=22><br>
<br>
<div class=3D=22gmail=5Fquote=22>On Wed, Jun 4, 2014 at 10:44 AM, Redmumb=
a
<span dir=3D=22ltr=22>&lt;<a href=3D=22mailto:redmumba=40gmail.com=22 tar=
get=3D=22=5Fblank=22>redmumba=40gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D=22gmail=5Fquote=22 style=3D=22margin:0 0 0 .8ex;bord=
er-left:1px =23ccc solid;padding-left:1ex=22>
<div dir=3D=22ltr=22>Sorry, yes, that is what I was looking to do--i.e.,
create a =22TopologicalCompactionStrategy=22 or similar.<br></div>
<div>
<div>
<div class=3D=22gmail=5Fextra=22><br>
<br>
<div class=3D=22gmail=5Fquote=22>On Wed, Jun 4, 2014 at 10:40 AM, Russell=

Bradberry <span dir=3D=22ltr=22>&lt;<a href=3D=22mailto:rbradberry=40gmai=
l.com=22 target=3D=22=5Fblank=22>rbradberry=40gmail.com</a>&gt;</span> wr=
ote:<br>
<blockquote class=3D=22gmail=5Fquote=22 style=3D=22margin:0 0 0 .8ex;bord=
er-left:1px =23ccc solid;padding-left:1ex=22>
<div style=3D=22word-wrap:break-word=22>
<div style=3D=22font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0=
,0,1.0);margin:0px;line-height:auto=22>
Maybe I=E2=80=99m misunderstanding something, but what makes you think th=
at
running a major compaction every day will cause they data from
January 1st to exist in only one SSTable and not have data from
other days in the SSTable as well=3F Are you talking about making a
new compaction strategy that creates SSTables by day=3F</div>
<div>
<div>
<div><br>
<br></div>
<br>
<p style=3D=22color:=23000=22>On June 4, 2014 at 1:36:10 PM, Redmumba
(<a href=3D=22mailto:redmumba=40gmail.com=22 target=3D=22=5Fblank=22>redm=
umba=40gmail.com</a>) wrote:</p>
<blockquote type=3D=22cite=22>
<div>
<div>
<div dir=3D=22ltr=22>
<div><span>Let's say I run a major compaction every day, so that
the =22oldest=22 sstable contains only the data for January 1st.&nbsp;
Assuming all the nodes are in-sync and have had at least one repair
run before the table is dropped (so that all information for that
time period is =22the same=22), wouldn't it be safe to assume that the
same data would be dropped on all nodes=3F&nbsp; There might be a
period when the compaction is running where different nodes might
have an inconsistent view of just that days' data (in that some
would have it and others would not), but the cluster would still
function and become eventually consistent, correct=3F<br>
<br></span></div>
<span>Also, if the entirety of the sstable is being dropped,
wouldn't the tombstones be removed with it=3F&nbsp; I wouldn't be
concerned with individual rows and columns, and this is a
write-only table, more or less--the only deletes that occur in the
current system are to delete the old data.<br></span></div>
<div class=3D=22gmail=5Fextra=22><span><br>
<br></span>
<div class=3D=22gmail=5Fquote=22><span>On Wed, Jun 4, 2014 at 10:24 AM,
Russell Bradberry <span dir=3D=22ltr=22>&lt;<a href=3D=22mailto:rbradberr=
y=40gmail.com=22 target=3D=22=5Fblank=22>rbradberry=40gmail.com</a>&gt;</=
span> wrote:<br></span>
<blockquote class=3D=22gmail=5Fquote=22 style=3D=22margin:0 0 0 .8ex;bord=
er-left:1px =23ccc solid;padding-left:1ex=22>
<div style=3D=22word-wrap:break-word=22>
<div style=3D=22font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0=
,0,1.0);margin:0px;line-height:auto=22>
I=E2=80=99m not sure what you want to do is feasible. &nbsp;At a high lev=
el
I can see you running into issues with R=46 etc. &nbsp;The SSTables
node to node are not identical, so if you drop a full SSTable on
one node there is no one corresponding SSTable on the adjacent
nodes to drop. &nbsp; &nbsp;You would need to choose data to
compact out, and ensure it is removed on all replicas as well.
&nbsp;But if your problem is that you=E2=80=99re low on disk space then y=
ou
probably won=E2=80=99t be able to write out a new SSTable with the older
information compacted out. Also, there is more to an SSTable than
just data, the SSTable could have tombstones and other relics that
haven=E2=80=99t been cleaned up from nodes coming or going.&nbsp;</div>
<div>
<div>
<div style=3D=22font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0=
,0,1.0);margin:0px;line-height:auto=22>
<br></div>
<div><br>
<br></div>
<br>
<p style=3D=22color:=23000=22>On June 4, 2014 at 1:10:58 PM, Redmumba
(<a href=3D=22mailto:redmumba=40gmail.com=22 target=3D=22=5Fblank=22>redm=
umba=40gmail.com</a>) wrote:</p>
<blockquote type=3D=22cite=22>
<div>
<div>
<div dir=3D=22ltr=22>
<div><span>Thanks, Russell--yes, a similar concept, just applied to
sstables.&nbsp; I'm assuming this would require changes to both
major compactions, and probably GC (to remove the old tables), but
since I'm not super-familiar with the C* internals, I wanted to
make sure it was feasible with the current toolset before I
actually dived in and started tinkering.<br></span></div>
<div><span><br></span></div>
<div><span>Andrew<br></span></div>
</div>
<div class=3D=22gmail=5Fextra=22><span><br>
<br></span>
<div class=3D=22gmail=5Fquote=22><span>On Wed, Jun 4, 2014 at 10:04 AM,
Russell Bradberry <span dir=3D=22ltr=22>&lt;<a href=3D=22mailto:rbradberr=
y=40gmail.com=22 target=3D=22=5Fblank=22>rbradberry=40gmail.com</a>&gt;</=
span> wrote:<br></span>
<blockquote class=3D=22gmail=5Fquote=22 style=3D=22margin:0 0 0 .8ex;bord=
er-left:1px =23ccc solid;padding-left:1ex=22>
<div style=3D=22word-wrap:break-word=22>
<div style=3D=22font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0=
,0,1.0);margin:0px;line-height:auto=22>
hmm, I see. So something similar to Capped Collections in
MongoDB.</div>
<div>
<div>
<div><br>
<br></div>
<br>
<p style=3D=22color:=23000=22>On June 4, 2014 at 1:03:46 PM, Redmumba
(<a href=3D=22mailto:redmumba=40gmail.com=22 target=3D=22=5Fblank=22>redm=
umba=40gmail.com</a>) wrote:</p>
<blockquote type=3D=22cite=22>
<div>
<div>
<div dir=3D=22ltr=22>
<div><span>Not quite; if I'm at say 90% disk usage, I'd like to
drop the oldest sstable rather than simply run out of space.<br>
<br>
The problem with using TTLs is that I have to try and guess how
much data is being put in--since this is auditing data, the usage
can vary wildly depending on time of year, verbosity of auditing,
etc..&nbsp; I'd like to maximize the disk space--not optimize the
cleanup process.<br>
<br></span></div>
<span>Andrew<br></span></div>
<div class=3D=22gmail=5Fextra=22><span><br>
<br></span>
<div class=3D=22gmail=5Fquote=22><span>On Wed, Jun 4, 2014 at 9:47 AM,
Russell Bradberry <span dir=3D=22ltr=22>&lt;<a href=3D=22mailto:rbradberr=
y=40gmail.com=22 target=3D=22=5Fblank=22>rbradberry=40gmail.com</a>&gt;</=
span> wrote:<br></span>
<blockquote class=3D=22gmail=5Fquote=22 style=3D=22margin:0 0 0 .8ex;bord=
er-left:1px =23ccc solid;padding-left:1ex=22>
<div style=3D=22word-wrap:break-word=22>
<div style=3D=22font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0=
,0,1.0);margin:0px;line-height:auto=22>
You mean this:</div>
<div style=3D=22font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0=
,0,1.0);margin:0px;line-height:auto=22>
<br></div>
<div style=3D=22font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0=
,0,1.0);margin:0px;line-height:auto=22>
<a href=3D=22https://issues.apache.org/jira/browse/CASSANDRA-5228=22 targ=
et=3D=22=5Fblank=22>https://issues.apache.org/jira/browse/CASSANDRA-5228<=
/a></div>
<div style=3D=22font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0=
,0,1.0);margin:0px;line-height:auto=22>
<br></div>
<div style=3D=22font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0=
,0,1.0);margin:0px;line-height:auto=22>
=3F</div>
<div>
<div>
<div><br>
<br></div>
<br>
<p style=3D=22color:=23000=22>On June 4, 2014 at 12:42:33 PM, Redmumba
(<a href=3D=22mailto:redmumba=40gmail.com=22 target=3D=22=5Fblank=22>redm=
umba=40gmail.com</a>) wrote:</p>
<blockquote type=3D=22cite=22>
<div>
<div>
<div dir=3D=22ltr=22>
<div><span>Good morning=21<br>
<br>
I've asked (and seen other people ask) about the ability to drop
old sstables, basically creating a =46I=46O-like clean-up
process.&nbsp; Since we're using Cassandra as an auditing system,
this is particularly appealing to us because it means we can
maximize the amount of auditing data we can keep while still
allowing Cassandra to clear old data automatically.<br>
<br>
My idea is this: perform compaction based on the range of dates
available in the sstable (or just metadata about when it was
created).&nbsp; =46or example, a major compaction could create a
combined sstable per day--so that, say, 60 days of data after a
major compaction would contain 60 sstables.<br></span></div>
<div><span><br></span></div>
<div><span>My question then is, will this be possible by simply
implementing a separate AbstractCompactionStrategy=3F&nbsp; Does this
sound feasilble at all=3F&nbsp; Based on the implementation of Size
and Leveled strategies, it looks like I would have the ability to
control what and how things get compacted, but I wanted to verify
before putting time into it.<br>
<br>
Thank you so much for your time=21<br>
<br></span></div>
<div><span>Andrew<br></span></div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
<br></div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
<br></div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
<br></div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
<br></div>
</div>
</div>
</blockquote>
</div>
<br>
<br clear=3D=22all=22>
<div><br></div>
</div>
</div>
<span class=3D=22HOEnZb=22><font color=3D=22=23888888=22>--<br>
Jon Haddad<br>
<a href=3D=22http://www.rustyrazorblade.com=22 target=3D=22=5Fblank=22>ht=
tp://www.rustyrazorblade.com</a><br></font></span>
<div><span class=3D=22HOEnZb=22><font color=3D=22=23888888=22>skype:
rustyrazorblade</font></span></div>
</div>
</blockquote>
</div>
<br></div>


</div></div></span></blockquote></body></html>
--538f5dcc_6de91b18_1dd--