cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Ellis <jbel...@gmail.com>
Subject Re: New thrift api question.
Date Thu, 13 Aug 2009 01:28:36 GMT
It's impossible to implement offset either performantly or safely in a
distributed log-structured merge system that supports deletes.  The
original API punted on all three of those.  0.4 doesn't.  See
https://issues.apache.org/jira/browse/CASSANDRA-261 for a discussion
of performance (we decided that that alone wasn't enough to keep the
feature out) and https://issues.apache.org/jira/browse/CASSANDRA-286
for details on the safety problems (which broke the camel's back).

It sucks when you have to take functionality *out* but that was the
only sane option here.  IMO, compared to manual sharding a relational
DB (in which case you still can't just do a simple offset when you
cross partitions!), pulling out NxM results where N is the number of
pages and M is the number of results per page isn't that big a deal.

Or just throw some ajax magic in to make the ugly next button go away,
like the slashdot front page does with the scrollbar. :)

-Jonathan

On Wed, Aug 12, 2009 at 8:22 PM, Tangram Liu<langram@gmail.com> wrote:
> Thanks for your reply. But I really don't want to use a ugly "next" button
> or just only capable return 100 results in 10 pages. I just can't understand
> why cassandra's new api remove this useful feature and replace with the new
> one.
>
> Pagination is an extremely common use case scenario in web app programming.
> almost every web app need “one to many” data model. when the “many” part is
> too many to fit in one page, paginate is the best way to resolve it. in most
> case, we don't need query or sort the result in a complicated way. we just
> need save them in time or alphabetic order, view first 20 records and
> provide an paginator at the bottom for the others. this is one reason
> why enhanced
> key-value(pure k-v db is too sample and relational db is too
> comprehensive, we need something between them) database coming popular
> recent year.
>
> i think one of the most basic function the enhanced k-v db should
> provide is the capability to define 'one to many' relationship(many to
> many relationship can build with two 'one to many' list).
>
> the old api can build 'one
> to many' list in a very sample way - just use 'one' part as key, and
> 'many' part as a list of columns which sort in time or alphabetic
> order and paginate them with start and count parameters. with new api
> i just can't figure out how to build it.
>
> could anyone here tell me why new api abandon the old design? how to
> build 'one to many' relationship in a effective way with new api? what
> data model should i use? thank?
>
> 2009/8/13 Jonathan Ellis <jbellis@gmail.com>
>
>> The easy way is to just show one page of results and have a Next
>> button that uses start=last one from current page.
>>
>> The slightly harder way if you want to show say 10 links to the next
>> 10 pages is, you have to select 10 pages worth of data and manually
>> offset into that.
>>
>> -Jonathan
>>
>> On Tue, Aug 11, 2009 at 10:37 PM, Tangram Liu<langram@gmail.com> wrote:
>> > Hi, there! I'm new to cassandra. and I think it fascinating.
>> >
>> > I got a question here:
>> >
>> > image a simple blog host app base on cassandra with the following data
>> > model:
>> >
>> > <Keyspaces>
>> >     <Keyspace Name="MultiBlog">
>> >         <ColumnFamily CompareWith="TimeUUIDType" Name="Blogs">
>> >     </Keyspace>
>> >  </Keyspaces>
>> >
>> > for each new blog article, insert with blog name as the key, article
>> title
>> > as the column name and article content as value.
>> >
>> > here is the question: how can i build a blog paginator with new api?
>> >
>> > with old api, i can simple use get_slice to get what i want(start=page
>> > offset, count= row per page). but new api, however, change the start
>> > parameter type from int to string. how can i build a paginate function
>> with
>> > new api?
>>
>

Mime
View raw message