couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Newson <>
Subject Re: Doc design / performace
Date Thu, 27 Oct 2011 15:58:33 GMT
Hi Thomas,

All the views in a design document are built at the same time and
written to the same file. So one big difference between having one doc
versus several is that having several allows views to be built in
parallel. Depending on your server hardware this could be a very
significant difference. Another is that modifying one view in a design
document will invalidate all views in that document (they will all be

The execution time of the map function is rarely the bottleneck, it's
dominated by the I/O of reading and writing.


On 27 October 2011 16:38, CGS <> wrote:
> At point 3:
> As long as you name each view, there shouldn't be any difference in between
> creating more design documents and having one design document (maybe having
> a single design document would help in limiting the number of documents in a
> database). That's because the access is based on path and the view build is
> done at the time of the first request (updated at the database change).
> A more important thing is to optimize your views by reducing the number of
> operations in it to exactly what you need. Don't forget that the view
> functions are applied to each document from the database. So, defining more
> views (even in the same document) with more specific tasks can speed up the
> build operations (considering you don't use them recursively for the same
> operation because that would slow down the overall process). In the case of
> needing more than one dedicated task for one operation, you can define a
> multiple choice view (e.g., one view with if else statement for simple
> conditions).
> Other than these, I don't know any recommendation.
> On 10/27/2011 12:23 PM, Thomas Hommers wrote:
>> Hi,
>> thanks for all the advise.
>> I know my question might have been a bit "general", but i think some of
>> the therefore "general" advise i received lead me to the right direction.
>> About the performace:
>> 1. after some research i found in the logs an error "127" that had
>> something to do with the spidermonkey installation. After solving this the
>> speed increased immediately.
>> 2. I will try to split the data into different databases.
>> 3. I maybe should separate some views into their own design documents. Is
>> there any best practice when to do that and what views should stay in one
>> design-doc and what views should have their own doc?
>> 4. I used the build-in _sum in the reduce function and think this
>> increased the speed too.
>> 5. I need to look into python-couchdb, as i just read there is also a bug
>> that causes speed issues.
>> Regards
>> Thomas
>> ________________________________________
>> From: Dave Cottlehuber []
>> Sent: Friday, October 21, 2011 6:38 PM
>> To:
>> Subject: Doc design / performace
>> On 21 October 2011 06:06, Thomas Hommers<>  wrote:
>>> Hi,
>>> i am quite new to couchDB and trying to build a sales application.
>> Welcome!
>>> I designed a document as product. One product consist of multiple
>> sub-products that are unique to one product.
>>> Next i designed a sales document that consists of multiple products. The
>> quantity of each sub-product can be chosen independent.
>> Does 1 doc = 1 product incl all sub-products? or are there references
>> within
>> 1 doc to another, .e.g to use via include_docs=true? Perhaps you can post
>> a
>> link to a few sample docs for us to look at.
>>> When i know want to see the total sales quantity, i created a view that
>> runs through all sales-docs and emits the sold quantity, with the product-
>> and sub-product-number as keys. This way I am able to see the sold
>> quantity
>> by product and by sub-product with a reduce function.
>> Ditto. This seems reasonable, and given that once the view is built, the
>> intermediate values are cached in the view file, this shouldn't be too
>> slow.
>>> The problem i am facing is that it takes a long time to display an
>> overview of all quantities.
>> What is your expectation vs what you saw? How are you querying the view?
>>> Did i maybe design something wrong and should take another approach? e.g.
>> maybe I should create a doc for each sub-product instead of having them
>> all
>> in one product-doc? Would this be faster?
>>> I am really thankful for any advice, hint or comment.
>>> Regards
>>> Thomas
>> Generally,

View raw message