I work on UWP app that downloads images from Azure . Although the size of image in < 2 MB , their number is over 500 k. Currently the images are stored in Azure SQL as varbinary .This is consuming 250 GB on the database instance.We need to move it to non relational data storage that has less latency , consumes less space in storage. Which option here (Azure BLOB or Cosmos DB) fits better.? We download the images from REST API connecting to Azure SQL right now using a unique key and want to follow a similar approach with the new data storage too .It will be great to hear from someone who have used these repositories to handle large number of Images?
2 Answers
"Better" is a matter of opinion. But consider that images aren't metadata - they're just binary, which tends to be the domain of Azure Storage (blobs). Both SQL Database and Cosmos DB have specific limits, and you may find yourself going beyond those limits trying to store such quantities of binary data.
Further: Once you store binary data (such as images) in SQL DB or Cosmos DB, you have no choice but to programmatically retrieve said content (and be bound by the performance constraints you've set within the database / collection). In contrast, Azure Storage has its own independent scale targets, and objects may be accessed directly (whether public, or private + SAS), and cached via CDN.
Ultimately this will come down to the storage architecture you choose for your app, but hopefully this info helps.
Another thing to bare in mind in a not so obvious cost in Cosmos DB, there is currently a minimum of 40RU/s per GB of storage in cosmos, hence if you store a large amount of images then you will find the minimum scaling setting may get pretty high which can get expensive quickly.
As David suggested I would store the files in Blob storage and then the file URL alongside the Ids as key value pairs in Cosmos. This should make Cosmos quite small, efficient and cheap but still give you access to indexing.
Related