Storing image files in Mongo database, is it a good idea?

Question

When working with mysql, it is a bad idea to store images as BLOB in the database, as it makes the database quite large which is harmful for normal usage of the database. Then, it is better to save image files on disk and save link to them within the database.

However, I think this is different for MongoDB, as increasing the database file size has a negligible influence on performance (this is the reason that MongoDB can successfully handle billions of records).

Do you think it is better to save image files on MongoDB (as GridFS) to reduce number of files stored on the server; or still it is better to keep the database as small as possible?

Answer 1

The problem isn't so much that the database gets big, databases can handle that (although MongoDB isn't as good as many other in that respect). The problem is that to send the data to the client it first has to be moved into RAM by the database, then copied over to the application's memory, then handed off to the kernel to be sent through the socket. It's wasting lots of RAM and CPU cycles. The reason it's better to have large files in the filesystem is that it's easier to get around copying it, you can ask the kernel to stream the file from disk to the socket directly.

The downside of storing large files in the filesystem is that it's much harder to distribute. Using a database, and something like Mongo's GridFS makes it possible to scale out. You just have to make sure you don't copy the whole file into the application's memory at once, but a chunk at a time. Most web app frameworks have some support for sending chunked HTTP responses nowadays.

Answer 2

The answer is yes. Back in the old cave-man days, servers had mutable file systems you could change. This was great till we tried to scale things.

Cave-people nowadays build apps with immutable deployments. Heroku and Dokku are examples of this. Because the web app server has no state, they can be created, upgraded, scaled, and destroyed easily.

Since we still have files, we need to put them somewhere. There are several solutions: nfs, our database, someone elses database.

• nfs is a 'network file system' which let's you do file i/o on network resources. If you're dealing with the network anyways, IMHO it doesn't add much value unless it's what you know already.

• Our database - For MongoDB there are two options: (file > 16mb) ? GridFS : BinData

• Someone elses database - Some are basic like Amazon S3 and some offer extra services like Cloudinary or Dropbox.

If you're on an big-budget enterprise team and someone spends 40 hrs a week taking care of servers then sure - use the file system. If you're building web apps that scale, putting files in the DB makes sense.

If you're concerned about performance:

1) Using a proxy (e.g. nginx) or a CDN to host your content for clients. Your server should just be serving cache misses.

2) Use streaming IO Nodeschool has a cool tutorial for Node.js.