[jira] [Comment Edited] (CASSANDRA-11153) Row offset within a partition
[ https://issues.apache.org/jira/browse/CASSANDRA-11153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15141673#comment-15141673 ] Ryan Svihla edited comment on CASSANDRA-11153 at 2/10/16 9:13 PM: -- Ok thinking about this is more, this is basically a "what is worse" option. Folks that need to do horrible paging queries because of some legacy interface that they pass around (http://foo.com/?page=9) will just read the whole partition and throw away the extra AKA lousy client side mode. If we required this be an "ALLOW FILTERING" option, I think that would tag it as a bad idea, but still enable people to do something less horrible than what they're already doing. For smaller partitions this should be plenty fast enough still. was (Author: rssvihla): Ok thinking about this is more, this is basically a "what is worse" option. Folks that need to do horrible paging queries because of some legacy interface that they pass around (http://foo.com/?page=9) will just read the whole partition and throw away the extra AKA lousy client side mode. If we required this be an "ALLOW FILTERING" option, I think that would tag it as a bad idea, but still enable people to do something less horrible than what they're already doing. > 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)
[jira] [Comment Edited] (CASSANDRA-11153) Row offset within a partition
[ https://issues.apache.org/jira/browse/CASSANDRA-11153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15142003#comment-15142003 ] Ryan Svihla edited comment on CASSANDRA-11153 at 2/11/16 12:16 AM: --- 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 cases and it would be nice to give them some approach that is "fast enough" for their needs. was (Author: rssvihla): 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)
[jira] [Comment Edited] (CASSANDRA-11153) Row offset within a partition
[ https://issues.apache.org/jira/browse/CASSANDRA-11153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15142003#comment-15142003 ] Ryan Svihla edited comment on CASSANDRA-11153 at 2/11/16 12:16 AM: --- 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 cases and it would be nice to give them some approach that is "fast enough" for their needs, even if it doesn't scale, even if it's not optimal. Most of these corners are not high perf sub ms latency use cases. was (Author: rssvihla): 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 cases 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)
