Also, if you can get to at least 2.0 you can use TimeWindowCompactionStrategy which works a lot better with time series data w/ TTLs than STCS.
On Fri, Sep 2, 2016 at 9:53 AM Jonathan Haddad <j...@jonhaddad.com> wrote: > What's your gc_grace_seconds set to? Is it possible you have a lot of > tombstones that haven't reached the GC grace time yet? > > > On Thu, Sep 1, 2016 at 12:54 AM Kevin O'Connor <ke...@reddit.com> wrote: > >> We're running C* 1.2.11 and have two CFs, one called OAuth2AccessToken >> and one OAuth2AccessTokensByUser. OAuth2AccessToken has the token as the >> row key, and the columns are some data about the OAuth token. There's a TTL >> set on it, usually 3600, but can be higher (up to 1 month). >> OAuth2AccessTokensByUser has the user as the row key, and then all of the >> user's token identifiers as column values. Each of the column values has a >> TTL that is set to the same as the access token it corresponds to. >> >> The OAuth2AccessToken CF takes up around ~6 GB on disk, whereas the >> OAuth2AccessTokensByUser CF takes around ~110 GB. If I use sstablemetadata, >> I can see the droppable tombstones ratio is around 90% for the larger >> sstables. >> >> My question is - why aren't these tombstones getting compacted away? I'm >> guessing that it's because we use STCS and the large sstables that have >> built up over time are never considered for compaction. Would LCS be a >> better fit for the issue of trying to keep the tombstones in check? >> >> I've also tried forceUserDefinedCompaction via JMX on some of the largest >> sstables and it just creates a new sstable of the exact same size, which >> was pretty surprising. Why would this explicit request to compact an >> sstable not remove tombstones? >> >> Thanks! >> >> Kevin >> >
