couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stanley Iriele <siriele...@gmail.com>
Subject Re: Erlang vs JavaScript
Date Thu, 15 Aug 2013 07:05:20 GMT
Whoa...OK...that I had no idea about...thanks for taking the time to go to
that granularity, by the way.

So does this mean that the process memory is shared? As apposed to living
in its own space?.so if someone accumulates a large json object in a list
function its chewing up couchdb's memory?... I guess I'm a little confused
about what's in the same process and what isn't now
On Aug 14, 2013 11:57 PM, "Jason Smith" <jhs@apache.org> wrote:

> 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