Обсуждение: yet another image: db or filesystem ? question

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

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?

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" />
>
> 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?

You can map it via a script: <img src="/foo/myimg.php?id=123">
Then have myimg.php read the image data for 123 from the DB and return it.

This is almost certainly much slower than just streaming the image from
the filesystem. However, cacheing effects might mean you don't care.

--
   Richard Huxton
   Archonet Ltd

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

> a) if the images are in the filesystem (and also under the web root), no
> problem.  Just use <img src="filename.jpg" />
>
> b) if the images are in the database...

    You use <img="images/filename.jpg" /> and setup URL rewriting in your
webserver so that a HTTP request on "images/filename.jpg" becomes
"serve_image?fname=filename.jpg" with serve_image being a php, jsp,
whatever script.
    This way when the performance starts to suck too much you can simply
serve images off the filesystem very easily, just remove the URL rewriting.
    Please use your primary key (an integer) as filename, don't let the users
name files on your filesystem !!

    If you are trying to control user access rights to files, it is much
faster to use an authenticator plugin, or lighttpd's mod_sec_download.

    In both cases the web application is only invoked to decide if the user
can access the image or not ; it does not actually handle the (potentially
large) file. It is the webserver that does it, and webservers are
optimized for this purpose.

    If it's for an intranet where you don't expect lots of traffic, though,
the PHP echoing a bytea it got from postgres works well...


> 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?
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
>        choose an index scan if your joining column's datatypes do not
>        match