incubator-couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From CGS <>
Subject Re: Post-mortem
Date Fri, 11 May 2012 14:57:24 GMT

I do not quite understand why so much fuzz on something which is clearly
not CouchDB fault. Maybe someone is able explain to me (maybe I am too slow
for such high level subject).

What I don't understand is the followings:
1. Those guys wanted a single front-end server which should keep up with
the incoming requests, correct? As far as I understood, CouchDB philosophy
is based on safety of the data, which was implemented as direct writes on
harddisk. So, having only one front-end server on which you force its hdd
to to keep up with the high speed internet connection is just like you want
to force a river to flow only through a mouse hole. I have problems in
understanding how this can happen. Does anyone know?
2. How can you implement NoSQL on an SQL product? Is like curving an apple
in a shape of banana and sell it as such. Am I missing anything here?
3. If MySQL is the future, then how come many service providers with a lot
of users moved to NoSQL?

Yes, there may be some points where CouchDB doesn't excel, but before
choosing a product, you take a look at what it offers, you don't buy the
box without looking what's inside, I suppose. Otherwise, it seems that
person doesn't know what happend to Pandora.

So, in the end, what matters is how this product will go on, not what some
think of. A word for devs: keep up with the good work!


On Fri, May 11, 2012 at 3:37 PM, Noah Slater <> wrote:

> More comments here:
> Not sure how useful they are...
> (Not caught up with the thread yet, sorry!)
> On Fri, May 11, 2012 at 2:34 PM, Dirkjan Ochtman <>
> wrote:
> > On Fri, May 11, 2012 at 3:25 PM, Robert Newson <>
> wrote:
> > > We're veering off-topic here, but there are several remaining issues.
> > > First is that the view file is at some update_seq relative to the
> > > database file. Being at update_seq N for a view means it has all the
> > > changes up to and including N, but nothing after N, so while those
> > > updates could be processed in parallel, they'd have to be applied to
> > > the view process and view file in order.
> >
> > Yeah, you'd have to serialize and buffer when writing to disk again.
> >
> > > Secondly, and more
> > > importantly, is how to handle rows that, for whatever reason, cause an
> > > exception when evaluated in the function (e.g, the common case where
> > > there's an undefined property and no guard clause). If the order is
> > > not determined, then two database, with the same data and same view
> > > code, will have different view results for the same input.
> >
> > I'm actually not clear on what happens with erroring view functions.
> > Does it just stop processing any further document revisions?
> >
> > In any case, it seems okayish to do have the document updates be in a
> > defined ordering but parallellize execution of the view function, then
> > serialize back into document order when the results come back, doing a
> > little buffering if the results aren't in order.
> >
> > Cheers,
> >
> > Dirkjan
> >

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