Re: What DB to use for lots of IMAGE files?

Mirwais Qader wrote:
>
> I am in the process of evaluating how to set up a database of about
> 1,000,000 (million) images of products, medical files etc... The

We currently have a document imaging database partially in production. The final production environment will have more than 15 servers. The smallest one has 18 GB. Some have 30GB, some have 60GB, and others have 120GB. The largest server has one terabyte. Yet our latest estimate indicated our disk is still too small. We also have three HSM systems to perform backup on optical and tape jukeboxes.

> database would consist of the following attributes:
> Search_KeyWord1, Search_KeyWord2, Search_KeyWord3,
> Description (text 100 chars), FileName, FileExtension, PathOfFile,
> ImageData (Raw 100K to .5 MB).
>

You must have estimated images size with a specific image format. Which format is your estimate based upon? Are you using color images? Are you planning to use BLOB? We are using Informix on SPARCs and all images are stored as BLOBs.

> This could be stored in 1 table, but I would probably split
> the non-image attributes from the image attributes since not all
> users would want to view the image data.

We split the image table into three tables based upon database normalization, although we could store all images in a single table without violating database normalization. There are several reasons that we split the table into three. The primary reason is to avoid single point of failure. If a single table is used and the table is corrupted somewhere, it is possible that the whole system will not be accessible. These added a significant coding effort to the development, but we are willing to pay the price.

>
> The criteria is FAST ACCESS to the data, and fast loading of the
> image if the user wants to see it. Some users may want to go
> through a list of 10-100 images before finding the one they want.
>

So far we are pleased with the performance of image retrieval. The retrieval is slow only if images are not on magnetic disk and must be loaded from optical platters. It seems to us the slowest part is not the client workstations and is not from network. The performance of the server seems to dominate the performance of the system. In other words, you may want to consider to buy a high performance server instead of powerful client workstations.

> How can I set this DB up? What DBMS would be good for this?
>

I may be wrong, but when it comes to images I will use either Sybase or Informix, not Oracle. I personally do not have experience with Oracle BLOB, but I was told by many Oracle experts not to use Oracle BLOB. This is before Oracle 7.3 was out. But check the market. There are many imaging products that are using database BLOBs. But I do not know a product that is using Oracle BLOB. I am not claiming I know all the document imaging products, but I have been in the imaging business for several years and know a lot of imaging products.

We chose Informix over Sybase for several reasons. The two main reasons are (1) Sybase (and SQL server) does not have row lock and (2) it is not easy to code two-phase commit in Sybase. Sorry, I really don't want to start another battle on which database is better.

>
> What format should the image data be stored in (.jpg, .gif, .tif,
> ....)?
>

You can decide that based upon user requirements. If you want to handle black/white images (most of us do) you do want to use tiff instead of jpg and gif. If you want to store multiple images in the same image file (or blob), again you should use tiff. tiff is the only format we use to handle b/w, grayscale, and color images.

Chao Received on Mon May 05 1997 - 00:00:00 CDT