Options for high volume site with Spring.

[manifoldronin]

What "price" are you paying over storing them in some other format? Databases are designed to retrieve data quickly and store it efficiently.

Databases are designed to query data quickly. For simple retrievals, they are nowhere near filesystems.

The same can be said of images. For example, say you have a set of images for a patient. These images can be retrieved knowing the patient's ID and other keys that combine to form the unique key required to retrieve an image.

The key difference here is: you can do "select * from patient where name like 'darrin%'", but you can't do "select * from patient where picture like <this binary stream that represents darrin's mug shot>".

Again, the images are the data. They are not just decorative parts of the GUI, but are actually what the user is interested in retrieving for view. If we didn't store the images in a database, then we would have to find some mechanism to replicate the data and index it ourselves...hardly efficient in either design time or processing speed to me, but maybe I am missing something?

As croco brought up, the transactional semantics is a valid point for storing images in the database, but in your case you mentioned image updates mostly happened in a nightly batch job, so transactions are not a major concern. Even if they are, as sethladd and yatesco said, storing just the meta data achieves the same effect without incurring that much of performance penalty.

[darrinps]

Hmmm...beginning to agree with storing the metadata instead of the images themselves in the database...may consider that.

Anyway, the images stored are a set of thumbnils (about 12) and the corresponding larger images. The thumbnails are small say 112x96 (about 2K). The larger versions are scaled so that none are larger than 800x600 (about 50K). The 3D models get compressed to be around 1.5 meg or so.

So for each entity (a patient for example) you will have 24 2D images (12 thumbnails and 12 enlargements) and about about 4.5 meg of 3D data (3 sets at 1.5 meg each).

There are thousands of these entities and it will grow into the 10's of thousands.

Does anyone know of a comparision done that shows how much disk space it takes to house images on a flat file -vs- a database? My instinct is that a flat file may acutally use more space depending on the way the disk is set up. For example, one of those 2D thumbnails I mentioned takes up 4K of disk space on my hard drive even though it is only 1.98K in size!

[gmatthews]

If you do end up storing images in the DB, make sure you consider implementing some logic to return a 304 (SC_NOT_MODIFIED) if the browser already has the image.

We store some images in the DB, and include the image id and the Hibernate version in the image URL so that we can implement browser caching properly.

[redtiger]

I'm not commenting on which method is better, but it is possible to have a high-volume site that stores images in the database. Terraserver stores its images in a database.

1. http://terraserver-usa.com/
2. http://research.microsoft.com/resear...d=MSR-TR-99-29

[Andrew Swan]

Storing the images in the database makes sense because they are part of the application data. This enables updating the application data (the images) in a transactional maner, which you can not do elegantly when part of the data is stored in the file system.

I believe a number of vendors have produced JCA adapters for file systems (or you could write your own!). If you can find one that supports XA (global) transactions, you could access the file system in the same transaction as your database along with any other transactional resources used by your application (JMS queues, etc.). Could I use "transaction" any more times in a sentence?

HTH.

Stop Press: found this article with the source code for such an adapter (no idea if it works though): http://java.sys-con.com/read/37798.htm