cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Branson (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (CASSANDRA-3929) Support row size limits
Date Tue, 05 Mar 2013 16:13:14 GMT

    [ 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

Mime
View raw message