cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ryan Svihla (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-11153) Row offset within a partition
Date Thu, 11 Feb 2016 00:16:18 GMT


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

View raw message