[ 
https://issues.apache.org/jira/browse/CASSANDRA-3929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13593524#comment-13593524
 ] 

Rick Branson edited comment on CASSANDRA-3929 at 3/5/13 4:12 PM:
-----------------------------------------------------------------

I see the arguments in general with how it's difficult to clearly communicate 
to the end user what's exactly going to happen to their data. At this point I'm 
looking at implementing this as a compaction strategy. I've also not done 
extensive testing on exactly how expensive it'd be to read the N'th column in 
the row for a sample of inserts and delete the unneeded data, which will 
probably coe first. This is a blocker for us moving some storage for a few 
features from a very manually managed Redis cluster to C*.

[~liqusha]: something like that, while probably slightly more "grokable" by the 
end user, would actually require reading the entire row for each operation 
unless some fancy enhancements to tombstones were made. If the data is 
time-ordered, this can be emulated by reading the N+1th column and deleting the 
row with a timestamp of that column+1. The idea with implementing this the way 
we have in this ticket is that we'd get it for "free" by making it part of the 
compaction process. 
                
      was (Author: rbranson):
    I see the arguments in general with how it's difficult to clearly 
communicate to the end user what's exactly going to happen to their data. At 
this point I'm looking at implementing this as a compaction strategy. I've also 
not done extensive testing on exactly how expensive it'd be to read the N'th 
column in the row for a sample of inserts and delete the unneeded data, which 
will probably coe first. This is a blocker for us moving some storage for a few 
features from a very manually managed Redis cluster to C*.

[~liqusha]: something like that, while probably slightly more "grokable" by the 
end user, would actually require reading the entire row for each operation 
unless some fancy enhancements to tombstones were made. If the data is 
time-ordered, this can be emulated by reading the N+1th column and deleting the 
row with a timestamp of that column+1. The idea with this is that we'd get it 
for "free" by making it part of the compaction process. 
                  
> Support row size limits
> -----------------------
>
>                 Key: CASSANDRA-3929
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-3929
>             Project: Cassandra
>          Issue Type: New Feature
>          Components: Core
>            Reporter: Jonathan Ellis
>            Assignee: Dave Brosius
>            Priority: Minor
>              Labels: ponies
>             Fix For: 2.0
>
>         Attachments: 3929_b.txt, 3929_c.txt, 3929_d.txt, 3929_e.txt, 
> 3929_f.txt, 3929_g_tests.txt, 3929_g.txt, 3929.txt
>
>
> We currently support expiring columns by time-to-live; we've also had 
> requests for keeping the most recent N columns in a row.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to