Mailing-List: contact couchdb-user-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: couchdb-user@incubator.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-Id: <1BDAF8CA-0962-4D85-99BB-C255A0FA3EC4@apache.org>
From: Jan Lehnardt <jan@apache.org>
To: couchdb-user@incubator.apache.org
In-Reply-To: <39670022-DC1E-4393-8FEA-7C3908A40E2E@gmail.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v928.1)
Subject: Re: DMS, _attachment or path_field?
Date: Tue, 9 Sep 2008 11:47:02 +0200
References: <39670022-DC1E-4393-8FEA-7C3908A40E2E@gmail.com>


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