cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jun Rao (JIRA)" <j...@apache.org>
Subject [jira] Commented: (CASSANDRA-223) time-based slicing does not work correctly w/ "historial" memtables
Date Mon, 22 Jun 2009 15:52:07 GMT

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

Jun Rao commented on CASSANDRA-223:
-----------------------------------

Since it's hard to guarantee any timestamp ordering among memtable and sstables because of
the reasons listed above, the only way that we can get the correct answer is do look at the
memtable and ALL sstables (this is what HBase has been doing). This affects the following
APIs.
get_column
get_slice_by_names
get_slice_by_name_range
get_slice_since

The implication is that those APIs will potentially run slower since there are more files
to read. One can probably tune the performance by setting a proper compaction policy.


> time-based slicing does not work correctly w/ "historial" memtables
> -------------------------------------------------------------------
>
>                 Key: CASSANDRA-223
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-223
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Jonathan Ellis
>         Attachments: 223.patch
>
>
> TimeFilter assumes that it is done as soon as it finds a column stamped earlier than
what it is filtering on, but when you have a group of "historical" memtables whose columns
were written in an arbitrary order this is not a safe assumption.
> It is not even a safe assumption when dealing with a single memtable + sstable pair,
as the attached new test shows.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message