From user-return-18386-apmail-couchdb-user-archive=couchdb.apache.org@couchdb.apache.org Fri Oct 21 08:21:49 2011 Return-Path: X-Original-To: apmail-couchdb-user-archive@www.apache.org Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 172B69106 for ; Fri, 21 Oct 2011 08:21:49 +0000 (UTC) Received: (qmail 90181 invoked by uid 500); 21 Oct 2011 08:21:47 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 89564 invoked by uid 500); 21 Oct 2011 08:21:44 -0000 Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@couchdb.apache.org Delivered-To: mailing list user@couchdb.apache.org Received: (qmail 89197 invoked by uid 99); 21 Oct 2011 08:21:43 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 21 Oct 2011 08:21:43 +0000 X-ASF-Spam-Status: No, hits=0.4 required=5.0 tests=FREEMAIL_FROM,FROM_LOCAL_NOVOWEL,HK_RANDOM_ENVFROM,RCVD_IN_DNSWL_LOW,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of cgsmcmlxxv@gmail.com designates 209.85.215.180 as permitted sender) Received: from [209.85.215.180] (HELO mail-ey0-f180.google.com) (209.85.215.180) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 21 Oct 2011 08:21:35 +0000 Received: by eyg5 with SMTP id 5so4731159eyg.11 for ; Fri, 21 Oct 2011 01:21:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=f9wZU5WUd8Q3s0W4H8UqC/0ydKhVgFWvaHWKg3EtjCw=; b=SX3bXdZhHPDElCqiyQiNSPaDOARrgnlaazQ2JSHD5zIg8iYD67klk6hX4v/QfyDEg5 AbOz1asXNVB1LNVe3sGfgGG1XrXCB8JH67Me2QusEeoidbAnpEGMkkCC26nuF+3zO77a MJJO9HNrv3d/BecY+615/YOR4g1YjcBsbgmP8= Received: by 10.14.10.32 with SMTP id 32mr1675439eeu.187.1319185273908; Fri, 21 Oct 2011 01:21:13 -0700 (PDT) Received: from [192.168.1.100] (dynamic-78-8-13-244.ssp.dialog.net.pl. [78.8.13.244]) by mx.google.com with ESMTPS id a49sm32764494eea.2.2011.10.21.01.21.12 (version=SSLv3 cipher=OTHER); Fri, 21 Oct 2011 01:21:12 -0700 (PDT) Message-ID: <4EA12B77.1020609@gmail.com> Date: Fri, 21 Oct 2011 10:21:11 +0200 From: CGS User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110922 Thunderbird/3.1.15 MIME-Version: 1.0 To: user@couchdb.apache.org Subject: Re: Doc design / performace References: <51B19E7DFC2E3A48B48FC8589E03D4C6455DF64B@msmx01.hz.ebalu.local> <2F768B9D-8CAB-4C2D-B42D-756047A9D0F8@gmail.com> In-Reply-To: <2F768B9D-8CAB-4C2D-B42D-756047A9D0F8@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 possible); 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 you > 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 quantities. >> 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