incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <>
Subject Re: Views per Database
Date Thu, 16 Apr 2009 06:36:13 GMT
Sorry for resending this, it seems there was failed sending
attempt when I sent the mail (and the other two) originally
and they ended up in some queue that now got flushed.


On 13 Apr 2009, at 12:25, Jan Lehnardt wrote:

> 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
> --

View raw message