couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Hahn <m...@hahnca.com>
Subject Re: couch attachments versus amazon S3
Date Thu, 12 Jan 2012 05:56:00 GMT
I just happened to run into documentation on an S3 feature that might
address your concern ...

"To host a static website on S3, It is possible to define a Amazon S3
bucket as a *Website Endpoint*."

http://trac.cyberduck.ch/wiki/help/en/howto/s3

On Wed, Jan 11, 2012 at 9:10 PM, Gabriel de Oliveira Barbosa <
manobi.oliveira@gmail.com> wrote:

> I'm on same dilema, but one point that make diferences to me is couchdb
> vhosts and rewrites, it can be very helpfull when you have complex routes
> for your static files.
>
> S3 don't suport url wildcards also, but I read in some place that couchdb
> can do this.
>
> On Thursday, January 12, 2012, Mark Hahn <mark@hahnca.com> wrote:
> > I've been storing a lot of images as couch attachments.  I now have to
> > support videos that are too large for couch attachments.  So I pretty
> much
> > have to consider using S3 since I'm on AWS anyway and S3 scales
> > automatically compared to my OS file system.
> >
> > Since I have to use S3 for videos, why not use it for images?  Has anyone
> > else compared these alternatives?
> >
> > These are the consequences to switching to S3 that I can think of ...
> >
> > 1) Smaller load on couchdb for replicating, compaction, disk usage etc
> >
> > 2) S3 would give less load on cpu and nginx for serving files to client
> >
> > 3) Performance for file access?  Would S3 be slower?
> >
> > 4) Option to use CDN in the future?
> >
> > 5) S3 has finer-grained access control than attachments.  I can't let the
> > client directly access couch on my server because couch has no
> read-access
> > controls.
> >
> > 6) Do small files have a disadvantage in S3?  I see they charge for IO
> > transfers, whatever that means.
> >
> > After typing this in I'm starting to think that if a file is needed
> across
> > servers, no matter how small, it should be in S3 instead of an
> attachment.
> >
>

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