From: | Vick Khera <vivek(at)khera(dot)org> |
---|---|
To: | PGSQL Mailing List <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Storing images in database for web applications |
Date: | 2009-12-01 20:37:18 |
Message-ID: | 2968dfd60912011237w24bba595p73fb7202ab761273@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Fri, Nov 27, 2009 at 6:04 AM, Thom Brown <thombrown(at)gmail(dot)com> wrote:
> I'm wondering if anyone has experience of storing and getting images to and
> from a database? We currently have the problem of images being uploaded to
> a single gateway used by many companies, most of which run several
> websites. As it stands, once they upload the image, it then has to be
> fsync'd to the appropriate servers (3-way in some cases) or accessed through
> our image proxy.
For our customer image hosting service, we store the master copy of
everything in the database, and have an external process that pushes
the (scaled) images to the front-end delivery service. Currently this
is amazon's cloudfront service. The URLs that our customers can
use/give out are all pointing to the cloudfront, which is wicked fast
and scalable.
We do not directly serve the images from the DB. That would just not scale.
What I'd do is put a shim layer in front of the http service that
gives out the image and looks for it in a cache. If not found,
fetches it from the DB then every subsequent request gets it from the
local cache on the http server. You could probably implement this
shim as a 'file not found' error handler in apache, so there would be
no overhead on a cache hit.
From | Date | Subject | |
---|---|---|---|
Next Message | Edgardo Portal | 2009-12-01 20:40:36 | Re: optimizing advice |
Previous Message | Steve Atkins | 2009-12-01 19:58:00 | Re: optimizing advice |