cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ben Pirt (JIRA)" <j...@apache.org>
Subject [jira] Commented: (CASSANDRA-1600) Merge get_indexed_slices with get_range_slices
Date Mon, 31 Jan 2011 11:37:11 GMT

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

Ben Pirt commented on CASSANDRA-1600:
-------------------------------------

Hopefully it is useful to get another use case for why this is important to a real-world user.

We are storing time-series data and would like to be able to pull out all values between time
A and time B that have a specific value as a property. Because we aren't able to combine a
range slice with an indexed slice we are having to duplicate our data into several keyspaces
so we can still do the range slice. Our ideal scenario would be to be able to say "Give me
all keys between time A and time B whose property P is greater than or equal to 5"

I would imagine that in another time-series type scenario of storing lots of logs (e.g. Apache
logs) it would be very useful to say "Give me all logs between time A and time B with a status
code of 200"

Please do let me know if I'm misunderstanding things and that there is a better way of doing
this, but it seems to me that it would be very useful functionality. Very much looking forward
to 0.8 for this fix alone!

> Merge get_indexed_slices with get_range_slices
> ----------------------------------------------
>
>                 Key: CASSANDRA-1600
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-1600
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: API
>    Affects Versions: 0.7 beta 1
>            Reporter: Stu Hood
>             Fix For: 0.8
>
>         Attachments: 0001-Add-optional-IndexClause-to-KeyRange-and-serialize-wit.txt,
0002-Drop-the-IndexClause.count-parameter.txt, 0003-Execute-RangeSliceCommands-using-scan-when-an-IndexCla.txt,
0004-Remove-get_indexed_slices-method.txt, 0005-Update-system-tests-to-use-get_range_slices.txt,
0006-Remove-start_key-from-IndexClause-for-the-start_key-in.txt, 0007-Respect-end_key-for-filtered-queries.txt,
0008-allow-applying-row-filtering-to-sequential-scan.txt, 0009-rename-Index-Filter.txt, AbstractScanIterator.java
>
>
> From a comment on 1157:
> {quote}
> IndexClause only has a start key for get_indexed_slices, but it would seem that the reasoning
behind using 'KeyRange' for get_range_slices applies there as well, since if you know the
range you care about in the primary index, you don't want to continue scanning until you exhaust
'count' (or the cluster).
> Since it would appear that get_indexed_slices would benefit from a KeyRange, why not
smash get_(range|indexed)_slices together, and make IndexClause an optional field on KeyRange?
> {quote}

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message