You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cassandra.apache.org by Tangram Liu <la...@gmail.com> on 2009/08/12 05:37:00 UTC
New thrift api question.
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:
**<http://www.google.cn/dictionary?q=fascinating&langpair=en%7Czh&hl=zh-CN&ei=CSOCSqinNYOQkQXS3ujiCg&sa=X&oi=translation&ct=result><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?
Re: New thrift api question.
Posted by Jonathan Ellis <jb...@gmail.com>.
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<la...@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 <jb...@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<la...@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?
>>
>
Re: New thrift api question.
Posted by Michael Koziarski <mi...@koziarski.com>.
> Hey, cool. Good find. :)
Evan sent it my way when I asked questions just like Tangram ;)
--
Cheers
Koz
Re: New thrift api question.
Posted by Jonathan Ellis <jb...@gmail.com>.
On Wed, Aug 12, 2009 at 8:41 PM, Michael Koziarski<mi...@koziarski.com> wrote:
> You can still build a one to many list with cassandra, you just can't
> paginate it the way you're expecting.
>
> I'd recommend reading this presentation:
>
> http://www.percona.com/ppc2009/PPC2009_mysql_pagination.pdf
>
> I found it really interesting and made the changes to the
> pagination-related APIs in cassandra make a lot more sense.
Hey, cool. Good find. :)
-Jonathan
Re: New thrift api question.
Posted by Tangram Liu <la...@gmail.com>.
I'm really inspired by the presentation you provide, thanks!
I should refresh my mind in the NoSQL world.
2009/8/13 Michael Koziarski <mi...@koziarski.com>
> > 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.
>
> You can still build a one to many list with cassandra, you just can't
> paginate it the way you're expecting.
>
> I'd recommend reading this presentation:
>
> http://www.percona.com/ppc2009/PPC2009_mysql_pagination.pdf
>
> I found it really interesting and made the changes to the
> pagination-related APIs in cassandra make a lot more sense.
>
> --
> Cheers
>
> Koz
>
Re: New thrift api question.
Posted by Michael Koziarski <mi...@koziarski.com>.
> 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.
You can still build a one to many list with cassandra, you just can't
paginate it the way you're expecting.
I'd recommend reading this presentation:
http://www.percona.com/ppc2009/PPC2009_mysql_pagination.pdf
I found it really interesting and made the changes to the
pagination-related APIs in cassandra make a lot more sense.
--
Cheers
Koz
Re: New thrift api question.
Posted by Tangram Liu <la...@gmail.com>.
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 <jb...@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<la...@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?
>
Re: New thrift api question.
Posted by Jonathan Ellis <jb...@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<la...@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?