Return-Path: Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: (qmail 38482 invoked from network); 16 Apr 2009 00:51:19 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 16 Apr 2009 00:51:19 -0000 Received: (qmail 77292 invoked by uid 500); 16 Apr 2009 00:51:18 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 77213 invoked by uid 500); 16 Apr 2009 00:51:18 -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 Delivered-To: moderator for user@couchdb.apache.org Received: (qmail 46913 invoked by uid 99); 13 Apr 2009 10:26:41 -0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of janlehnardt@googlemail.com designates 209.85.218.170 as permitted sender) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=cDa5a6ug3wH0Nn41uABkcE6TbTxxY69YN2/8tPU3db8=; b=xfhwaB32kn36AzYZbDnCjYdRx7x5IquZMJTAhnRgDbHje5GfIg+cPVrlNVyCmJ10rq YkE5iKA6D9SjTY5HI9LwAi5gQmSthQzmN9m0qyLdBbvBqnuU/dNrOU5TT8ufU/Y4MOF0 jyE/an37EDDriY2xF/Vz9q8sHErUd3FyS1m7Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=G8ElSWvGmxakjp0kbG92DxwXlRF+TFSBRTPRLorWkadImlFxprjV3lHb30Iyo84Ykt 8o0qpOPL0N7MTkHtsNyuzQ3+nFDwJLROHwc68+7qR93h98lF6OC7gk/2Kv0j73y1JiWY Pb2Aliyr1oJ6aCHKmkXfSrCeVEvAkaKl6UQUI= Message-Id: <4B0DE6AF-82F9-40C8-A77B-2CEB7AF846EE@apache.org> From: Jan Lehnardt To: user@couchdb.apache.org In-Reply-To: <9acd6e550904130015q21f00353h751970cfa1f3a23f@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: Views per Database Date: Mon, 13 Apr 2009 11:25:35 +0100 References: <9acd6e550904130015q21f00353h751970cfa1f3a23f@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) X-Virus-Checked: Checked by ClamAV on apache.org On 13 Apr 2009, at 08:15, Thomas Heller wrote: > Hey there, > > My CouchDB Project is coming along nicely but I came about one concern > recently. While my Database is quite small at the moment (only about > 500kb > in docs) I already have 7 design docs, 12 map only views, 6 map/reduce > views. Now my "concern" is when traffic picks up and "write" activity > increases that certain parts of the site will become "slow". > > For example I have a Forum on the Site which uses 3 views (list > categories, > list posts with last comment for each category, list comments for each > post), basic stuff and works fine right now. But since every updated/ > new doc > has to pass any view (when called) I fear that many "writes" to the > forum > may force constant updates for other views on the site. I know its > superficial but still. > > Basically what I'm asking: Does anyone have any experience how many > design > docs/views per Database is a "good" value? I could move any > "module" (forum, > wiki pages, etc) to its own database but that would add a little > maintenance > overhead which might be totally unneeded. I expect to have about 15 > design > docs with about 30 views when I'm done. Should I move each view > function to > its own design doc? Like I said my Database currently has about 150 > docs so > any testing I do is kinda pointless since everything will be fast > enough, > guess I'll have to write some "noise" simulator which just adds > documents > over time and see where it leads me. Having more views in a design document makes better use of your resources. For each design document, CouchDB fetches a document from the databases, serializes it into JSON, sends it to the view server, the view server deserializes it into a native JavaScript object and sends it through all map functions. The (de-) serialization is expensive. Executing a bunch of map functions is not. You should only separate out views into their own design docs when they are truly separate. Say you have a very complex map function (including parsing and whatnot), you might want to trigger the building of that view from a cronjob or message bus instead of the live application. But mostly, all views that belong to a single application can go into a single design document. CouchDB's internal architecture is designed to batch-update views on- read and there are ways to make that even faster in the future. One option you might be interested in is the `?stale=ok` option for view queries. It will return whatever is in your view index right now instead of triggering an update (or waiting for one to finish). That way you can get slightly not-recent data faster. Cheers Jan --