Thread: 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