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. Just
remember to clear your snapshots after dropping though.
On J
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). I don't think this would yield any benefit (to
I'd suggest creating 1 table per day, and dropping the tables you don't
need once you're done.
On Wed, Jun 4, 2014 at 10:44 AM, Redmumba wrote:
> 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, Rus
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’m misunderstanding something, but what makes you think that
> running a major compaction every day will cause they data fr
Maybe I’m 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 SSTable as well? Are
you talking about making a new compaction strategy that create
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 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 t
I’m 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 to choose d
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
b
hmm, I see. So something similar to Capped Collections in MongoDB.
On June 4, 2014 at 1:03:46 PM, Redmumba (redmu...@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 t
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 o
You mean this:
https://issues.apache.org/jira/browse/CASSANDRA-5228
?
On June 4, 2014 at 12:42:33 PM, Redmumba (redmu...@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'
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'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
12 matches
Mail list logo
