incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <...@apache.org>
Subject Re: Erlang vs JavaScript
Date Fri, 16 Aug 2013 15:54:50 GMT
I think it is worth putting Jason’s and Jens’s viewpoints on a scale of “learning to
live with the pain” and “finding relief for the pain”, where “pain” is any of View
Build Time or View Index Time from Jason’s glossary.

If living with the pain works for you, Jason’s point of view is very valuable because all
you need to is accept the current situation :)

But I think it is also worth considering that there are scenarios where living with the pain
is just not a fun or viable thing to do and then finding relief for the pain is a good strategy.

This thread started a fork on dev@ with concrete engineering suggestions on how to make this
a reality in CouchDB, so please join us there if you want to help out.

Best
Jan
--


On Aug 16, 2013, at 17:24 , Jason Smith <jhs@apache.org> wrote:

> On Fri, Aug 16, 2013 at 10:16 PM, Jens Alfke <jens@couchbase.com> wrote:
> 
>> 
>> On Aug 15, 2013, at 10:14 AM, Jason Smith <jhs@apache.org> 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.)


Mime
View raw message