number of views pe design doc

[Stanley Iriele <si...@breaktimestudios.com>]

Hello,

I've been using couchdb for a while now and I have had problems in the past
with having too many views in one design doc. what is the recommended
number of view per doc?..is 6 too many?...the documents inside could
potentially be updated quite frequently.

thanks in advance for any comments

-Stanley

Re: number of views pe design doc

[Adam Kocoloski <ko...@apache.org>]

On May 29, 2013, at 8:56 PM, Stanley Iriele <si...@breaktimestudios.com> wrote:

> On Wed, May 29, 2013 at 5:41 PM, Jens Alfke <je...@couchbase.com> wrote:
> 
>> 
>> On May 29, 2013, at 5:23 PM, Stanley Iriele <si...@breaktimestudios.com>
>> wrote:
>> 
>>> I've been using couchdb for a while now and I have had problems in the
>> past
>>> with having too many views in one design doc. what is the recommended
>>> number of view per doc?..is 6 too many?...the documents inside could
>>> potentially be updated quite frequently.
>> 
>> I think it depends entirely on your data and how complex the view
>> functions are.
>> 
>> The thing to remember is that when CouchDB needs to update a view, it
>> updates _every_ view in that design document. If you have some views that
>> are only queried rarely, or have especially slow map/reduce functions, it
>> can help to put them in their own design documents.
>> 
>> —Jens
> 
> 
> 
> Thanks..that makes sense...So..how do reduce functions fit into the
> mix?..when are they updated?.basically if I throw reduce function in...is
> that updated as well when all of the views are updated?..will that slow
> down view generation? I don't really know if reduce functions are called
> one the fly

CouchDB does pre-compute some pieces of a reduce view.  If you're querying the reduce view with group=false it can pre-compute the whole thing and deliver the result directly.  If you're querying with group=true or group_level=N the situation is a bit more complicated.  CouchDB still does a good bit of pre-computation, but it doesn't take the "boundaries" between keys into account.  If you have a small number of unique keys in your view index then CouchDB can do a lot of the work ahead of time.  If each key only appears in a couple of rows then CouchDB will essentially be doing ~all of the reduce work at query time for a group=true query.

Cheers, Adam

Re: number of views pe design doc

[Stanley Iriele <si...@breaktimestudios.com>]

On Wed, May 29, 2013 at 5:41 PM, Jens Alfke <je...@couchbase.com> wrote:

>
> On May 29, 2013, at 5:23 PM, Stanley Iriele <si...@breaktimestudios.com>
> wrote:
>
> > I've been using couchdb for a while now and I have had problems in the
> past
> > with having too many views in one design doc. what is the recommended
> > number of view per doc?..is 6 too many?...the documents inside could
> > potentially be updated quite frequently.
>
> I think it depends entirely on your data and how complex the view
> functions are.
>
> The thing to remember is that when CouchDB needs to update a view, it
> updates _every_ view in that design document. If you have some views that
> are only queried rarely, or have especially slow map/reduce functions, it
> can help to put them in their own design documents.
>
> —Jens



Thanks..that makes sense...So..how do reduce functions fit into the
mix?..when are they updated?.basically if I throw reduce function in...is
that updated as well when all of the views are updated?..will that slow
down view generation? I don't really know if reduce functions are called
one the fly

Re: number of views pe design doc

[Jens Alfke <je...@couchbase.com>]

On May 29, 2013, at 5:23 PM, Stanley Iriele <si...@breaktimestudios.com> wrote:

> I've been using couchdb for a while now and I have had problems in the past
> with having too many views in one design doc. what is the recommended
> number of view per doc?..is 6 too many?...the documents inside could
> potentially be updated quite frequently.

I think it depends entirely on your data and how complex the view functions are.

The thing to remember is that when CouchDB needs to update a view, it updates _every_ view in that design document. If you have some views that are only queried rarely, or have especially slow map/reduce functions, it can help to put them in their own design documents.

—Jens