-1

I have a case in my startup where I need to fetch images in bytes as fast as possible.

At the moment I'm storing the images in Azure Storage then I fetch them on the run and cache them into my database as bytes. On future requests these bytes will be fetched from the database directly. Fetching the bytes from the database is much faster, however, overtime it accumulated and now my database storage is 80% used.

My database is also on Azure and reserving more size will be expensive, so I'm looking into a better cheap way to achieve this.

27
  • 1
    "I need to fetch images in bytes as fast as possible." is essentially incompatible with "I'm looking into a better cheap way to achieve this." Decide whether cheap or fast is more important to you. Aug 19 '21 at 18:50
  • 1
    @PhilipKendall Again, too early for that decision. I understand your point but I haven't finished researching whether there's a way and I'm not in a rush.
    – Faisal
    Aug 19 '21 at 19:05
  • 1
    First off, what kind of DB are we talking about? How are you accessing and retrieving the binary data? How are these images used i.e., are you presenting them to a client or are you processing them internally?
    – JimmyJames
    Aug 19 '21 at 19:15
  • 1
    According to this the premium tier is on SSD and optimized for low-latency. Are you using the premium performance tier? I would be very surprised that a non-relational feature of a relational DB beats a system designed specifically for this purpose. That would seem like a Azure Storage fail. Are you pulling these using async IO? When we talk about speed, there's latency and throughput. What do you mean by 'faster' here exactly?
    – JimmyJames
    Aug 19 '21 at 19:23
  • 1
    Every 30 days sounds like a number plucked out of thin air. Do you have any usage data that would let you predict the impact of adjusting this number? Aug 19 '21 at 19:41
3

There's two issues in your problem statement:

  1. A cache is a subset of the larger data to server files that are accessed more frequently. You have to invalidate low hit rate cache entries or you will consume all your resources.
  2. Azure Blob storage is designed to serve up your blob's bytes over HTTPS with high speed, reliability, and scalability.

By copying your blobs into your database, you are simply duplicating data. I highly doubt serving from the database is faster than having Azure blob storage serve the data for you. While databases can store binary data, that's not really their main use, so it is rarely optimized as storage mediums designed from the ground up for that purpose.

I highly recommend that you examine the ways that you have designed your application to find where it is causing bottlenecks. If you need to have your application as a proxy to the data, make sure of the following:

  • Do not read the whole blob as an array of bytes--it wastes memory and can cause massive garbage collections
  • Make sure you stream the bytes from the blob storage stream to the response stream
  • Design around passing single use URLs (Azure storage can do this), and let the browser pull the data directly
  • Look at the differences in how you are handling binary data in the database to how you are handling it in blob storage. Your algorithm may need to be optimized

In short, make sure you understand what makes Azure storage "slow". If you are testing locally on your machine and your test database is local on your machine, you are artificially penalizing Azure storage.

Granted, I come from an AWS background, and AWS S3 is much faster than serving binaries from an RDS database--particularly at scale. Microsoft is also a smart company, I'm sure the Azure storage is at least close to S3 in performance and scalability.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.