I get the impression that you are paging through a single partition in Cassandra? If so you should probably use bounds on clustering keys to get your "next page". You could use LIMIT as well here but it's mostly unnecessary. Probably just use the pagesize that you intend for the API.
Yes you'll need a table for each sort order, which ties into how you would use clustering keys for LIMIT/OFFSET. Essentially just do range slices on the clustering keys for each table to get your "pages". Also I'm assuming there's a lot of data per partition if in-mem sorting isn't an option, if this is true you will want to be wary of creating large partitions and reading them all at once. Although this depends on your data model and compaction strategy choices. On 3 October 2017 at 08:36, Daniel Hölbling-Inzko < daniel.hoelbling-in...@bitmovin.com> wrote: > Hi, > I am currently working on migrating a service that so far was MySQL based > to Cassandra. > Everything seems to work fine so far, but a few things in the old services > API Spec is posing some interesting data modeling challenges: > > The old service was doing Limit/Offset pagination which is obviously > something Cassandra can't really do. I understand how paginationState works > - but so far I haven't figured out a good way to make Limit/Offset work on > top of paginationState (as I need to be 100% backwards compatible). > The only ways which I could think of to make Limit/Offset work would > create scalability issues down the road. > > The old service allowed sorting by any field. If I understood correctly > that would require a table for each sort order right? (In-Mem sorting is > not an option unfortunately) > In doing so, how can I make the Java Datastax mapper save to another table > (I really don't want to be writing a Subclass of the Entity for each Table > to add the @Table annotation. > > greetings Daniel >
