The short answer is yes, you can rely on the ordering of keys being consistent. They will always be returned in partitioner order. This is pretty much implied by the existence of the token() function so it's not going to change (if only because changing it would break people).
-- Sylvain On Fri, May 24, 2013 at 4:52 PM, Ondřej Černoš <cern...@gmail.com> wrote: > 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 >
