DP-900: Microsoft Azure Data Fundamentals
Semi Structured Data
Table Storage
Azure Table Storage is Microsoft’s fully managed NoSQL key-value store within Azure Storage accounts. It’s designed for massive scale—supporting up to 25× the capacity of a single Azure SQL Database—while providing a flexible schema: each row has two keys (PartitionKey and RowKey) plus any number of custom properties. Unlike relational tables, rows in Table Storage can have completely different sets of properties.
Relational vs. Semi-Structured Databases
Moving from relational to semi-structured (NoSQL) databases means trading rich relational features for scale and performance.
Feature | Relational Database | Semi-Structured Database |
---|---|---|
Relationships | ✔ | ✖ |
Views & Stored Procs | ✔ | ✖ |
Indexes & Normalization | ✔ | ✖ |
Flexible Schema | ✖ | ✔ |
High Throughput | ✖ | ✔ |
While you lose traditional indexing, Table Storage excels at high-velocity inserts and lookups, handling millions of transactions per day with sub-millisecond reads on keyed queries.
Where to Create Table Storage
You can store table-style NoSQL data in Azure via:
Service | Description | Reference |
---|---|---|
Azure Storage Account | Native Table Storage in a storage account | Storage Account overview |
Azure Cosmos DB (Table API) | Globally distributed, multi-model NoSQL | Cosmos DB service |
In this guide, we focus on Table Storage within an Azure Storage Account.
Note
Azure Cosmos DB’s Table API offers global distribution and automatic indexing, but at a higher cost compared to native Azure Storage Table.
PartitionKey and RowKey
Every row in Table Storage must include these system properties:
Property | Role |
---|---|
PartitionKey | Groups related rows into partitions for load distribution and scaling |
RowKey | Unique identifier within its PartitionKey |
Timestamp | Auto-managed last-modified time, updated on any row change |
The combination of PartitionKey + RowKey is automatically indexed—queries specifying both keys return results in sub-millisecond time.
Choosing a PartitionKey
A well-designed PartitionKey evenly distributes data and request load across partitions. For example, a customer database keyed by country:
- Canada: few customers → light traffic
- USA: many customers → heavier traffic
- India: very large customer base → potential hotspot
Imbalanced partitions can lead to throttling and degraded performance. Aim for partitions of roughly equal size and activity.
Application Scope and Access Patterns
Relational systems let you index many columns; Table Storage limits fast lookups to PartitionKey and RowKey. Design your tables around your application’s primary access patterns.
- Customer Management
PartitionKey = country works if you always filter by country when retrieving data. - New Customer Onboarding
If the country is unknown at insert time, a country-based PartitionKey may not fit this scenario.
Warning
Designing the wrong PartitionKey for your access patterns can lead to inefficient queries or throttling under load.
Timestamp Property
The Timestamp property is updated automatically on any row insert or update. Use it for optimistic concurrency: compare the stored timestamp before writing to ensure no concurrent modification occurred.
Browsing and Managing Table Storage
You can inspect and manage Table Storage with:
Storage Browser
Available in the Azure portal. View and edit tables, rows, and properties directly in your browser without any local installation.Azure Storage Explorer
A standalone desktop app for Windows, macOS, and Linux. Provides rich table-management capabilities, including bulk import/export and advanced filtering.
Download & Documentation
Links and References
Watch Video
Watch video content