# .NET and More > Microsoft Azure and Cloud Dev >  [RESOLVED] Azure Storage

## FunkySloth

Hi Guys,

Can anyone give me a simple explanation that I can understand as what is the difference between Azure Blob, File, Queue and Table Storage?. I've read the Microsoft Documentation and somehow got a little grasp about these types of storages, however, it gives me this overwhelming feeling that I didn't get it in the right way. For example, Blob and File storage were kinda the same but differ in accessibility, I guess. Because File storage applies SMB, wherein stored data are accessible for all the computers that are connected in the same network. While Blob Storage is accessible via HTTP/HTTPS. And this Queue Storage makes me confused a little bit more due to I don't know what it is for and specially the last one which is Table storage (NoSql) thing.

Please help me to understand this as a developer cause I want to learn more about Azure and IoT.

Really appreciate the help.

Thanks

----------


## PlausiblyDamp

Blob storage is a reasonably cheap way of storing objects (or files really) - however it doesn't implement any of the things you would expect from a normal file system so there is no standard File IO functionality, no concept of locking a file etc. It pretty much gives you a cheap way of storing files in the cloud than can be accessed over HTTP.

File stores are a typical windows network file share, you can map drives to them (firewall might need to let traffic out) secure them and generally treat them as a typical NTFS volume that has been shared out.

Table Storage is a very simplistic NoSQL store, compared to a typical SQL DB or similar it is a lot cheaper, potentially very fast and can store massive amounts of data but you lose the idea of tables, PK/FK etc. Table store is great for storing data that doesn't have a fixed schema or would work as a flat file structure almost. Performance can be excellent for inserts - in excess of 20,000 inserts a second so if you are dealing with a rapid intake of data they can be an excellent solution for a fraction of the cost a RDBMS would cost.

Queues aren't really a storage mechanism, more of a messaging system - if you have multiple components that need to communicate then queues behave almost like an email system. Things put messages into queues and other things read them out. This can be handy as the rate messages enter a queue can be different to the speed they are processed, it can act as a way to improve front end speed while effectively buffering data to be processed by a back end system.

----------


## FunkySloth

I guess I understand quite now the Blob and File storage. And about Queues is it something like I store a message and tells my application what will do? Sorry if I'm having a hard time about this cause it's my first time in Azure and English is not my native language.

Can you give me a more real-word project that can be use using Queues.

Thanks

----------


## PlausiblyDamp

Sorry for the late reply...

Queues can be used in several different types of application, usually when whatever initiates a process needs to complete quickly but the actual work may take longer to complete.

As an example, imagine an online ordering system. A user accesing the store can happily add things to their basket etc. and eventually will need to go and complete a checkout process. This could be a complex process behind the scenes - not only does the order need to be created and stock allocated (which is what the user sees) but stock needs to be assembled ready for collection, deliveries need to be organised and scheduled, email confirmations and updates need to be sent, possibly new stock needs to be reordered and so on. If all of this was done as part of the user's checkout process it could make the user interaction a very slow process.

Allowing the first bit, order is created and stock allocated, to be part of the actual checkout process will keep things efficient. Dropping one or more messages into a queue (or queues) would then allow the subsequent activities to occur at a slower rate or even at a scheduled rate. This makes the initial checkout faster for the user and allows more flexibility for the backend.

This process might end up as a series of queues, once the initial order is confirmed a message is queued to notify staff to assemble the order, once this is complete another message could trigger an email and initiate the order collection process and so on.

----------

