Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: <572D0890-3DA8-4AE4-AB9F-54EA200E747A@apache.org>
References: <7db9abd30902111022i6c7f6385n23beba458565afb@mail.gmail.com>
	 <58546136-8137-45D1-A3EF-D9226C6B26F0@cisco.com>
	 <e282921e0902111329g2cc9efdue37ca3ef80a01e78@mail.gmail.com>
	 <572D0890-3DA8-4AE4-AB9F-54EA200E747A@apache.org>
Date: Wed, 11 Feb 2009 16:53:39 -0500
Message-ID: <64a10fff0902111353g39026166sc5abcccd6e83e60b@mail.gmail.com>
Subject: Re: [user] Thoughts on document/views...
From: Dean Landolt <dean@deanlandolt.com>
To: user@couchdb.apache.org
Content-Type: multipart/alternative; boundary=000e0cd6ae7af683c80462aba248

--000e0cd6ae7af683c80462aba248
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On Wed, Feb 11, 2009 at 4:45 PM, Damien Katz <damien@apache.org> wrote:

>
> On Feb 11, 2009, at 4:29 PM, Chris Anderson wrote:
>
>  On Wed, Feb 11, 2009 at 10:28 AM, Wout Mertens <wmertens@cisco.com>
>> 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.

--000e0cd6ae7af683c80462aba248--