My understanding was that TTLs only apply to columns and not on a per row basis. This means that for each column insert you would need to set that TTL. Does this mean that the amount of data space used in such a case would be the TTL * the number of columns? I was hoping there was a way to set a row TTL. See older post: http://comments.gmane.org/gmane.comp.db.cassandra.user/12701
From: Christopher Keller <cnkel...@gmail.com<mailto:cnkel...@gmail.com>> Reply-To: "user@cassandra.apache.org<mailto:user@cassandra.apache.org>" <user@cassandra.apache.org<mailto:user@cassandra.apache.org>> Date: Tuesday, December 18, 2012 11:16 AM To: "user@cassandra.apache.org<mailto:user@cassandra.apache.org>" <user@cassandra.apache.org<mailto:user@cassandra.apache.org>> Subject: Re: Partition maintenance If I'm understanding you correctly, you can write TTL's on each insert. 18 months would be roughly 540 days which would be 46656000 seconds. I've not tried that number, but I use smaller TTL's all the time and they work fine. Once they are expired they get tombstones and are no longer searchable. Space is reclaimed as with any tombstone. --Chris On Dec 18, 2012, at 11:08 AM, stephen.m.thomp...@wellsfargo.com<mailto:stephen.m.thomp...@wellsfargo.com> wrote: Hi folks. Still working through the details of building out a Cassandra solution and I have an interesting requirement that I’m not sure how to implement in Cassandra: In our current Oracle world, we have the data for this system partitioned by month, and each month the data that are now 18-months old are archived to tape/cold storage and then the partition for that month is dropped. Is there a way to do something similar with Cassandra without destroying our overall performance? Thanks in advance, Steve -- "The downside of being better than everyone else is that people tend to assume you're pretentious."
