incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <...@apache.org>
Subject Re: Views per Database
Date Mon, 13 Apr 2009 18:44:16 GMT

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






Mime
View raw message