From: | Steve Atkins <steve(at)blighty(dot)com> |
---|---|
To: | pgsql-general General <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: yet another image: db or filesystem ? question |
Date: | 2007-07-17 15:39:50 |
Message-ID: | 3607D287-F586-407A-ADF9-9FD8FB513F97@blighty.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Jul 17, 2007, at 8:09 AM, Rick Schumeyer wrote:
> I've read the earlier threads on whether to store images in the
> database or filesystem. I think I understand the pros and cons of
> each method, but I have a question on a specific use case.
>
> Let's say I have a web app, and I want to display the images in a
> web page.
>
> a) if the images are in the filesystem (and also under the web
> root), no problem. Just use <img src="filename.jpg" />
That's likely to be by far the lowest system overhead way of doing
things, and unless you have a really good reason not to do it this
way, do it this way. (There are really good reasons not to, in some
cases.)
> b) if the images are in the database...do I need to create a
> temporary file first in order to use the <img> tag? Or is there
> some other HTML way of doing this?
Not HTML, no. You have your webapp read the file into memory and send
it directly to the client. The HTML is likely to look identical, but
rather than the webserver receiving the request for "/foo/
filename.jpg" and reading it from disk it'll pass the request to the
webapp to handle. Unless the webapp is much, much better written than
most of them are then you'll be tying up an entire fat apache
instance and an entire webapp instance to feed the image to the client.
If you use a large object to store it, you can stream it from the
database through the webapp to the client.
If you use bytea you'll need to read the entire thing off disk into
postgresqls memory, decompress it, copy it into your webapps memory,
then trickle it out to the client - which might be fine for 100x100
user icons, but which will start getting very memory hungry when you
have 2 or 3 copies of every multi-megabyte image currently being
viewed on a photo site.
There are various options in between too. One approach is to receive
the request for the image in the webapp, get the metadata from the
database, copy the image to an on-disk cache from the database if it
has changed or is not in the cache already, then tell the webserver
to return that file directly from the cache.
Cheers,
Steve
From | Date | Subject | |
---|---|---|---|
Next Message | mljv | 2007-07-17 15:41:02 | int8 vs int4 |
Previous Message | mljv | 2007-07-17 15:33:29 | Re: createing indexes on large tables and int8 |