Azure Blob storage is a service for storing large amounts of unstructured data, such as text or binary data, that can be accessed from anywhere in the world via HTTP or HTTPS. You can use Blob storage to expose data publicly to the world, or to store application data privately.
Common uses of Blob storage include:
The Blob service contains the following components:
FIGURE 1: Storage Account | All access to Azure Storage is done through a storage account.
Container | A container provides a grouping of a set of blobs. All blobs must be in a container. An account can contain an unlimited number of containers and a container can store an unlimited number of blobs.
Blob | A file of any type and size. There are two types of blobs that can be stored in Azure Storage: block and page blobs. Most files are block blobs. A single block blob can be up to 200 GB in size. This tutorial uses block blobs. Page blobs, another blob type, can be up to 1 TB in size, and are more efficient when ranges of bytes in a file are modified frequently.
URL format | Blobs are addressable using the following URL format: http://<storage account>.blob.core.windows.net/<container>/<blob>
The following example URL could be used to address one of the blobs in the diagram above: http://sally.blob.core.windows.net/movies/MOV1.AVI
All access to Microsoft Azure Blob is done through a standard HTTP REST PUT/GET/DELETE interface.
The HTTP/REST commands supported to implement the blob operations include:
Committed Block List | This is the list of blocks that have been successfully committed as part of a PutBlockList for a given blob Uncommitted Block List | This is the list of blocks that have been uploaded for a blob since the last PutBlockList for the blob. These blocks represent the temporary/uncommitted blocks that have not yet been committed
All of these operations can be done on a blob with the following URL: http://<account>.blob.core.windows.net/<container>/<blobname>
You can upload a blob up to 64MB in size using a single PUT blob request up into the cloud. To go up to the 50GB blob size limit, one must use the block interface.
One of the target scenarios for Microsoft Azure Blob is to enable efficient upload of blobs that are many GBs in size. This is provided by Microsoft Azure Blob through the following steps:
Storage, then we commit the list of uncommitted blocks uploaded to represent the blob name they were associated with. This is done with a PUT specifying the URL above with the query specifying that this is a blocklist command. Then the HTTP header contains the list of blocks to be committed for this blob. When this operation succeeds, the list of blocks, in the order in which they were listed, now represents the readable version of the blob. The blob can then be read using the GET blob commands described above
The following figure incorporates blocks into the Microsoft Azure Blob data concepts.
As described earlier, blobs can be accessed via PUT and GET by using the following URL: http://<account>.blob.core.windows.net/<container>/<blobname>
In the examples shown in Figure 2, a single PUT can be used to put the images with the following URLs: http://sally.blob.core.windows.net/pictures/IMG001.JPG
The same URLs can be used to get the blobs. In using a single PUT, blobs up to 64MB can be stored. To store blobs larger than 64MB and up to 50GB, one needs to first PUT all of the blocks, and then PUT the block list to comprise the readable version of the blob. In Figure 2 above, only after the blocks have been PUT and committed as part of the block list can the blob be read using the following URL: http://sally.blob.core.windows.net/pictures/MOV1.AVI
GET operations always operate on the blob level, and do not involve specifying blocks.
The Azure Table storage service stores large amounts of structured data. The service is a NoSQL data store which accepts authenticated calls from inside and outside the Azure cloud. Azure tables are ideal for storing structured, non-relational data. Common uses of the Table service include:
You can use the Table service to store and query huge sets of structured, non-relational data, and your tables will scale as demand increases.
The Table service contains the following components:
A RowKey in Table Storage is a very simple thing: it's your 'primary key' within a partition. PartitionKey + RowKey form the composite unique identifier for an entity. Within one PartitionKey, you can only have unique RowKey. If you use multiple partitions, the same RowKey can be reused in every partition. Therefore, a RowKey is just the identifier of an entity within a partition.
One of the most common questions that come up when talking about Table Storage is regarding whether transactions are supported. Table storage does support batch transactions against data within the same table and the same partition.
There are several rules about the transactions though: all of the entities must exist within the same partition of the table, the number of entities in the transaction can't exceed 100 and the entire batch being sent to the server cannot exceed 4 MB in size.
As you can see, there are limitations to the level of transaction support you get which revolves around the partition. This is another good reason why choosing your partition key scheme is very important.
Similar to Azure SQL Database, Azure Table Storage stores structured data, with the main difference being that Azure SQL Database is a relational database management system based on the SQL Server engine and built on standard relational principles and practices. As such, it provides relational data management capabilities through TransactSQL queries, ACID transactions and stored procedures that are executed on the server side.
Azure Table Storage is a flexible key/value store that enables you to build cloud applications easily, without having to lock down the application data model to a particular set of schemas. It is not a relational data store and does not provide the same relational data management functions as Azure SQL Database (such as joins and stored procedures).
CAMPARISON CRITERIA | AZURE TABLE STORAGE | AZURE SQL DATABASE |
Data Relationships | No | Yes |
Server-side Processing | No | Yes |
Transaction Support | Limited | Yes |
Geo-replication | Yes | No |
Table Schema | Relaxed | Managed |
Similarity [to existing data stores used on-premises] | No | Yes |
Scale-out | Automatic | Manual |
Data Types | Simple | Simple, Complex and User Defined |
Azure Table Storage provides limited support for serverside queries, but does offer transaction capabilities. Additionally, different rows within the same table can have different structures in Azure Table Storage. This schemaless property of Azure Tables also enables you to store and retrieve simple relational data efficiently.
If your application stores and retrieves large data sets that do not require rich relational capabilities, Azure Table Storage might be a better choice. If your application requires data processing over schematised data sets and is relational in nature, Azure SQL Database might better suit your needs. There are several other factors you should consider before deciding between Azure SQL Database and Azure Table Storage. Some of these considerations are listed in the Table 1 on page 12.
Azure Queue storage is a service for storing large numbers of messages that can be accessed from anywhere in the world via authenticated calls using HTTP or HTTPS. A single queue message can be up to 64 KB in size and a queue can contain millions of messages, up to the total capacity limit of a storage account. A storage account can contain up to 500 TB of blob, queue and table data.
See Azure Storage Scalability and Performance Targets for details about storage account capacity. Common uses of queue storage include:
The Queue service contains the following components:
Provide reliable storage and delivery of messages for an application.