incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Smith <...@apache.org>
Subject Re: Erlang vs JavaScript
Date Thu, 15 Aug 2013 17:14:56 GMT
Sorry if this is beating a dead horse.


On Thu, Aug 15, 2013 at 11:37 AM, Jens Alfke <jens@couchbase.com> wrote:

>
> On Aug 14, 2013, at 8:52 PM, Jason Smith <jhs@apache.org> wrote:
>
> > View building time feels important during development but it is
> irrelevant
> > during operation. Production servers never hold up requests to build
> views,
> > so the performance is secondary.
>
> Wait, what? I may be mis-reading that, but it doesn’t make sense to me, at
> least not in the absolute terms you’re using. I can think of plenty of
> situations where an app server needs an up-to-date view query to get the
> correct data, and can’t just get away with using stale=true.
>

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.

And my point was, if you use the PPP trick I described (and most production
applications should be, IOMO), then every view, even hundreds of gigabytes,
comes on-line in an instant and querying it is log(n) or whatever. So when
I said "never" I should say "average delay approaches zero as time ->
infinity" or in other words "building views sucks, but you should do that
offline, so who cares?"

The only place where my point fails is that CouchDB updates views not when
you provide new data, but when you query for it. Most applications are
read-heavy, so this is not so bad, but sometimes I wish CouchDB would not
send me a 201 until the views were current. That is one of the few places
CouchDB differs from Google App Engine.

As a practical matter, if somebody said their views do not update fast
enough, I would give them my usual chestnut: your hardware is underpowered.
How many writes can possibly arrive that hang up your view queries so badly?

Unfortunately bitter experience has taught me the answer. About ten
thousand. If you get ten thousand updates (which is easy with bulk_docs,
but even an untuned server can nearly handle about that many concurrent
connections), then you get appreciable downtime on your views. Sad but true.

And in my experience ?stale=ok is just turning a simple problem into a
complex problem multiplied by a scheduling problem.

So that is the only exception I would make but my basic point is, build
views offline and COPY them into production and for all your applications
can tell, they are up instantly. Hope that clarifies my point.

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