[
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 come 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 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.
> 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
