Menu
I am writing a new application at the moment and certain entities in the application have images (just used for display purposes on the website).
I want to host my application on azure later and I am trying to figure out whether it would be better to use Azure Blob storage to store all images or just store them in the DB?
What is better performance wise when loading the images on the website?
Could someone please explain benefits of either solution to me so that I can make up my mind?
510
I currently allow users to either store their FileData(image) in a SQL database File Table or store it locally on their device or a network drive in a folder path and filename. My code will retrieve the image, either stored in the DB or the FilePath and FileName if a checkbox is checked.
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.
Azure Blob Storage is Microsoft's massively scalable object storage solution for the cloud. Blob Storage is designed for storing images and documents, streaming media files, managing backup and archive data, and much more. You can read more about Blob Storage on the overview page.
Generally databases are best for data and the file system is best for files. It depends what you're planning to do with the image though. If you're storing images for a web page then it's best to store them as a file on the server. The web server will very quickly find an image file and send it to a visitor.
How you design your database storage scheme is subjective, but there are objective things to consider in your scenario. I'll address those, and leave the "which should I choose" to you...
Azure Storage blobs are designed for bulk "block" data (such as documents, images, etc). Something like SQL Database is designed for metadata (stuff you search/index/query).
Everything can be done via SQL Database, and you would only need to worry about SQL queries (and it sounds like that's something you're already familiar with). SQL Server (and SQL Database) have always had the ability to store binary content via its BLOB type.
While you can store your images in SQL Database, you will find that your database size increases considerably, vs just storing queryable metadata. And while SQL Database service allows you to scale your storage, you'll find larger scale in blob storage (up to 500TB) at a lower cost than SQL Database service. If you run SQL Server in a VM, then you'll still have storage cost (attached disks) equivalent to blobs, along with VM costs.
Storage blobs, by themselves, don't provide a query language - you will need to know the container and/or blob name. So, for optimum searching, you'll want a queryable database with your metadata (e.g. SQL Database).
If you store your images in blobs, and reference them via URI in your database, you will be able to query against your database, find the image's URI, and then read from blob storage appropriately.
Also note: With blobs, you'll be able to provide direct image URI access to, say, a browser or an app (even if the blob is marked as private), which allows you to then bypass your app tier when delivering binary (image) content to the end-user. Blobs may also be cached in the CDN, which you cannot do with SQL Database.
Which you choose is ultimately up to you; I simply provided the objective reasons to use each.
144
Much cheaper in BLOB.
You are also probably going the get faster transfer as BLOB. Now the initial lookup may be a little faster with SQL but for a large image I think BLOB would win. SQL is just plain not optimized for big stuff and BLOB is.
And you keep SQL free to serve up short stuff.
22
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
