3 ms·

What's an example of an application that is a good fit for MongoDB?

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.
breischl 10y ago
If you have a fairly complex object structure that is logically a single unit, and you only need/want to query on a small number keys. Or anytime you might think "It would be better to just serialize this and shove it into a VARCHAR column." eg, the rate structure for a vacation rental. The fancier ones (not AirBnB) can have lots of different seasons, stay durations, various upcharges/discounts, etc. It's difficult to model in SQL, and even if you could it's not usually useful. Dealing with the entire thing as a single document just makes more sense. Another example: if you need to handle data that your app doesn't really own. eg, you're going to read it, maybe wrap it up with some other data, and pass it on. In that case being able to handle and store that data as a mostly-opaque blob is handy. Of course that's an argument for a document DB in general, not Mongo in particular. Dynamo, Rethink, etc might be better choices.

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.

breischl 10y ago

If you have a fairly complex object structure that is logically a single unit, and you only need/want to query on a small number keys. Or anytime you might think "It would be better to just serialize this and shove it into a VARCHAR column." eg, the rate structure for a vacation rental. The fancier ones (not AirBnB) can have lots of different seasons, stay durations, various upcharges/discounts, etc. It's difficult to model in SQL, and even if you could it's not usually useful. Dealing with the entire thing as a single document just makes more sense. Another example: if you need to handle data that your app doesn't really own. eg, you're going to read it, maybe wrap it up with some other data, and pass it on. In that case being able to handle and store that data as a mostly-opaque blob is handy. Of course that's an argument for a document DB in general, not Mongo in particular. Dynamo, Rethink, etc might be better choices.