incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ayende Rahien" <aye...@ayende.com>
Subject Re: Associating users and comments
Date Thu, 02 Oct 2008 20:07:56 GMT
The problem here is not IPC, it is latency. And having to do parallel reads
tends to be non trivial in many client scenarios (having to do explicit
thread management, not good).

On Thu, Oct 2, 2008 at 11:04 PM, Chris Anderson <jchris@apache.org> wrote:

> On Thu, Oct 2, 2008 at 12:49 PM, Alan Bell
> <alan.bell@theopenlearningcentre.com> wrote:
> > Jeremy Wall wrote:
> >> Or you can create a last 5 posts for users view. There is nothing wrong
> with
> >> that.
> > But you can't can you? You could create a view of posts for a user and
> > retrieve the top 5 rows, but you can't control a documents presence in
> > the view based on the number of other documents that may or may not be
> > in the view already I think. Maybe I am being overly pedantic here!
> >
>
> to requote myself:
> >
> > Alternatively, how would I have it return only 5 Paste's max for each
> user?
> >
> can't really do that in one request... a request to the map per human
> with
> startkey=["097337c75773737022bb4e8cd3a92140"]&endkey=["097337c75773737022bb4e8cd3a92140",{}]&count=6
> would do it.
>
> and to follow up, I agree with Jeremy when he says:
>
> > Alternatively, you can do the 20 roundabouts but in parallel so the
> latency
> > hit is only the longest roundtrip. CouchDB shouldn't have any problem
> with a
> > lot of simultaneous reads at once.
>
> CouchDB handle concurrency well, and shies away from query options
> that would negatively impact it's ability to do so. That means cases
> like this push more work to the client. Maybe the IPC overhead
> outstrips the lower load on CouchDB's internals, maybe it doesn't... I
> guess we'll learn as we go along.
>
>
> --
> Chris Anderson
> http://jchris.mfdz.com
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message