CODEWITHSUNDEEP
c#asp.netsql-serverwindows
ps.
ps.

Reputation: 4360

which one is a more scalable solution for managing image files

I need to be able to support user image upload and download/view images.

here are my options.

1) Store images in a sql database.

I have seen this work for a small setup. DB cost would go higher as the size increases. backups would be easier. Can't take advantage of caching or CDN.

2) Store images in a file system. I have seen this option being cumbersome in slightly larger than a small setup. Difficult to manage directories with huge number of files. Will have to come up with some hashing algorithm to make sure there are a few images in a directory and a directory contains only a few directories. Dont know if there is a limit in windows for creating a deep directory structure. Could use caching.

3) Store images in nosql DB. Just throwing this one there. I am not too familiar with NoSql.

4) Windows Azure storage/Amazon storage.

Couple of things. 1) money is an important factor. 2) windows is preferred environment but linux/apache solutions are ok.

And one more thing. What would Facebook do? or does. Thanks again.

Upvotes: 2

Views: 196

Answers (3)

Rinat Galyautdinov
Rinat Galyautdinov

Reputation: 255

If your project is not in Azure, it's better to save your files in a file system. But if your project is already located in Azure, then you should better use blob's containers for storing your files. Comparing where to store the files: in a database or in a file system , the answer is: It's better to use a file system because it would work faster and your database won't grow up because of the tons of the images.

Upvotes: 0

TombMedia
TombMedia

Reputation: 1972

Don't reinvent the wheel.

Image Resizing for .Net has pretty much everything you could think of. Caching, cloud plugins, API and a huge community + associated support.

There are a variety of methods to optimize performance and it's easy to switch from one provider to another say S3 to Azure; take a look at that product (it has a nuget package) if you have a chance.

Upvotes: 0

Simon Whitehead
Simon Whitehead

Reputation: 65077

You should go with a hybrid solution.

Store your actual binary images on the filesystem, but use a database for image metadata. This gives you an easier medium with which to serve the files from - allowing for scalability and potentially speed of serving them, whilst also having the speed of a database for searching, filtering, etc.

I have seen various ways of implementing this.. but generally they are primary keys + mime type + directory tied to a file name / folder. For example, a photo in the /simon-whitehead/albums/stackoverflow/ directory with the filename 1013.jpg would have something like this as it's table in the database:

Id - 1013
Name - example.jpg
AlbumId - (Stackoverflow album id)
UserId - (my user id)
Lat - 37.81
Long - 144.96
Date - 7/10/2013
Mime type - image/jpeg

You may even have a junction table that joins tags to images (for searching). Then, you basically build the response like this:

file = getuser(userId).name / getalbum(albumId).name / getimage(imageid).name

EDIT: I see you've now added Azure. I will say that one company I worked for used Azure and they had fantastic experiences. I however didn't get much chance to have a look.. so I cannot give any advice on that.

Upvotes: 2

Related Questions