4.1.3.1. Implement Table Storage

First Principle: Implementing Azure Table storage involves defining its structure with PartitionKey and RowKey for optimal query performance and scalability. This enables efficient storage and retrieval of structured, non-relational data for applications.

What It Is: Azure Table storage is a NoSQL service for storing large amounts of structured, non-relational data as entities within tables.

Creating a Table:

• Create a Storage Account in Azure Portal.
• Use Azure CLI to create a table:

  az storage table create --name MyTable --account-name <storage-account>
  

Entity Structure:

• PartitionKey: Groups related entities for efficient queries and scalability. All entities with the same PartitionKey are stored in the same logical partition.
• RowKey: Uniquely identifies an entity within its partition. The combination of PartitionKey and RowKey uniquely identifies each entity.
• Timestamp: Auto-managed by Azure, records last modification time for the entity.
• Custom Properties: User-defined properties (e.g., Name, Email). Each entity can have different custom properties, providing a schema-less design.

Example Entity (JSON):

{
  "PartitionKey": "CustomerA",
  "RowKey": "0001",
  "Timestamp": "2024-06-01T12:00:00Z",
  "Name": "Alice",
  "Email": "alice@example.com",
  "Address": "123 Main St"
}

Inserting an Entity (C# Azure.Data.Tables SDK):

using Azure.Data.Tables;
// ... assume tableClient is initialized
var entity = new TableEntity("CustomerA", "0001")
{
    { "Name", "Alice" },
    { "Email", "alice@example.com" }
};
tableClient.AddEntity(entity);

Querying Entities: (See 4.1.3.2 for more detail)

// By PartitionKey and RowKey (point query)
var entity = tableClient.GetEntity<TableEntity>("CustomerA", "0001");
// By filter (partition scan or table scan)
var results = tableClient.Query<TableEntity>(e => e.PartitionKey == "CustomerA" && e.Email == "alice@example.com");

Deleting an Entity:

tableClient.DeleteEntity("CustomerA", "0001");

Design Tip: Choose PartitionKey and RowKey to optimize for your most common queries and to distribute load evenly across partitions.

Scenario: You need to store real-time sensor data from IoT devices. Each device sends unique data points, and you want to efficiently retrieve all data for a specific device.

Reflection Question: How does defining the PartitionKey (e.g., device ID) and RowKey (e.g., timestamp) when implementing Azure Table storage fundamentally enable efficient storage and retrieval of structured, non-relational data by optimizing for common query patterns and ensuring scalability?