Storing Images : DB or File System -

Question

Hi all,

I read some post in this regard but I still don't understand what's the best solution in my case.

I'm start writing a new webApp and the backend is going to provide about 1-10 million images. (average size 200-500kB for a single image)

My site will provide content and images to 100-1000 users at the same time.

I'd like also to keep Provider costs as low as possible (but this is a secondary requirement). I'm thinking that File System space is less expensive if compared to the cost of DB size.

Personally I like the idea of having all my images in the DB but any suggestion will be really appreciated :)

Do you think that in my case the DB approach is the right choice?

Answer 1

Most large sites use the filesystem.

See http://stackoverflow.com/questions/561447/store-pictures-as-files-or-in-the-database-for-a-web-app

Answer 2

Putting all of those images in your database will make it very, very large. This means your DB engine will be busy caching all those images (a task it's not really designed for) when it could be caching hot application data instead.

Leave the file caching up to the OS and/or your reverse proxy - they'll be better at it.

Answer 3

When dealing with binary objects, follow a document centric approach for architecture, and not store documents like pdf's and images in the database, you will eventually have to refactor it out when you start seeing all kinds of performance issues with your database. Just store the file on the file system and have the path inside a table of your databse. There is also a physical limitation on the size of the data type that you will use to serialize and save it in the database. Just store it on the file system and access it.

Answer 4

Your first sentence says that you've read some posts on the subject, so I won't bother putting in links to articles that cover this. In my experience, and based on what you've posted as far as the number of images and sizes of the images, you're going to pay dearly in DB performance if you store them in the DB. I'd store them on the file system.

Answer 5

There's already a similar question here.

Answer 6

We use FileNet, a server optimized for imaging. It's very expensive. A cheaper solution is to use a file server.

Please don't consider storing large files on a database server.

As others have mentioned, store references to the large files in the database.

Answer 7

Some other reasons to store images on the file system:

• Image servers can run even when the database is busy or down.
• File systems are made to store files and are quite efficient at it.
• Dumping data in your database means slower backups and other operations.
• No server-side coded needed to serve up an image, just plain old IIS/Apache.
• You can scale up faster with dirt-cheap web servers, or potentially to a CDN.
• You can perform related work (generating thumbnails, etc.) without involving the database.
• Your database server can keep more of the "real" table data in memory, which is where you get your database speed for queries. If it uses its precious memory to keep image files cached, that doesn't buy you hardly anything speed-wise versus having more of the photo index in memory.

Answer 8

What database are you using? MS SQL Server 2008 provides FILESTREAM storage

allows storage of and efficient access to BLOB data using a combination of SQL Server 2008 and the NTFS file system. It covers choices for BLOB storage, configuring Windows and SQL Server for using FILESTREAM data, considerations for combining FILESTREAM with other features, and implementation details such as partitioning and performance.

details