"too large for couch attachments": how so?
On 12 January 2012 05:56, Mark Hahn <[email protected]> wrote: > 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 < > [email protected]> 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 <[email protected]> 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. >> > >>
