The problem is that tombstones will hang in there till GC grace period. You can reduce the GC grace period and then catch lost deletes in the application layer if you know you should not be seeing such an old record.
Also in 1.2, they have some setting which enable an sstable to be compacted if it has lot of tombstones. You might want to look at that. On Mon, Aug 26, 2013 at 3:31 AM, cem <cayiro...@gmail.com> wrote: > Hi Alain, > > I solved the same issue by implementing a client that manages time range > partitions. Each time range partition is a CF. > > Cem. > > > On Mon, Aug 26, 2013 at 11:34 AM, Alain RODRIGUEZ <arodr...@gmail.com>wrote: > >> Hi, >> >> Any guidance on this topic would be appreciated :). >> >> >> 2013/8/23 Alain RODRIGUEZ <arodr...@gmail.com> >> >>> Hi, >>> >>> I am currently using about 10 CF to store temporal data. Those data are >>> growing pretty big (hundreds of GB when I actually only need information >>> from the last month - i.e. about hundreds of MB). >>> >>> I am going to delete old (and useless) data, I cannot always use TTL >>> since I have counters too. Yet I know that deletes are a bit tricky in >>> Cassandra, due to the fact that they are distributed. >>> >>> I was wondering about the best way to keep high performance and get rid >>> of tombstones easily. >>> >>> I was considering 2 ways to do it : >>> >>> - Major compaction on these 10 CF to force them to always keep fresh >>> data only and remove tombstones >>> - LCS to have more chance to get all parts of the row in one SSTable, >>> allowing tombstones to be removed eventually. >>> >>> What would be the better option (i.e. what would be the impact of both >>> solutions) ? >>> Do you need more information about those CF to answer this question ? >>> >>> Any insight is welcome, as always. >>> >>> Alain >>> >> >> >
