couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Landolt <>
Subject Re: [user] Thoughts on document/views...
Date Wed, 11 Feb 2009 21:53:39 GMT
On Wed, Feb 11, 2009 at 4:45 PM, Damien Katz <> wrote:

> On Feb 11, 2009, at 4:29 PM, Chris Anderson wrote:
>  On Wed, Feb 11, 2009 at 10:28 AM, Wout Mertens <>
>> wrote:
>>> On Feb 11, 2009, at 7:22 PM, kowsik wrote:
>>>> What I'm getting at is, does it make sense to have some type of
>>>> document "class" attribute and then have views bound to these classes?
>>>> The goal, of course, being that couch-db can pre-filter a lot of these
>>>> things and only run the views for the appropriate types of documents.
>>> I'm probably speaking before my turn being such a newbie, but why
>>> wouldn't
>>> you create a new database for disjoint classes of documents?
>> That's the basic rule of thumb: Document only need to be in the same
>> database with each other, if they need to be run through the same
>> views (or they need to be replicated together).
>> If you have a db with millions of records, but only a handful of them
>> are interesting to to your views, you will save a lot of serialization
>> by putting the viewed documents in their own database.
>>> Also, once a view is run on a document, it doesn't get re-run that often
>>> does it?
>> Views are run one per document update, so if you write the document
>> once, it only gets run through the view server once.
>> If you have say, 5 different document "classes" and you have views
>> that care about each of them, if you put those views in the same
>> design document, then you will not have extra serialization hits. Each
>> document update is sent to the view server once per design document.
>>> So other than eating diskspace, maybe there's not really anything wrong
>>> with
>>> keeping everything in one db.
>> My recommendation is to not worry about it, unless you have like 75%
>> or more docs that don't show up in any view. In that case, those docs
>> might better off in another database.
> I agree with Chris. The way view indexes are updated en-masse, it makes
> this mostly a non-issue.

Antony did bring up an interesting (perhaps inevitable) optimization though
-- in light of jchris' comments the guards won't do much good, but it'd make
an interesting (post 1.0, obviously) addition to the erlang api to be able
bypass view server i/o and json roundtripping. I probably wouldn't ever need
it, and at first I'd gag a little when I cracked open someone else's erlang
design doc, but it could lower the penalty for having a number of boutique
third-party design docs in a database.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message