cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Alves (JIRA)" <j...@apache.org>
Subject [jira] [Issue Comment Edited] (CASSANDRA-3885) Support multiple ranges in SliceQueryFilter
Date Sat, 28 Apr 2012 14:15:49 GMT

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

David Alves edited comment on CASSANDRA-3885 at 4/28/12 2:14 PM:
-----------------------------------------------------------------

Here's a patch that implements multi-slice in ISR, it behaves pretty much as expected/suggested,
additionally it implementes re-read prevention. to clarify:
       - for forward scans it checks whether the next slice is within the current index segment
and continues the scan there if it is.
       - for reverse scans it stores the columns before the current range, in cache. if the
next range (which in reverse is before) starts/uses the same index segment the it uses the
cache instead of re-reading the columns.

The test also reduces the number of bytebuffer comparisons in computeNext() as all the columns
added to blockColumns are within the argument ranges and may be read so there is no need to
make range checks.

The patch slightly changes SliceQueryFilter to use range sets but maintains backwards compatibility.
Public access to start and finish is changed to be done through accessors.

The patch includes a somewhat (maybe too) verbose test of the new and old behavior.

The slice reader assumes that either the whole ranges are read reversed or not (there are
no forward+reversed range mix).

The slice reader assumes that ranges are sorted correctly, e.g. that for forward lookup ranges
are in lexicographic order of start elements and that for reverse lookup they are in reverse
lexicographic order of finish (reverse start) elements. i.e. forward: [a,b],[d,e],[g,h] reverse:
[h,g],[e,d],[b,a]. The reader also assumes that validation has been performed in terms of
intervals (no overlapping intervals).

Tests are *mostly* green with the following exception:

[junit] Testsuite: org.apache.cassandra.db.CommitLogTest
    [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0 sec
    [junit] 
    [junit] Testcase: org.apache.cassandra.db.CommitLogTest:terminated successfully:	Caused
an ERROR
    [junit] Timeout occurred. Please note the time in the report does not reflect the time
until the timeout.
    [junit] junit.framework.AssertionFailedError: Timeout occurred. Please note the time in
the report does not reflect the time until the timeout.
    [junit] 
    [junit] 
    [junit] Test org.apache.cassandra.db.CommitLogTest FAILED (timeout)



                
      was (Author: dr-alves):
    Here's a patch that implements multi-slice in ISR, it behaves pretty much as expected/suggested,
additionally itimplemented re-read prevention. to clarify:
       - for forward scans it checks whether the next slice is within the current index segment
and continues the scan there if it is.
       - for reverse scans it stores the columns before the current range, in cache. if the
next range (which in reverse is before) starts/uses the same index segment the it uses the
cache instead of re-reading the columns.

The test also reduces the number of bytebuffer comparisons in computeNext() as all the columns
added to blockColumns are within the argument ranges and may be read so there is no need to
make range checks.

The patch slightly changes SliceQueryFilter to use ranges sets but maintained backwards compatibility.
Public access to start and finish is changed to be done through accessors.

The patch includes a somewhat (maybe too) verbose test of the new and old behavior.

The slice reader assumes that either the whole ranges are read reversed or not (there are
no forward+reversed range mix).

The slice reader assumes that ranges are sorted correctly, e.g. that for forward lookup ranges
are in lexicographic order of start elements and that for reverse lookup they are in reverse
lexicographic order of finish (reverse start) elements. i.e. forward: [a,b],[d,e],[g,h] reverse:
[h,g],[e,d],[b,a]. The reader also assumes that validation has been performed in terms of
intervals (no overlapping intervals).


                  
> Support multiple ranges in SliceQueryFilter
> -------------------------------------------
>
>                 Key: CASSANDRA-3885
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-3885
>             Project: Cassandra
>          Issue Type: Sub-task
>          Components: Core
>            Reporter: Jonathan Ellis
>            Assignee: Vijay
>             Fix For: 1.2
>
>         Attachments: CASSANDRA-3885.patch
>
>
> This is logically a subtask of CASSANDRA-2710, but Jira doesn't allow sub-sub-tasks.
> We need to support multiple ranges in a SliceQueryFilter, and we want querying them to
be efficient, i.e., one pass through the row to get all of the ranges, rather than one pass
per range.
> Supercolumns are irrelevant since the goal is to replace them anyway.  Ignore supercolumn-related
code or rip it out, whichever is easier.
> This is ONLY dealing with the storage engine part, not the StorageProxy and Command intra-node
messages or the Thrift or CQL client APIs.  Thus, a unit test should be added to ColumnFamilyStoreTest
to demonstrate that it works.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message