Azure Table Storage

Azure Table Storage is a fully managed NoSQL key-value store that stores semi-structured data as entities. Each entity is a set of properties (name-value pairs) and is uniquely identified by a composite primary key consisting of a partition key and a row key. The service is schemaless, meaning entities in the same table can have different sets of properties. Table Storage is designed for storing large amounts of structured data that does not require complex joins, foreign keys, or stored procedures. It is ideal for web application user data, device telemetry, metadata, and other scenarios where low latency and high scalability are required.

Azure Table Storage is built on top of Azure Storage infrastructure. Data is stored in partitions, where each partition is a contiguous range of entities that share the same partition key. The partition key determines the physical location of the data. Within a partition, entities are sorted by row key. The service uses a hash of the partition key to distribute partitions across storage nodes. This means that entities with the same partition key are stored together, enabling efficient point queries and range queries within a partition.

When you insert an entity, the client SDK sends a REST API request to the Azure Storage front-end, which routes the request to the appropriate partition server based on the partition key hash. The server then stores the entity in a B-tree structure indexed by row key. Queries that specify both partition key and row key are the fastest (point queries). Queries that specify only partition key return all entities in that partition sorted by row key. Queries without partition key perform a full table scan across all partitions, which is slow and should be avoided.

To create a table using Azure CLI:

az storage table create --account-name <storage-account-name> --name <table-name> --auth-mode login

To list tables:

az storage table list --account-name <storage-account-name> --auth-mode login

To insert an entity using Azure CLI (requires connection string or SAS):

az storage entity insert --account-name <storage-account-name> --table-name <table-name> --entity PartitionKey=pk RowKey=rk Name=John --connection-string <connection-string>

To query entities:

az storage entity query --account-name <storage-account-name> --table-name <table-name> --filter "PartitionKey eq 'pk'" --connection-string <connection-string>

Using .NET SDK (Azure.Data.Tables package):

var serviceClient = new TableServiceClient(connectionString);
var tableClient = serviceClient.GetTableClient("mytable");
await tableClient.CreateIfNotExistsAsync();

var entity = new TableEntity("pk", "rk")
{
    { "Name", "John" },
    { "Age", 30 }
};
await tableClient.AddEntityAsync(entity);

var result = await tableClient.GetEntityAsync<TableEntity>("pk", "rk");

AZ-204 expects you to know how to choose between Table Storage, Cosmos DB, and SQL Database. Key differentiators: Table Storage is simpler, cheaper, and has lower latency for simple key-value lookups. Cosmos DB offers global distribution, multi-master, and multiple consistency levels. SQL Database is for relational data. Also know the limits: 1 MB entity, 252 properties, 500 TiB per table, 2,000 entities/sec per partition. Be familiar with the SDK operations and batch constraints.

A social media company with 50 million users needs to store user profiles (username, email, display name, avatar URL, preferences). They chose Azure Table Storage because it is cost-effective and can handle the scale. They designed the partition key as a hash of the user ID to distribute load evenly across partitions. The row key is the user ID itself (since it's unique). They use the .NET SDK to read and write profiles on every login. The system handles 10,000 requests per second with average latency under 10 ms. A common misconfiguration is using the user ID directly as partition key without hashing, leading to uneven distribution if user IDs are sequential. They also implemented a secondary index for email lookup by storing a separate table with email as partition key and user ID as row key. When a user changes their email, they update both tables in a batch (though batch only works within same partition, so they must handle consistency manually). Performance issues arise when a single partition becomes hot due to a celebrity user; they mitigated by adding a sub-partition (e.g., appending a random digit to the hash).

A manufacturing company collects telemetry from 100,000 sensors every minute. They store data in Azure Table Storage with partition key as DeviceID and row key as inverted timestamp (DateTime.MaxValue.Ticks - timestamp) to ensure most recent entries appear first in queries. They use batch inserts to reduce costs. The system ingests 1.7 million entities per day. They query by device and time range to generate reports. A common issue is that the partition key is too granular (each device has its own partition), leading to many small partitions and slower cross-device queries. They solved this by using a coarser partition key, such as facility ID, but then faced hot partitions for busy facilities. They eventually moved to Cosmos DB for better global distribution and multi-region writes. For the exam, remember that Table Storage is suitable for IoT telemetry if queries are primarily per device.

A media company stores millions of video files in Azure Blob Storage. They use Table Storage to store metadata (filename, upload date, duration, tags, status). The partition key is the first two characters of the blob name (a simple hash) to distribute load. The row key is the full blob name. They use Azure Functions triggered by blob uploads to insert metadata into the table. This allows fast lookups by blob name and range queries by date. A misconfiguration is not using a partition key that distributes load, causing throttling. They also learned that the 1 MB entity limit is not an issue for metadata, but they had to be careful not to store large tags. They use continuation tokens for pagination when listing all blobs. This pattern is common and often tested on the exam as a valid use case for Table Storage.