Return-Path: X-Original-To: apmail-cassandra-user-archive@www.apache.org Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 369C6D029 for ; Fri, 24 May 2013 14:52:39 +0000 (UTC) Received: (qmail 33569 invoked by uid 500); 24 May 2013 14:52:37 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 33108 invoked by uid 500); 24 May 2013 14:52:36 -0000 Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@cassandra.apache.org Delivered-To: mailing list user@cassandra.apache.org Received: (qmail 33080 invoked by uid 99); 24 May 2013 14:52:35 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 24 May 2013 14:52:35 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of cernoso@gmail.com designates 209.85.223.177 as permitted sender) Received: from [209.85.223.177] (HELO mail-ie0-f177.google.com) (209.85.223.177) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 24 May 2013 14:52:29 +0000 Received: by mail-ie0-f177.google.com with SMTP id 9so11868553iec.8 for ; Fri, 24 May 2013 07:52:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=3SJlIMywhN4E+okmqSPOCuKeqlXUycN7+NefUGv4ZO0=; b=DojjvxEw/3CTYWsB3bv3xZUNt2NqWQfUKzxUqt3IcCFr9H1cOV7Tr8oYHtVPRdwxEh du5Zxblo4VWLt4FrUiEBBSzoP47/aV1kUs3sWB4rwYCg2KpSz28uYeq0d8wwwj4Mc7jv eLh8KSU0+V0zeHG0lqU6MCF1PXW5nmePgW+2u0FsXfY0gkHXBs2EJni4zvykzSdJ+clf +W/71MhNNKlfvyFEvYMBo+gKvkJtrDVJ64kM5w9OTUEgUMuzcsDL0OH6u7uJQuhDPAxt LhmjFZ/j4izLKj7VNRLk7Vq9EO0CAJ03RtOzbee5i3Lc21yZpC9oarWLhUZDH3LrdIR4 /8IA== MIME-Version: 1.0 X-Received: by 10.50.115.42 with SMTP id jl10mr7098563igb.71.1369407129431; Fri, 24 May 2013 07:52:09 -0700 (PDT) Received: by 10.42.177.73 with HTTP; Fri, 24 May 2013 07:52:09 -0700 (PDT) Date: Fri, 24 May 2013 16:52:09 +0200 Message-ID: Subject: pagination in cql3 From: =?UTF-8?B?T25kxZllaiDEjGVybm/FoQ==?= To: user@cassandra.apache.org Content-Type: multipart/alternative; boundary=089e0116058280b80e04dd77f19d X-Virus-Checked: Checked by ClamAV on apache.org --089e0116058280b80e04dd77f19d Content-Type: text/plain; charset=ISO-8859-1 Hi all, I need to support a legacy API where page offset and limit are on the input of the API call (it used to be mapped directly to offset and limit MySQL select options). The data are pretty small (like really small, some hundreds of thousands narrow rows maximum - I use Cassandra for its multiple-dc and HA capabilities, not for "big data"). I know the token(key) function and its use for paging, but unfortunately I cannot change the API to a version where last key on previous page and limit would be provided. What I thought I would do - though it is violating good Cassandra practices like "don't fetch all keys" - is the following: select _key_ from table limit _offset_value_; select _columns_ from table where token(_key_) > token(_last_key_from_the_select_above_); The first select tells me where the offset begins and the second one queries for the page. The paged queries will not be performed too often, so performance is not such a big deal here. This construct however depends on repeatable ordering of keys returned from the select key from table query. I don't care about the ordering, but I need to know it is actually ordered by key tokens. Afaik it should be so (SSTs are ordered this way, the coordinator merges the data from queried nodes, ssts and memtables - I suppose it all preserves the order), but I don't know if it really works this way and if it is "documented" so that I can rely on it. Or should it be done some other way? Thanks, Ondrej Cernos --089e0116058280b80e04dd77f19d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all,

I need to support a legac= y API where page offset and limit are on the input of the API call (it used= to be mapped directly to offset and limit MySQL select options). The data = are pretty small (like really small, some=A0hundreds=A0of thousands narrow = rows maximum - I use Cassandra for its multiple-dc and HA capabilities, not= for "big data").

I know the token(key) function and its use = for paging, but unfortunately I cannot change the API to a version where la= st key on previous page and limit would be provided.

What I thought I would do - though it is=A0violating=A0goo= d Cassandra practices like "don't fetch all keys" =A0- is the= following:

select _key_ from table li= mit _offset_value_;
select _columns_ from table where token(_key_) > token(_last_= key_from_the_select_above_);

The first= select tells me where the offset begins and the second one queries for the= page. The paged queries will not be performed too often, so performance is= not such a big deal here.

This construct however depends on repeatabl= e ordering of keys returned from the select key from table query. I don'= ;t care about the ordering, but I need to know it is actually ordered by ke= y tokens. Afaik it should be so (SSTs are ordered this way, the coordinator= merges the data from queried nodes, ssts and memtables - I suppose it all = preserves the order), but I don't know if it really works this way and = if it is "documented" so that I can rely on it.

Or should it be done some other way?
<= div style>
Thanks,

Ondrej Cernos
--089e0116058280b80e04dd77f19d--