[ 
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 implements 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 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)



                  
> 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

        

Reply via email to