Storing images in MongoDB - is it worth it?

Question

MongoDB

Good afternoon.
We need an authoritative opinion on this issue. There was a task to deal with GridFS, write and read files from there. Everything worked out, but the question arose: is there any point in storing, for example, images (photos) there? Is this solution more productive (or vice versa)? If so, what is the (logical) best way to implement this?
How it's happening now:

A GET request /specialists/:login/photos/:photo(where :login is the specialist's login, :photo is the unique identifier of the photo) is sent to GridFS, from where the specialist's photo is retrieved by ID and given to the browser.
Accordingly, the photo is written on the page as

<img src="/specialists/:login/photos/:photo" alt="" />

, and there may be 20 of them, which will mean 20 queries to the database.

Answer 1

Absolutely not worth it. What for to you in general superfluous requests to basis? Especially such bulky ones? People, on the contrary, cache everything and put it on the screw, so that access is faster, but on the contrary, you think how to remove the cache (images) from under your hands and shove it into the database.

Answer 2

It will not be productive if there is no large cluster that compensates for the reduced access speed due to parallelization. I prefer to store pictures on a separate server, and links to them in the database. Here is a small study of this issue, though two years ago: www.coffeepowered.net/2010/02/17/serving-files-out-of-gridfs/

Answer 3

Look towards gridFS (part of mongo) and the nginx module ( github.com/mdirolf/nginx-gridfs ) if the memory does not change, then you lose 50% in performance, but you get all the benefits of cloud file storage.

Answer 4

If there is a question of storing files in GridFS, then there is a need for cloud storage and timely modification of the file / files in the cloud, as well as controlled file storage (for example, keeping a file usage counter in the document itself in gridfs and deleting it when it is reset). Only in this case it makes sense to think about gridfs. Of course, if you use GridFS directly, then there will be performance losses, and the more requests and more files, the greater the performance drawdown. There are several options for more or less productive solutions, but their whole essence comes down to: GridFS - (gridfs-fuse) --> disk0 - (rsync) --> disk1 - (rsync) --> disk2 - ... (parallel rsync is possible) or GridFS - (gridfs-fuse) --> disk0 - (drbd) --> disk1, disk2,… or combinations thereof.