couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From CGS <>
Subject Re: Doc design / performace
Date Fri, 21 Oct 2011 08:21:11 GMT
I do tend to agree with Frederick on this one. "I don't know" seems to 
be the real answer here.

Nevertheless, he touched some valuable points in general design which, 
in your case, would be concluded in "divide et impera" (if I understood 
correctly your problem). That means:
1. at the database level, try to achieve better granularity (by 
designing smaller databases with as optimal number of documents as 
2. at the view level, use pagination (10 subproducts per page would 
allow enough time to build all the views until the user hits the button 
for the next page).

Keep in mind that if you don't find a way, you who knows the best your 
project requirements, nobody can find it for you unless that person is 
really into your project.

On 10/21/2011 08:29 AM, Frederick Dalgleish wrote:
> The real answer I have for you is "I don't know."
> The other answer is a bunch of generalities, some of which may be even true, all of which
> probably have already considered....but if not, here goes.  All of this is worth what
you paid for it....the advice that is.
> The number one rule of design is to make the granularity of your design such that each
document is about
> equal to an object in an object oriented programming language, let's say, Objective C
for kicks and grins.
> So an object might be a dog.  A dog is a product in your schema.  A dog or a product
might have characteristics, like objects do.
> Dogs have sizes, colors and tail lengths.  Products have prices, quantities and maybe
colors or something.
> The product is a document.  The fields are the characteristics.
> The second rule of design is that a million items in CB won't process as fast as say,
10 items.  So feel free to have a bunch of
> databases with fewer numbers of objects in them.  Consider scaling up to more servers.
 Consider getting better advice than mine.
> That won't be difficult.
> The third rule of design is to remember the machine and/or the CB product you are using.
 A CB product which caches some of
> the more frequently used or frequently somethinged items in RAM, rather than forcing
all the fun to and from the disk which is spinning
> as fast as that poor disk is able, trying to keep up with your app....will be faster
than otherwise.  So consider Membase related products.
> The fourth rule of design has nothing to do with design.  It isn't really a rule.  It
just says that things go faster when the machine has more
> cycles per second, more processors, higher bus speeds, higher bandwidth to and from the
server, more RAM, and a billion other little things.
> All the external to the server stuff can be ruled out if you are using localhost, probably.
> So, if your machine is the cat's meow and your budget for software and CB help instances
is limitless, you are certain to figure this out.
> Cheers.  FD
> PS  If you get an answer to your question that really rocks, please consider sharing
it with me (us).
> On Oct 21, 2011, at 12:06 AM, Thomas Hommers wrote:
>> Hi,
>> i am quite new to couchDB and trying to build a sales application.
>> 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.
>> 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.
>> The problem i am facing is that it takes a long time to display an overview of all
>> 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

View raw message