Table storage basics in Azure - Commands & Configuration

Introduction

Storing data in tables helps organize information in rows and columns without complex databases. Azure Table Storage lets you save lots of simple data with fast access and low cost.

When you want to save user preferences for a web app without a full database.

When you need to log events or telemetry data quickly and cheaply.

When you want to store product catalog information with flexible schema.

When you want to keep session state data for a web application.

When you need a simple key-value store that scales easily.

Config File - azure_table_storage_policy.json

azure_table_storage_policy.json

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "TableService.QueryEntities",
        "TableService.AddEntity",
        "TableService.UpdateEntity",
        "TableService.DeleteEntity"
      ],
      "Resource": "https://myaccount.table.core.windows.net/mytable"
    }
  ]
}

This JSON file defines permissions for accessing an Azure Table Storage table named mytable in the storage account myaccount. It allows querying, adding, updating, and deleting entities in the table.

Commands

Create a new Azure Storage account named mystorageaccount in the resource group myResourceGroup located in eastus region. This account will hold the table storage.

Terminal

az storage account create --name mystorageaccount --resource-group myResourceGroup --location eastus --sku Standard_LRS

Expected Output

{

  "id": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/myResourceGroup/providers/Microsoft.Storage/storageAccounts/mystorageaccount",

  "location": "eastus",

  "name": "mystorageaccount",

  "resourceGroup": "myResourceGroup",

  "sku": {

    "name": "Standard_LRS"

  },

  "type": "Microsoft.Storage/storageAccounts"

}

→

--sku - Defines the replication and performance tier of the storage account

→

--location - Specifies the Azure region where the account is created

Create a new table named mytable inside the mystorageaccount storage account. Tables organize data in rows and columns.

Terminal

az storage table create --name mytable --account-name mystorageaccount

Expected Output

Created table mytable

→

--name - Specifies the name of the table to create

→

--account-name - Specifies which storage account to use

Insert a new entity (row) into the mytable table with PartitionKey 'users' and RowKey '001'. This entity has properties Name and Age.

Terminal

az storage entity insert --table-name mytable --entity PartitionKey=users RowKey=001 Name=Alice Age=30 --account-name mystorageaccount

Expected Output

No output (command runs silently)

→

--table-name - Specifies the table to insert the entity into

→

--entity - Defines the key-value pairs for the entity's properties

Retrieve and display the entity with PartitionKey 'users' and RowKey '001' from the mytable table.

Terminal

az storage entity show --table-name mytable --partition-key users --row-key 001 --account-name mystorageaccount

Expected Output

{

  "PartitionKey": "users",

  "RowKey": "001",

  "Timestamp": "2024-06-01T12:00:00Z",

  "Name": "Alice",

  "Age": 30

}

→

--partition-key - Specifies the partition key of the entity to retrieve

→

--row-key - Specifies the row key of the entity to retrieve

Key Concept

If you remember nothing else from this pattern, remember: Azure Table Storage stores data as simple rows identified by PartitionKey and RowKey for fast and scalable access.

Common Mistakes

Using the same RowKey within a PartitionKey for multiple entities

RowKey must be unique within a PartitionKey; duplicates cause insert failures or overwrite data.

Ensure each entity has a unique combination of PartitionKey and RowKey.

Not specifying the storage account name in commands

Azure CLI commands need the storage account to know where to apply the operation; missing it causes errors.

Always include --account-name with the correct storage account in your commands.

Trying to create a table with invalid characters or names

Table names must follow Azure naming rules; invalid names cause creation to fail.

Use only letters, numbers, and no special characters in table names.

Summary

Create an Azure Storage account to hold your tables.

Create a table inside the storage account to organize your data.

Insert entities with unique PartitionKey and RowKey to store rows.

Retrieve entities by specifying their PartitionKey and RowKey.

Practice

1. What two keys uniquely identify a record in Azure Table Storage?

easy

A. StorageKey and DataKey

B. PrimaryKey and SecondaryKey

C. PartitionKey and RowKey

D. TableKey and RecordKey

Solution

1. Step 1: Understand Azure Table Storage keys

   Azure Table Storage uses two keys to uniquely identify each record: PartitionKey and RowKey.

2. Step 2: Confirm uniqueness of keys

   PartitionKey groups records, and RowKey uniquely identifies a record within that partition.

3. Final Answer:

   PartitionKey and RowKey -> Option C

4. Quick Check:

   Unique record ID = PartitionKey + RowKey [OK]

Hint: Remember: PartitionKey groups, RowKey identifies [OK]

Common Mistakes:

• Confusing PartitionKey with PrimaryKey
• Thinking TableKey is a valid key
• Assuming only one key is needed

2. Which of the following is the correct way to create a table client in Azure SDK for Table Storage?

easy

A. TableClient = new TableServiceClient(tableName).GetTableClient(connectionString);

B. TableClient = new TableClient(tableName, connectionString);

C. TableClient = new TableServiceClient(tableName).GetClient(connectionString);

D. TableClient = new TableClient(connectionString, tableName);

Solution

1. Step 1: Review Azure Table Storage SDK syntax

   The correct constructor for TableClient requires connection string first, then table name.

2. Step 2: Match syntax to options

   TableClient = new TableClient(connectionString, tableName); matches the correct syntax: new TableClient(connectionString, tableName); others mix order or use wrong classes.

3. Final Answer:

   TableClient = new TableClient(connectionString, tableName); -> Option D

4. Quick Check:

   Constructor order: connectionString, tableName [OK]

Hint: Connection string always comes before table name [OK]

Common Mistakes:

• Swapping connection string and table name order
• Using TableServiceClient instead of TableClient
• Calling non-existent methods like GetClient

3. Given this code snippet, what will be the output?

var entity = new TableEntity("users", "user1") { { "Name", "Alice" }, { "Age", 30 } };
Console.WriteLine(entity.PartitionKey + ", " + entity.RowKey + ", " + entity["Name"]);

medium

A. user1, users, Alice

B. users, user1, Alice

C. users, user1, 30

D. user1, users, 30

Solution

1. Step 1: Identify PartitionKey and RowKey values

   PartitionKey is "users" and RowKey is "user1" as set in the constructor.

2. Step 2: Access the "Name" property value

   The "Name" property is set to "Alice", so entity["Name"] returns "Alice".

3. Final Answer:

   users, user1, Alice -> Option B

4. Quick Check:

   PartitionKey, RowKey, Name = users, user1, Alice [OK]

Hint: PartitionKey first, RowKey second, then properties [OK]

Common Mistakes:

• Mixing PartitionKey and RowKey order
• Printing Age instead of Name
• Confusing property access syntax

4. You try to insert an entity with the same PartitionKey and RowKey twice. What will happen?

medium

A. An error occurs because keys must be unique.

B. The table creates a duplicate record with a new key.

C. The second insert overwrites the first entity silently.

D. The insert is ignored without error.

Solution

1. Step 1: Understand uniqueness constraint in Table Storage

   PartitionKey and RowKey together uniquely identify an entity; duplicates are not allowed.

2. Step 2: Behavior on duplicate insert

   Trying to insert an entity with existing keys causes an error, preventing duplicates.

3. Final Answer:

   An error occurs because keys must be unique. -> Option A

4. Quick Check:

   Duplicate keys cause error, no silent overwrite [OK]

Hint: Duplicate keys cause error, not overwrite [OK]

Common Mistakes:

• Assuming silent overwrite happens
• Thinking duplicates are allowed
• Believing insert is ignored silently

5. You want to design a scalable Azure Table Storage schema for a large user database. Which approach best supports fast lookups and scalability?

hard

A. Use PartitionKey as user country and RowKey as user ID

B. Use PartitionKey as user ID and RowKey as timestamp

C. Use a single PartitionKey for all users and RowKey as user ID

D. Use random GUIDs for both PartitionKey and RowKey

Solution

1. Step 1: Understand partitioning for scalability

   PartitionKey groups data to distribute load; grouping by country balances partitions.

2. Step 2: Use RowKey for unique identification

   RowKey as user ID uniquely identifies users within each country partition.

3. Step 3: Evaluate other options

   Single partition causes bottleneck; random GUIDs reduce query efficiency; user ID as PartitionKey fragments data poorly.

4. Final Answer:

   Use PartitionKey as user country and RowKey as user ID -> Option A

5. Quick Check:

   Partition by country, RowKey unique ID = scalable [OK]

Hint: PartitionKey groups data logically for scalability [OK]

Common Mistakes:

• Using single partition for all data
• Random keys hurting query performance
• Misusing RowKey as partitioning key