5 ms·
I actually don't have any experience, but I heard this from wise people: If you have a file store service, where you're storing relatively big files (big image
by kolme 10y ago
I actually don't have any experience, but I heard this from wise people:
If you have a file store service, where you're storing relatively big files (big images, videos, etc) and some metadata associated to them which need to be queried.
It's easier to implement than "traditional" solutions (metadata goes in a RDBMS and actual files go to some directory, NAS, or whatever).
Also, apart from being a nicer solution from a programmer's perspective, you'll be able to easily scale horizontally because it supports sharding.
Like I said, I didn't tried this myself so take it with a grain of salt. Also, I don't know how that compares to storing blobs in a RDBMS.
- KMag 10y ago> Also, apart from being a nicer solution from a programmer's perspective, you'll be able to easily scale horizontally because it supports sharding. Sharding file storage is pretty easy. On the other hand, I'm not familiar with the MongoDB APIs, but I assume it doesn't support handing a socket file descriptor from the webserver over to MongoDB so Mongo can sendfile(2) the data directly from the kernel's page cache to the TCP socket for locally resident data. With the files stored directly on disk and metadata in an RDBMS, your webserver can sendfile(2) those files that are permanently stored locally or cached to local disk, and act as a proxy for other shards. Extra context switches and coping your data one or two times more than necessary can add up quickly.