Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Storing images in NoSQL stores

Tags:

image

nosql

Our application will be serving a large number of small, thumbnail-size images (about 6-12KB in size) through HTTP. I've been asked to investigate whether using a NoSQL data store is a viable solution for data storage. Ideally, we would like our data store to be fault-toerant and distributed.

Is it a good idea to store blobs in NoSQL stores, and which one is good for it? Also, is NoSQL a good solution for our problem, or would we be better served storing the images in the file system and serving them directly from the web server (as an aside, CDN is currently not an option for us)?

like image 543
Wayne See Avatar asked Feb 17 '10 03:02

Wayne See


People also ask

Can I store images in NoSQL?

In under 10 minutes, you will be able to store and access your images (in fact, any arbitrary Python object including webpages) -- in compressed form; NoSQL.

Should you store images in MongoDB?

Storing images is not a good idea in any DB, because: read/write to a DB is always slower than a filesystem. your DB backups grow to be huge and more time consuming. access to the files now requires going through your app and DB layers.

Can you store images in MongoDB?

So for storing an image in MongoDB, we need to create a schema with mongoose. For that create the file `model. js` file and define the schema. The important point here is that our data type for the image is a Buffer which allows us to store our image as data in the form of arrays.

Which database is best for storing images?

The large images should be stored in something like AWS S3, HDFS, a Content Delivery Network (CDN), a web server, file server or whatever else would be great a serving up large static objects, in accordance with your use case and budget.


1 Answers

Whether or not to store images in a DB or the filesystem is sometime one of those "holy war" type of debates; each side feels their way of doing things is the one right way. In general:

To store in the DB:

  • Easier to manage back-up/replicate everything at once in one place.
  • Helps with your data consistency and integrity. You can set the BLOB field to disallow NULLs, but you're not going to be able to prevent an external file from being deleted. (Though this isn't applicable to NoSQL since there aren't the traditional constraints).

To store on the filesystem:

  • A filesystem is designed to serve files. Let it do it's job.
  • The DB is often your bottleneck in an application. Whatever load you can take off it, the better.
  • Easier to serve on a CDN (which you mentioned isn't applicable in your situation).

I tend to come down on the side of the filesystem because it scales much better. But depending on the size of your project, either choice will likely work fine. With NoSQL, the differences are even less apparent.

like image 147
jamieb Avatar answered Oct 20 '22 17:10

jamieb