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 C613911E34 for ; Wed, 4 Jun 2014 17:45:47 +0000 (UTC) Received: (qmail 30366 invoked by uid 500); 4 Jun 2014 17:45:45 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 30327 invoked by uid 500); 4 Jun 2014 17:45:45 -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 30319 invoked by uid 99); 4 Jun 2014 17:45:45 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 04 Jun 2014 17:45:45 +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 redmumba@gmail.com designates 209.85.216.47 as permitted sender) Received: from [209.85.216.47] (HELO mail-qa0-f47.google.com) (209.85.216.47) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 04 Jun 2014 17:45:40 +0000 Received: by mail-qa0-f47.google.com with SMTP id s7so7425607qap.6 for ; Wed, 04 Jun 2014 10:45:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=1WJgAV7roMj5K0GMYNtuwC65bxCTEM5ga9bdHQIAwz8=; b=HCbMmz7BNq7GpOyEBm/vbqeZVBzVCSCYAP0NUQWBgo+UYNhrNVgRiD4EKH4o8vb6fC ZiiL+OR8a0os/6r1rbBWpzg236DKgdZlJ3iWkcD9jUOZ8rytA0Omuveb08JrqG9u/puK chq3SO0NWxi3cAIeMJXLOwtx23B1AY1TOOm/lFi3aNntJRSXMkWaUX18lqkTLTeTtmwl +IqLEhatTgvthm/OpVh2qcJ+NAR+09PD0bLyhWSPr7sXUueCRkU9x965llPLVONO1VjL Bttfa8X/wRqBAT8kxwZLdSmSq/EQKBx5TiUYRHY5SaaDGTFo2DTQXTfLEOS2akTRN+4H xbVQ== X-Received: by 10.229.213.66 with SMTP id gv2mr73572067qcb.13.1401903916917; Wed, 04 Jun 2014 10:45:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.178.71 with HTTP; Wed, 4 Jun 2014 10:44:56 -0700 (PDT) In-Reply-To: References: From: Redmumba Date: Wed, 4 Jun 2014 10:44:56 -0700 Message-ID: Subject: Re: Customized Compaction Strategy: Dev Questions To: Russell Bradberry Cc: user@cassandra.apache.org Content-Type: multipart/alternative; boundary=001a11333facfa2c7204fb0630bf X-Virus-Checked: Checked by ClamAV on apache.org --001a11333facfa2c7204fb0630bf Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sorry, yes, that is what I was looking to do--i.e., create a "TopologicalCompactionStrategy" or similar. On Wed, Jun 4, 2014 at 10:40 AM, Russell Bradberry 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 1s= t > to exist in only one SSTable and not have data from other days in the > SSTable as well? Are you talking about making a new compaction strategy > that creates SSTables by day? > > > > On June 4, 2014 at 1:36:10 PM, Redmumba (redmumba@gmail.com) wrote: > > Let's say I run a major compaction every day, so that the "oldest" > sstable contains only the data for January 1st. Assuming all the nodes a= re > in-sync and have had at least one repair run before the table is dropped > (so that all information for that time period is "the same"), wouldn't it > be safe to assume that the same data would be dropped on all nodes? Ther= e > 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 wou= ld > have it and others would not), but the cluster would still function and > become eventually consistent, correct? > > Also, if the entirety of the sstable is being dropped, wouldn't the > tombstones be removed with it? 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 > wrote: > >> I=E2=80=99m not sure what you want to do is feasible. At a high level = I can >> see you running into issues with RF etc. 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. You would need t= o >> choose data to compact out, and ensure it is removed on all replicas as >> well. But 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 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. >> >> >> >> >> On June 4, 2014 at 1:10:58 PM, Redmumba (redmumba@gmail.com) wrote: >> >> Thanks, Russell--yes, a similar concept, just applied to sstables. >> 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. >> >> Andrew >> >> >> On Wed, Jun 4, 2014 at 10:04 AM, Russell Bradberry >> wrote: >> >>> hmm, I see. So something similar to Capped Collections in MongoDB. >>> >>> >>> >>> On June 4, 2014 at 1:03:46 PM, Redmumba (redmumba@gmail.com) wrote: >>> >>> 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. >>> >>> 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.. I'd lik= e to >>> maximize the disk space--not optimize the cleanup process. >>> >>> Andrew >>> >>> >>> On Wed, Jun 4, 2014 at 9:47 AM, Russell Bradberry >>> wrote: >>> >>>> You mean this: >>>> >>>> https://issues.apache.org/jira/browse/CASSANDRA-5228 >>>> >>>> ? >>>> >>>> >>>> >>>> On June 4, 2014 at 12:42:33 PM, Redmumba (redmumba@gmail.com) wrote: >>>> >>>> Good morning! >>>> >>>> I've asked (and seen other people ask) about the ability to drop old >>>> sstables, basically creating a FIFO-like clean-up process. Since we'r= e >>>> 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 ke= ep >>>> 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).= For >>>> example, a major compaction could create a combined sstable per day--s= o >>>> that, say, 60 days of data after a major compaction would contain 60 >>>> sstables. >>>> >>>> My question then is, will this be possible by simply implementing a >>>> separate AbstractCompactionStrategy? Does this sound feasilble at all= ? >>>> Based on the implementation of Size and Leveled strategies, it looks l= ike I >>>> would have the ability to control what and how things get compacted, b= ut I >>>> wanted to verify before putting time into it. >>>> >>>> Thank you so much for your time! >>>> >>>> Andrew >>>> >>>> >>> >> > --001a11333facfa2c7204fb0630bf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sorry, yes, that is what I was looking to do--i.e., create= a "TopologicalCompactionStrategy" or similar.


On Wed, Jun 4, 2014 at= 10:40 AM, Russell Bradberry <rbradberry@gmail.com> wrote= :
Maybe I=E2=80=99m misunderstanding something, but what makes you think that= 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 SSTa= ble as well? Are you talking about making a new compaction strategy that cr= eates SSTables by day?



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

Let's say I run a major compaction every day, so that the "oldest" sstable contains only the data for January 1st.=C2=A0 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 "the same"), wouldn't it be safe to assume tha= t the same data would be dropped on all nodes?=C2=A0 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?

Also, if the entirety of the sstable is being dropped, wouldn't the tombstones be removed with it?=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@gmail.com> wrote:
I=E2=80=99m not sure what you want to do is feasible. =C2=A0At a high level I can see you running into issues with RF etc. =C2=A0The 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. =C2=A0 =C2=A0You would need to choose data to compact out, and ensure it is removed 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 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.=C2=A0




On June 4, 2014 at 1:10:58 PM, Redmumba (redmumba@gmail.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 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.

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



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

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.

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@gmail.com> wrote:
You mean this:


?



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

Good morning!

I've asked (and seen other people ask) about the ability to drop old sstables, basically creating a FIFO-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 can 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 For 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.

My question then is, will this be possible by simply implementing a separate AbstractCompactionStrategy?=C2=A0 Does this sound feasilble at all?=C2=A0 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.

Thank you so much for your time!

Andrew




--001a11333facfa2c7204fb0630bf--