Sorry if this is beating a dead horse.
On Thu, Aug 15, 2013 at 11:37 AM, Jens Alfke <[email protected]> wrote: > > On Aug 14, 2013, at 8:52 PM, Jason Smith <[email protected]> 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.
