On Thu, Jan 14, 2010 at 12:15 PM, Kelvin Kakugawa <kakug...@gmail.com> wrote: > If you're interested, why don't you create a new ticket and assign it > to yourself. I'd be happy to help you figure out which parts of the > codebase need to be touched.
Created, #699 (I have yet to figure out how to assign it to me though). Of course, any help/ideas are welcome. > btw, I'm working on Issue #580 which will add versioning to Cassandra. > An aspect of this feature is that I am adding support for a new type > of column that serializes different metadata to disk. So, when my > contribution gets pushed through, the strategy that I use would > probably be able to support a new TTL column, as well. So, you > wouldn't have to penalize all of the currently existing column types. Yes, I was also thinking of making a special kind of column, so that it don't penalize non TTLed column. So I'm indeed interested by what you do with #580. I'll have a look at what you have done already. Thanks -- Sylvain > > On Thu, Jan 14, 2010 at 12:17 AM, Sylvain Lebresne <sylv...@yakaz.com> wrote: >> On Thu, Jan 14, 2010 at 6:46 AM, August Zajonc <augu...@augustz.com> wrote: >>> I personally like this last option of expiring entire sstables. It seems >>> significantly more efficient then scrubbing data. The granularity might be a >>> bit high, but by columnfamily seems a reasonable trade-off in the short run >>> for an easier solution. >>> >>> For apps that don't want to see the old data, during a read if the data had >>> a timestamp older than the expire time on the ColumnFamily it could also be >>> ignored, then when all in an sstable < x, truncate. >>> >>> Logs are a great example of this. >> >> I personally think that truncate and a potential TTL are two different >> things, since as >> you said, they have very different granularity. In particular, using >> truncate basically >> means that all the data in the CF you truncate have exactly the same >> TTL. Plus, >> you have to know if a data have a TTL (and which one if you want >> different CF that you >> truncate at different time) when you request it. I, for one, have many >> use where it's not >> really a desirable solution. Plus, truncate suppose that you >> deactivate compaction for >> you CF, which may or may not be affordable. >> But sure, for some models, and logs are a great example indeed, >> truncate will be the >> perfect solution. >> >> Anyway, I'm starting to seriously consider giving this TTL idea a >> shot. We'll see how >> that goes. >> >> -- >> Sylvain >> >
