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.
CGS
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 [[email protected]]
Sent: Friday, October 21, 2011 6:38 PM
To: [email protected]
Subject: Doc design / performace
On 21 October 2011 06:06, Thomas Hommers<[email protected]> 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,
