Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Thu, 11 Feb 2016 00:16:18 +0000 (UTC)
From: "Ryan Svihla (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12938324.1455136830000.22009.1455149778291@Atlassian.JIRA>
In-Reply-To: <JIRA.12938324.1455136830000@Atlassian.JIRA>
References: <JIRA.12938324.1455136830000@Atlassian.JIRA>
 <JIRA.12938324.1455136830157@arcas>
Subject: [jira] [Commented] (CASSANDRA-11153) Row offset within a partition
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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