Storing Images : DB or File System -

Question

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?

Solution 1

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.

Solution 2

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.

Solution 3

Most large sites use the filesystem.

See Store pictures as files or in the database for a web app?

Solution 4

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.

Solution 5

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.

View more solutions

Comments

[andrewWinn]

Duplicate of stackoverflow.com/questions/1212832/…

[mickthompson]

Duplicate? I'm using java, mysql, and image files that are 1/20 - 1/50 of 10MB. My question is not related to a specific technology, but to size/qty of images that need to be stored

[Srikar Doddi]

This question keeps getting asked on a daily basis on SO.

[Edwin Buck]

Edge servers are supposed to do this for you, if you can afford to scale. An edge server would be operating off the HTTP traffic, so it doesn't matter to it where the image came from, except for the initial request, and the subset of requests that occur just "after" the timeout. That in mind, one would best structure their database layer in such a way that it can respond with correct information for HEAD requests without accessing the record that hold the "whole" image. Disks are generally faster, but choosing database doesn't mean you must give up all performance.