incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From CGS <cgsmcml...@gmail.com>
Subject Re: Doc design / performace
Date Thu, 27 Oct 2011 15:38:18 GMT
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 [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