Uploaded image for project: 'Cassandra'
  1. Cassandra
  2. CASSANDRA-1276

GCGraceSeconds per ColumnFamily



    • Type: Improvement
    • Status: Resolved
    • Priority: Low
    • Resolution: Fixed
    • Fix Version/s: 0.7 beta 1
    • Component/s: None
    • Labels:


      From: Jonathan Ellis [jbellis@gmail.com]
      Received: 7/12/10 9:15 PM
      To: user@cassandra.apache.org [user@cassandra.apache.org]
      Subject: Re: GCGraceSeconds per ColumnFamily/Keyspace

      Probably. Can you open a ticket?

      On Mon, Jul 12, 2010 at 10:41 PM, Todd Burruss <bburruss@real.com> wrote:
      > Is it possible to get this feature in 0.7?
      > ----Original Message----
      > From: Jonathan Ellis [jbellis@gmail.com]
      > Received: 7/12/10 5:06 PM
      > To: user@cassandra.apache.org [user@cassandra.apache.org]
      > Subject: Re: GCGraceSeconds per ColumnFamily/Keyspace
      > GCGS per CF sounds totally reasonable to me.
      > On Mon, Jul 12, 2010 at 6:33 PM, Todd Burruss <bburruss@real.com> wrote:
      >> I have two CFs in my keyspace. one i care about allowing a good amount of
      >> time for tombstones to propagate (GCGraceSeconds large) ... but the other i
      >> couldn't care and in fact i want them gone ASAP so i don't iterate over
      >> them. has any thought been given to making this setting per Keyspace or per
      >> ColumnFamily?
      >> my scenario is that i add columns to rows in one CF, UserData, with
      >> logging data or activity, but we only want to keep, say 5000 columns per
      >> user. So i also store the user's ID in another CF, PruneCollection, and
      >> periodically iterate over it using the IDs found in PruneCollection to
      >> "prune" the columns in UserData - and then immediately delete the ID from
      >> PruneCollection. if the code is adding, say 50 IDs per second to
      >> PruneCollection then the number of deleted keys starts to build up, forcing
      >> my iterator to skip over large amounts of deleted keys. With a small
      >> GCGraceSeconds these keys are removed nicely, but i can't do that because it
      >> affects the tombstones in UserData as well, which need to be propagated.
      >> thoughts?


        1. 1276-v4.txt
          41 kB
          Jonathan Ellis
        2. 1276-v5.txt
          38 kB
          Jon Hermes
        3. 1276-v6.txt
          38 kB
          Jon Hermes
        4. 1276-v7.txt
          0.7 kB
          Jon Hermes



            • Assignee:
              jhermes Jon Hermes
              btoddb B. Todd Burruss
              Jon Hermes
              Jonathan Ellis
            • Votes:
              0 Vote for this issue
              1 Start watching this issue


              • Created: