cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stu Hood (JIRA)" <j...@apache.org>
Subject [jira] Issue Comment Edited: (CASSANDRA-1599) Add sort/order support for secondary indexing
Date Mon, 11 Oct 2010 03:22:12 GMT

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

Stu Hood edited comment on CASSANDRA-1599 at 10/10/10 11:20 PM:
----------------------------------------------------------------

Another issue with local indexes is that implementing sorting would involve a clusterwide
merge sort. A distributed index is required to efficiently return the data in index order.
I think this issue should be delayed for 0.8.0 when we have distributed indexes available:
the indexes available in 0.7.0 are intended for filtering data.

As a multi-part solution, (imo) we should:
 # (optionally) Rename local indexes to "filter_indexes" or "filters"
 # Expose 0.8.0 distributed indexes as readonly column families which are sorted by the index
value, and which are queried using get_range_slices
 # Implement LT/LTE/GT/GTE operations for the key-range in get_range_slices

Outcomes:
 * Your "primary" index expression would be consistently queried using the "range" parameter
in get_range_slices and would define the sort order
 * "filters" (0.7.0 secondary indexes) would be applied using the IndexClause argument as
described on CASSANDRA-1600

I'm going to open another ticket to suggest some changes to index definitions to make this
consistent.


      was (Author: stuhood):
    Another issue with local indexes is that implementing sorting would involve a clusterwide
merge sort. A distributed index is required to efficiently return the data in index order.
I think this issue should be delayed for 0.8.0 when we have distributed indexes available:
the indexes available in 0.7.0 are intended for filtering data.

As a multi-part solution, (imo) we should:
 # (optionally) Rename local indexes to "filter_indexes" or "filters"
 # Expose 0.8.0 distributed indexes as readonly column families which are sorted by the index
value, and which are queried using get_range_slices
 # Implement LT/LTE/GT/GTE operations for the key-range in get_range_slices
Outcomes:
 * Your "primary" index expression would be consistently queried using the "range" parameter
in get_range_slices and would define the sort order
 * "filters" (0.7.0 secondary indexes) would be applied using the IndexClause argument as
described on CASSANDRA-1600

I'm going to open another ticket to suggest some changes to index definitions to make this
consistent.

  
> Add sort/order support for secondary indexing
> ---------------------------------------------
>
>                 Key: CASSANDRA-1599
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-1599
>             Project: Cassandra
>          Issue Type: New Feature
>          Components: API
>            Reporter: Todd Nine
>             Fix For: 0.8
>
>
> For a lot of users paging is a standard use case on many web applications.  It would
be nice to allow paging as part of a Boolean Expression.
> Page -> start index
>            -> end index
>            -> page timestamp 
>            -> Sort Order
> When sorting, is it possible to sort both ASC and DESC? 
>             

-- 
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