Azure Table StorageAzure Table Storage Overview

Azure in a DayAzure Tables

• Module 1: Azure Tables Overview• Module 2: REST API

– DEMO: Azure Table REST API• Module 3: Querying Azure Tables

– DEMO: Querying Azure Tables– DEMO: Paging with Azure Tables

• Module 4: Insert, Updating, Deleting– DEMO: Inserting– DEMO: Updating– DEMO: Deleting

• Module 5: Concurrency and Entity Group Transactions– DEMO: Concurrency– DEMO: Entity Group Transactions

DEMOWhat we will be building

Agenda

I. OverviewII. API Overview – REST APIIII. StorageClient API

A. Querying B. InsertingC. UpdatingD. Deleting

IV. ConcurrencyV. Entity Group Transactions

Azure Table Storage

“I don’t think that means what you think it means”- Fezzik – The Princess Bride

What Azure Tables Are Not

• Relational– No concept of Foreign Keys– Able to join to other tables

• Protected by a schema• Database tables– No ORDER BY– No GROUP BY

• Related in any way to SQL Server

What Azure Tables Are

• Schemaless• Entity Bags– Name-value pairs

• Massively scalable• Highly available• Durable• Cloud Service

Table Storage Structure

TableEntity

Entity

Entity…

Storage AcctTable

Table

Table…

Property

Property

Property…

Entity PropertyName

Type

Value

TimeStamp

RowKey

PartitionKey

Required Properties

• PartitionKey– Enables scalability– Defines the unit of partition

• RowKey – Unique identifier by partition– With PartitionKey, forms the composite key

• Timestamp (server managed) – for concurrency

Illustrating Partitions

PK Text

T1 Going to bed

T1 I’m super smart, really

T2 Love me, please…

T2 Playing XBox

T2 Just ate meatloaf

Vomeets Table

Node X Node Y

PK Text

T2 Love me, please…

T2 Playing XBox

T2 Just ate meatloaf

Vomeets TablePK Text

T1 Going to bed

T1 I’m super smart, really

PK TextVomitter

Vomeets

Partitioning Considerations

• PartitionKey should be in “WHERE clause”– If it is not, reconsider your architecture– Otherwise scan every partition on n nodes

• Tradeoff between Entity locality and scalability– Partitions need to be small enough to allow for

• Scalability• Availability

– Partitions need to be large enough to allow for• Common queries• Entity Group Transactions

RowKey Considerations

• RowKey is unique – by partition• Together with the PartitionKey, forms the

composite key• RowKey defines the sort order

Agenda

I. OverviewII. API Overview – REST APIIII. StorageClient API

A. Querying B. InsertingC. UpdatingD. Deleting

IV. ConcurrencyV. Entity Group Transactions

Azure Table Storage APIs

• REST– Standards– Interoperable - anyone who has HTTP Stack

• Familiar and easy-to-use API– oData– WCF Data Services– .NET classes and LINQ– Other wrappers – Java, PHP, etc.

oData

• Web Standards compliant protocol• Protocol enables querying and updating data• Based on• ATOM Publishing Protocol• HTTP• JSON• URI

WCF Data Services

• Provides oData clients• Enables rapid development of oData services• StorageClient API wraps WCF Data Services

clients

Why wrap REST API

• Hide complexity of Shared Key Signatures• Hide – Creating HTTP Request– Adding appropriate HTTP Headers– Calculating URI– Serializing Request Body– Deserializing Response Body

Why use REST API

• On a platform without a wrapper• Unimplemented feature in wrapper

DEMOREST API

Agenda

I. OverviewII. API Overview – REST APIIII. StorageClient API

A. Querying B. InsertingC. UpdatingD. Deleting

IV. ConcurrencyV. Entity Group Transactions

Common classes you will work with

• CloudStorageAccount• CloudTableClient• TableServiceContext : DataServiceContext• DataServiceQuery<T>• CloudTableQuery<T>

DEMOStorageClient API

Agenda

I. OverviewII. API Overview – REST APIIII. StorageClient API

A. Querying B. InsertingC. UpdatingD. Deleting

IV. ConcurrencyV. Entity Group Transactions

Concurrency

When multiple users access data at the same time (concurrently), data integrity can be violated.

Optimistic Concurrency Control

• Assume low contention• No locks are taken when data is read• No persistent connection required• Highly scalable• During update:– Check to see if data has changed since read– If yes, rollback– If no, commit

ConcurrencyClient1 Azure

CustomerPartitionKey CustomerRegion

RowKey CustomerName

Address1 1 Azure Way

… …

Timestamp 2011-03-21T18:11:18.1733124Z

Client2CustomerPartitionKey CustomerRegion

RowKey CustomerName

Address1 1 Azure Way

… …

Timestamp 2011-03-21T18:11:18.1733124Z

CustomerPartitionKey CustomerRegion

RowKey CustomerName

Address1 1 Azure Way

… …

Timestamp 2011-03-21T18:11:18.1733124Z

CustomerPartitionKey CustomerRegion

RowKey CustomerName

Address1 1 Azure Way

… …

Timestamp 2011-03-21T18:13:14.1238356Z

CustomerPartitionKey CustomerRegion

RowKey CustomerName

Address1 1 Azure Way

… …

Timestamp 2011-03-21T18:13:14.1238356Z

1. Client1 Issues GET

HTTP GET

2. Azure returns the requested entity with a timestamp. (required property for all entities)

HTTP Response

HTTP GET

HTTP Response

3. Client2 requests the same entity

HTTP MERGE

4. Client1 issues an HTTP MERGE (PUT/DELETE), passing the timestamp as an HTTP Header

5. Azure checks to see if the passed Timestamp matches the server. If does, so Azure returns 204. Response includes new Timestamp

HTTP MERGE

6. Client2 now issues an HTTP MERGE, passing the original Timestamp.7. Azure checks to see if the Timestamp matches the server. It doesn’t, so server returns 412.

Concurrency Process

• On INSERT / UPDATE, the server maintains a Timestamp• When you fetch an entity, the timestamp is returned with

the entity• When you perform an operation, you send the timestamp

as an if-match header (or in the message body in an Entity Group Transaction)

• If the sent Timestamp != server Timestamp– HTTP Error: 412 – Precondition Failed

• Sent Timestamp == server Timestamp– Operation succeeds– New Timestamp is returned

DEMOConcurrency

Entity Group Transactions

• Batch Insert/Update/Delete – The entire batch is treated as a transaction

• Call overload of SaveChangescontext.SaveChanges(SaveChangesOptions.Batch);

• SaveChangeOptions– None– ContinueOnError– Batch– ReplaceOnUpdate

Entity Group Transactions

• Constraints – Maximum 100 operations– Maximum payload size: 4 MB– All entities have to have the same partition key– Can perform only 1 operation per entity

• Snapshot Isolation– No locking required– Snapshot taken at beginning of transaction– Commits only if no concurrency violations

• Can use context.RetryPolicy

DEMOConcurrency