Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of ladicek@gmail.com designates
 209.85.214.180 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <A7D50E04F38FD44D9D914F2ABCA592BF2E6E690788@BE259.mail.lan>
References: <A7D50E04F38FD44D9D914F2ABCA592BF2E6E690685@BE259.mail.lan>
	<08E52809-C962-4E9C-AFB8-397EA201580E@utt.fr>
	<A7D50E04F38FD44D9D914F2ABCA592BF2E6E6906AD@BE259.mail.lan>
	<A7D50E04F38FD44D9D914F2ABCA592BF2E6E6906BB@BE259.mail.lan>
	<CABvT1DGGZ0344rwYwbS=n=ctF2YKjLWVqg-fq4zX8YhyAE8QEQ@mail.gmail.com>
	<A7D50E04F38FD44D9D914F2ABCA592BF2E6E6906DE@BE259.mail.lan>
	<CAPmACT7BMOQHF0Ny==qPqrP4kinAa9eCPy9bfF=CV2ucas_WjQ@mail.gmail.com>
	<A7D50E04F38FD44D9D914F2ABCA592BF2E6E690751@BE259.mail.lan>
	<CABvT1DHd67vuXnO+5aC4QOEGFW56x0tDBJEiKCx8anbrWxWs+Q@mail.gmail.com>
	<A7D50E04F38FD44D9D914F2ABCA592BF2E6E690788@BE259.mail.lan>
Date: Fri, 25 May 2012 17:17:15 +0200
Message-ID: 
 <CALbocOm01zLrAk_D3cTzX3M1EOoSXeh6v3iA7a-BAvf94YTTZA@mail.gmail.com>
Subject: Re: Am I doing something fundamentally wrong?
From: Ladislav Thon <ladicek@gmail.com>
To: user@couchdb.apache.org
Content-Type: multipart/alternative; boundary=f46d043c7fc80ed0a904c0ddddaf

--f46d043c7fc80ed0a904c0ddddaf
Content-Type: text/plain; charset=ISO-8859-1

>
> Clearly I seem to be a bit of a loan voice on this as everyone skirts
> around the why do views take so long to build, why do they only run on one
> CPU and why do they take up so much space


I don't really understand CouchDB, so I'm not afraid to (try to) answer
this and be (quite possibly) wrong :-)

1. "why do views take so long to build" -- because for every document, a
JavaScript function has to be executed. This function is executed by a
separate process (view server), in this case the "couchjs" process. As your
documents are fairly large, this might incur significant
serialization/deserialization overhead. Views can also be written in
Erlang, AFAIK, and I bet that would be a hell of a lot faster.

2. "why do they only run on one CPU" -- because order of processing still
matters here (to make incremental view updates possible), even if it is
called "map reduce". It would surely be possible to write a parallel
implementation, but it's more tricky than it looks on the first sight.
Noone just did it yet.

3. " why do they take up so much space" -- because of CouchDB's append-only
B-tree nature. Your views seem to have pretty random keys (as the keys are
IDs of your documents), which means that a lot of inner nodes have to be
created only to be discarded few moments later. Note that discarded here
means that no pointer points at them, but they are still lying on the disk.

All in all, I'd say that CouchDB isn't exactly great fit for an OLAP-style
workload.

LT

--f46d043c7fc80ed0a904c0ddddaf--