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

Ryan Svihla commented on CASSANDRA-11153:
-----------------------------------------

Use case is something like this:

1. Stateless servers so all useful data has to be passed over the URL (and can 
bump around randomly to different servers so you start talking shared cache for 
the state)
2. permalinks based on page number to never changing data.

the only valid alternative to this is they would have to retain the "start id" 
which still requires them figuring out what that is in the first place, and so 
they'll have to do something like this, client side, still.

Again this is not how I would ever design an application, but this is hyper 
common in legacy use case and it would be nice to give them some approach that 
is "fast enough" for their needs.

> Row offset within a partition
> -----------------------------
>
>                 Key: CASSANDRA-11153
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-11153
>             Project: Cassandra
>          Issue Type: New Feature
>            Reporter: Ryan Svihla
>            Priority: Minor
>
> While doing this across partitions would be awful, inside of a partition this 
> seems like a reasonable request. Something like:
> SELECT * FROM my_table WHERE bucket='2015-10-10 12:00:00' LIMIT 100 OFFSET 100
> with a schema such as:
> CREATE TABLE my_table (bucket timestamp, id timeuuid, value text, PRIMARY 
> KEY(bucket, id));
> This could ease pain in migration of legacy use cases and I'm not convinced 
> the read cost has to be horrible when it's inside of a single partition.
> EDIT: I'm aware there is already an issue 
> https://issues.apache.org/jira/browse/CASSANDRA-6511. I think the partition 
> key requirement is where we get enough performance to provide the flexibility 
> in dealing with legacy apps that are stuck on a 'go to page 8' concept for 
> their application flow without incurring a huge hit scanning a cluster and 
> tossing the first 5 nodes results.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to