Azure Storage Tables Data Model

Azure Table Storage is a NoSQL key-attribute store that accepts authenticated calls using HTTP or HTTPS. It’s a service that stores large amounts of structured, non-relational data. Table storage is efficient and can hold a vast quantity of data. A table in Table Storage is a collection of entities. Each entity is a set of properties, similar to a row in a database.

Key Concepts

Entities

An entity is a record, akin to a row in a relational database. An entity can have any number of properties, up to 1 MB in total for all properties.

Each entity is uniquely identified by two key properties:

• PartitionKey: This property is a string value that groups entities. Entities with the same PartitionKey are co-located on the storage server. This helps optimize queries that target entities within a specific partition.
• RowKey: This property is a string value that uniquely identifies an entity within a partition. Combined with PartitionKey, it forms the entity's unique identifier (PartitionKey + RowKey).

Properties

A property is a name-value pair within an entity. Each property consists of a name (a string) and a value (one of the supported data types).

Property names are strings and are case-insensitive. An entity can have up to 252 properties, excluding the PartitionKey, RowKey, and Timestamp properties.

Supported data types for property values include:

• String
• Int32
• Int64
• Boolean
• DateTime
• Double
• GUID
• Binary (Byte array)
• String (Edm.String)
• Int32 (Edm.Int32)
• Int64 (Edm.Int64)
• Boolean (Edm.Boolean)
• DateTime (Edm.DateTime)
• Double (Edm.Double)
• GUID (Edm.Guid)
• Binary (Edm.Binary)
• Single precision floating point (Edm.Single)
• Decimal (Edm.Decimal)
• DateTimeOffset (Edm.DateTimeOffset)

Table Structure

A table is a collection of entities. All entities within a table must have the same set of properties, but individual properties can be null or empty. Tables do not enforce a fixed schema.

Example Data Model

Consider a table storing product inventory:

In this example:

• PartitionKey could represent broad product categories like "Electronics" or "Apparel".
• RowKey could be a unique product ID like "P001" or "A101".
• Timestamp is managed by Azure Storage.
• Custom properties include ProductName, Category, Quantity, Price, and IsAvailable.

Querying and Performance

The combination of PartitionKey and RowKey is the entity's unique identifier. Queries that specify both the PartitionKey and RowKey (point queries) are the most efficient, retrieving a single entity very quickly.

Queries targeting a single PartitionKey are also highly performant as they only scan entities within that partition. Queries that span multiple partitions or do not specify a PartitionKey (e.g., a table scan) can be less efficient and more costly, especially for large tables.

Data Type Considerations

While Table Storage offers flexibility, using appropriate data types for your properties can impact query performance and storage costs. For example, storing dates as DateTime objects is more efficient for date-based queries than storing them as strings.

When inserting or updating entities, you can specify the OData metadata to indicate the data type of a property if it's not implicitly inferable.

Next Steps

Now that you understand the data model, you can learn how to interact with Azure Table Storage using:

• Azure SDKs
• Azure CLI
• PowerShell