incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Myung <dmy...@dimagi.com>
Subject Re: "reverse" view - find out views that a doc affects?
Date Thu, 15 Aug 2013 03:30:33 GMT
Our issues with exploring caching "after" couch db stems from a variety of
reasons.

1:  We do a lot of varied view calls on a single page to assemble our
pages. We ajax the big stuff, but basic other parts that need to be timely
and updated can routinely run between 80-250ms per view call.
2:  A view with an include_docs=True or even a single doc get runs 50-75 ms
on a good day, and could be more if background reindexing or other burdens
on our server are high.
3:  A lot of said views are already very efficient as you said since the
couch view is already an index, but there is still a retrieval burden we
experience. It's consistent and predictable, but it adds up.
4:  Our couch db server is running off an encrypted volume (ecryptfs - due
to it hosting medical data) so we theorize that most of the OS level
caching on views and docs for some reason we are not benefiting from at all.
5:  The contents of the frequently accessed documents and views we want are
infrequently updated. Where queries are unavoidable like reduce views and
frequently updated information (like encounters and such), we rely on the
views directly and try to background load the UI where needed.

Going back to point 4, our requests for pure couch retrieval can range from
800-3000 ms retrieving this information. A very simple in-memory caching
test effectively eliminated that latency (don't have real numbers, but it
is on the order of a 10-15x speed improvement for us.

Dan


On Wed, Aug 14, 2013 at 12:49 PM, Stanley Iriele <siriele2x3@gmail.com>wrote:

> Is the bottleneck actual http round trips? Or view building?... If there
> are no changes to said database... And the vies has been built it will be
> fast....couchdb does a very good job about this... I'm not sure if it does
> etaging for views but there is some equivalent.
>
> What is the problem your facing?
> On Aug 14, 2013 9:31 AM, "Filippo Fadda" <filippo.fadda@programmazione.it>
> wrote:
>
> > No, there is not. This is an information that knows only who wrote the
> > view map function. I remember you, every document pass through each
> views,
> > and only there, inside the map function, you decide to emit or discard
> the
> > document from the view.
> > If a view has been updated, even if the document you have inserted is not
> > emitted for that view, this could be a bug and you should report it. The
> > view is an index, and an index shouldn't change if you are not inserting
> a
> > new node.
> >
> > -Filippo
> >
> > On Aug 14, 2013, at 6:12 PM, Daniel Myung wrote:
> >
> > > Is there a way or a mechanism or trick or hack of some sort to find out
> > for
> > > a given doc I deposit to couch to find out what views it affects? Is
> > there
> > > a record of doc ids being operated upon in a design doc reindexing
> > > operation?
> > >
> > > for various reasons, we're looking to reduce the number of view call
> > round
> > > trips that our application does on couch, and were looking to cache the
> > > view response...but invalidation due to *new* docs that could show in
> the
> > > view (that we haven't seen) has been preventing us from going further
> > down
> > > this route.
> > >
> > > Thanks
> > >
> > > Dan
> >
> >
>

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