couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Smith <>
Subject Re: Erlang vs JavaScript
Date Fri, 16 Aug 2013 15:24:18 GMT
On Fri, Aug 16, 2013 at 10:16 PM, Jens Alfke <> wrote:

> On Aug 15, 2013, at 10:14 AM, Jason Smith <> wrote:
> > To restate my final sentence which you quoted: Accessing a view is an
> index
> > scan, it hardly matters what the total data size is; therefore after the
> > building period, all views are basically always instantly available.
> You’re missing my point, Jason. Introducing an arbitrary “building period”
> implies you don’t care about the latency between a database update and when
> it becomes visible in view queries. As I said, that may be allowable in
> some types of applications, but definitely not all. To repeat my example,
> an e-commerce customer is not going to tolerate any “building period”
> longer than a second or two in between their clicking “Add To Cart” and the
> item showing up in their cart.

I agree. But a hypothetical "Add to cart" would only be one or two document
updates. That will be reflected in a view query pretty quickly. The HTTP
overhead is probably still the majority of the time spent; updating the
view index to reflect the new cart will be negligible.

Do we agree there? It occurs to me that you and I may work in different
environments. Perhaps you are accustomed to much heavier update frequency
than I.

My own glossary:

View build time: Building the views the first time you push a new design
document into an existing database. Can take a very long time, but can be
done "offline."

View update time: The time it takes couch to update a view to reflect those
updates which happened since either the view build, or the view update
(whichever was more recent).

To me, view update time is regrettable but for most applications
(read-heavy) it is not much of a problem. View build time is not a concern
because you can run it at your leisure and "promote" it to the true
document ID using COPY. In most situations, native views solve a
non-problem (although I've cited a few cromulent exceptions.)

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