Understanding the Azure Storage Blobs Object Model
Azure Blob Storage is a cloud object storage solution for the cloud. It is optimized for storing massive amounts of unstructured data, such as text or binary data. Unstructured data is data that doesn't adhere to a particular data model or definition, such as images, audio, video, or any type of document. You can use Blob Storage to expose data publicly to the world, or to store application data privately.
The object model for Azure Blob Storage is hierarchical and organized to efficiently manage and access large volumes of data. Understanding this model is crucial for effective development and administration.
Key Components
The Azure Blob Storage object model consists of the following key components, ordered from highest to lowest in the hierarchy:
- Storage Account: A unique namespace in Azure that holds your data. All Azure Storage services are accessed through a storage account. It provides a container for your blobs.
- Container: A logical grouping of blobs within a storage account. Think of a container as a folder in a file system. Containers must have names that comply with REST protocol naming conventions.
- Blob: The fundamental unit of storage for unstructured data in Azure Blob Storage. Blobs can be any type of text or binary data. There are three types of blobs:
- Block blobs: Optimized for storing large amounts of unstructured data. They are made up of blocks of data that can be uploaded independently. Block blobs are suitable for storing files, media, backups, and logs.
- Append blobs: Optimized for append operations, such as logging. An append blob is made up of blocks, but blocks can only be appended to the end of the blob.
- Page blobs: Optimized for random read and write operations. Page blobs are used for IaaS virtual machine disks and are composed of 512-byte pages.
Resource Hierarchy and Naming Conventions
The hierarchy of Azure Storage resources is as follows:
https://
Naming Conventions:
- Storage Account Name: Must be 3 to 24 alphanumeric characters, all lowercase.
- Container Name: Must begin with a letter or number, and can only contain letters, numbers, and the hyphen (-) character. Each hyphen must be directly preceded and followed by a letter or number. Container names must be between 3 and 63 characters long.
- Blob Name: Can contain any combination of characters. However, it's recommended to avoid characters that are not valid in a URL. Blob names can be up to 1,024 characters long.
Properties and Metadata
Each resource in the object model can have associated properties and metadata:
- Properties: System-defined metadata that provide information about the resource, such as ETag, Last-Modified, Content-Type, Content-Length, etc.
- Metadata: User-defined key-value pairs that you can associate with a blob or container. Metadata is stored in HTTP headers.
Table of Blob Types
| Blob Type | Description | Use Cases |
|---|---|---|
| Block Blob | Optimized for storing large amounts of unstructured data. Composed of blocks. | Storing files, media, backups, logs, documents. |
| Append Blob | Optimized for append operations. Blocks can only be added to the end. | Logging data, appending to files. |
| Page Blob | Optimized for random read/write operations. Composed of 512-byte pages. | IaaS virtual machine disks. |
Access Tiers
Azure Blob Storage offers different access tiers to optimize costs based on how frequently data is accessed:
- Hot Tier: For frequently accessed data. Higher storage costs, lower access costs.
- Cool Tier: For infrequently accessed data. Lower storage costs, higher access costs.
- Archive Tier: For rarely accessed data that can tolerate several hours of retrieval time. Lowest storage costs, highest access costs and retrieval fees.