Re: images in database...
Re: images in database...
- Subject: Re: images in database...
- From: John Lennard <email@hidden>
- Date: Tue, 13 Dec 2005 10:59:04 +1300
We have tried several approaches for storing images in our applications.
Our main application, Virtual Curator (http://
www.virtualcurator.com) , stores images as flat files in a pool of
directories on the file system. This pool of directories was to
overcome file system limits on directories as currently the system is
storing some 70000 images of various sizes and scales, in total about
5Gb of images. We are using a simple hashing algorithm that seems to
quite nicely distribute the images evenly throughout the pool of
directories.
The various sites that then use these images just reference the
images via http. This approach meant that if the load on the site got
too high we could just move the images to their own server and dish
them out that way.
This approach seems to required a little more fluffing about (if you
consider threads, media trackers and pipes fluffing) when storing and
performing operations on images such as resizing and saving, but does
work well.
The other two approaches we have used is to a) store the whole image
in a blob and b) use Andrew Lindesay's LEWOStuff.Framework to sore
the binary data in lots of little blobs.
I have decided in most cases that there is less development required
to store image/binary data in the db than saving things out to the
file system. Whilst its easy to get stuff off of a http server,
getting things to the server and managing them seems to be a little
less complicated.
I have now also started to build up a whole pile of tools which can
read eo's on the command line and perform manipulation of this data
if things need to be re-scaled or new image sizes added, so the fact
that i cant write a shell script to resize images on a file system is
a non-issue.
The LEWOStuff seems to work quite well, in that by using little
chunks instead of one big one, we dont need load the whole image into
memory to stream out, just bits at a time, which makes the memory
requirements alot less that faulting the whole image to memory and
then streaming it out. We just attach a stream from the LEWOStuff to
the append to response and all of the image data is magically sucked
out and fed to the client.
At this point, none of our sites using binary data in the db have
been particularly flogged, but my thought is that if things get dire,
i will place a proxy box of some description in front of application
to perform caching. Whist this means that change management is a
little trickier if images change, i dont have to implement a whole
caching infrastructure. And given the nature of most of our web-
sites the binary data tends to not change once it is loaded, so
waiting for something to fall out of a cache is not a biggie.
Just my NZD 0.05 ( no 2 cent pieces )
John.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden