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 06:56:17 GMT
To me, an Erlang view is a view server which supports map, reduce, show,
update, list, etc. functions in the Erlang language. (Basically it is
implemented in Erlang.)

A view server is a subprocess that runs beneath CouchDB which communicates
with it over standard i/o. It is a different process in the operating
system and only interfaces with the main server using the view server
protocol (basically a bunch of JSON messages going back and forth).

I do not know of an Erlang view server which works well and is currently
maintained.

A native view (shipped by CouchDB but disabled by default) is some
corner-cutting. Code is evaluated directly by the primary CouchDB server.
Since CouchDB is Erlang, the native query server is necessarily Erlang. The
key difference is, your code is right there in the eye of the storm. You
can call couch_server:open("some_db") and completely circumvent security
and other invariants which CouchDB enforces. You can leak memory until the
kernel OOM killer terminates CouchDB. It's not about the language, it's
that is is running inside the CouchDB process.



On Thu, Aug 15, 2013 at 1:36 PM, Stanley Iriele <siriele2x3@gmail.com>wrote:

> Wait....I'm a tad confused here..Jason what is the difference between
> native views and Erlang views?...
> On Aug 14, 2013 11:16 PM, "Jason Smith" <jhs@apache.org> wrote:
>
> > Oh, also:
> >
> > They are **not** Erlang views. They are **native** views. We should
> > emphasize the latter to remind ourselves about the security and
> reliability
> > risks which Bob identifies.
> >
> > They are very powerful, but it is a trade-off. Once I had a customer who
> > had a basic "class" document describing common values. All other
> documents
> > were for modifications to the "base class" so to speak. He needed to
> query
> > by document ID, but if no such document existed, return the "base class"
> > document instead. The product was already in the field and so the code
> > could not change. We had to change it in CouchDB.
> >
> > The fix was very simple: a _rewrite rule to a native _show function. In
> the
> > show function, if the Doc was null, then we used the internal CouchDB API
> > to fetch the default document. Voila.
> >
> >
> > On Thu, Aug 15, 2013 at 1:08 PM, Jason Smith <jhs@apache.org> wrote:
> >
> > > On Thursday, August 15, 2013, Andrey Kuprianov wrote:
> > >
> > >> Doesnt server performance downgrade, while views are being rebuilt? So
> > the
> > >> faster they are rebuilt, the better for you.
> > >
> > >
> > > If my view build would degrade total performance to cross an
> unacceptable
> > > threshold, then I am really riding the line! What about an unplanned
> > > compaction? What if one day the clients have a bug and load increases?
> > What
> > > if an unplanned disaster happens and a backup must be performed
> urgently?
> > >
> > > I would evaluate view performance in the larger context of the entire
> > > application life cycle.
> > >
> > > Men seem to want to date beautiful women. It is a very high priority at
> > > the pub or whatever. But long-married men do not even think about their
> > > wife's attractiveness because that is a small, superficial part of a
> much
> > > larger story.
> > >
> > >
> > >>
> > >> Besides, looks like it's possible to do the same 3 steps with design
> doc
> > >> views created in Erlang? Or is it just about using require() in
> Node.js?
> > >>
> > >
> > > Actually, yes that is a fine point. I myself prefer Node.js but anyone
> > can
> > > choose the best fit for them.
> > >
> > > And speaking more broadly, CouchDB is a very flexible platform so it is
> > > quite likely that my own policies do not apply to every use case. In
> fact
> > > if I'm honest I use native views myself, usually for unplanned
> > > troubleshooting, I want to find conflicts so I use manage_couchdb:
> > > http://github.com/iriscouch/manage_couchdb
> > >
> > > My main point is, anybody time somebody says "performance" ask yourself
> > if
> > > it is really a "performance siren." Earlier in this thread, Jens raises
> > > some examples of plausible true performance requirements, not just
> siren
> > > songs.
> > >
> >
>

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