couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Hommers <thomas.homm...@ebalu.com>
Subject RE: Doc design / performace
Date Thu, 27 Oct 2011 10:23:24 GMT
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 [dave@muse.net.nz]
Sent: Friday, October 21, 2011 6:38 PM
To: user@couchdb.apache.org
Subject: Doc design / performace

On 21 October 2011 06:06, Thomas Hommers <thomas.hommers@ebalu.com> 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,

Mime
View raw message