Mailing-List: contact couchdb-user-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: couchdb-user@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of anselmo.ars@gmail.com
 designates 64.233.184.232 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version
         :content-type:references;
        b=WPDGuYP6nPWngsjl1ZCxRPLsrfaxKIw4MD8Tf8MyDQhevXXckFhXbZkP49fZsDJBlc
         8RiAhmdkIINeVoTPgfSyUoxXqZWeYFKa7YNpXp5ZoW0WHg9X/8EtjwjDeUUiES4v1fl7
         mXou5cZqwcnhqd58q8NtVnmD89SWSoiqQu+qY=
Message-ID: <460dc5940809090312v708b44ceh4ca238eaf1240c64@mail.gmail.com>
Date: Tue, 9 Sep 2008 11:12:56 +0100
From: "anselmo silva" <anselmo.ars@gmail.com>
To: couchdb-user@incubator.apache.org
Subject: Re: DMS, _attachment or path_field?
In-Reply-To: <1BDAF8CA-0962-4D85-99BB-C255A0FA3EC4@apache.org>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_67831_31367178.1220955176049"
References: <39670022-DC1E-4393-8FEA-7C3908A40E2E@gmail.com>
	 <1BDAF8CA-0962-4D85-99BB-C255A0FA3EC4@apache.org>

------=_Part_67831_31367178.1220955176049
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Extremely explanatory! You left my mouth open....

Cheers...

(still open....)


On Tue, Sep 9, 2008 at 10:47 AM, Jan Lehnardt <jan@apache.org> wrote:

>
> On Sep 9, 2008, at 11:14 , Anselmo Silva wrote:
>
>  When Building a document management system, will you consider the binary
>> _attachment (as couchdb current feature) or a path_field to a
>> server/file_system (protected) enviroment?
>>
>> its an ongoing question about saving binary into a DB ( even with couchDB
>> ). From this we can raise some high-level architecture question:
>>
>> - Will the binary _attachments affect the rebuild index views ( even with
>> append ) ?
>> - How about replication?( I think it would be hard and intense when
>> dealing with higher db size values. )
>>
>
> A couple of notes:
>
> If all your stuff is in the DB, managing said stuff becomes easier.
>
> Not using a database as a blob store is usually recommended because
> data needs to pass the border of user- and kernel-land a few times before
> being sent. The sendfile() syscall helps here, but Erlang developers say
> they don't see a measurable difference. So this looks like a non-issue
> in Erlang-land and hence CouchDB.
>
> If you keep your files external to CouchDB, you need to manage deletes and
> updates and everything.
>
> If you mix in replication, you need to manage replication as well. If that
> is
> easier or harder for you depends on your setup.
>
> Attachments have no impact on view index creation time.
>
> The more data is in a doc, the more resources you need to replicate said
> doc.
> It is also very convenient, see above. Fast, convenient, efficient: pick
> two.
>
> I don't think that is as big of an architectural question as it might
> sound. Start
> by building an app that works. If profiling shows that attachment
> replication is
> your bottleneck, think about solving that in a way that doesn't hurt you.
> If you
> opt for a more complex external solution now, no one can guarantee that
> this
> won't include a bottleneck when it comes to profiling. Ripping out
> attachments
> and do manual handling is not that big a deal (imho), c.f.
> DbUpdateNotifications.
>
> Cheers
> Jan
> --
>
>
>


-- 
Anselmo Silva

------=_Part_67831_31367178.1220955176049--