Azure in a Day Azure 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

DEMO What we will be building

Agenda I.Overview II.API Overview – REST API III.StorageClient API A.Querying B.Inserting C.Updating D.Deleting IV.Concurrency V.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 Table Entity … Storage Acct Table … Property … EntityProperty Name 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 PKText T1Going to bed T1I’m super smart, really T2Love me, please… T2Playing XBox T2Just ate meatloaf Vomeets Table Node XNode Y PKText T2Love me, please… T2Playing XBox T2Just ate meatloaf Vomeets Table PKText T1Going to bed T1I’m super smart, really PKText Vomitter 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.Overview II.API Overview – REST API III.StorageClient API A.Querying B.Inserting C.Updating D.Deleting IV.Concurrency V.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

DEMO REST API

Agenda I.Overview II.API Overview – REST API III.StorageClient API A.Querying B.Inserting C.Updating D.Deleting IV.Concurrency V.Entity Group Transactions

Common classes you will work with CloudStorageAccount CloudTableClient TableServiceContext : DataServiceContext DataServiceQuery CloudTableQuery

DEMO StorageClient API

Agenda I.Overview II.API Overview – REST API III.StorageClient API A.Querying B.Inserting C.Updating D.Deleting IV.Concurrency V.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

Concurrency Client1Azure Customer PartitionKeyCustomerRegion RowKeyCustomerName Address11 Azure Way …… Timestamp T18:11 : Z Client2 Customer PartitionKeyCustomerRegion RowKeyCustomerName Address11 Azure Way …… Timestamp T18:11 : Z Customer PartitionKeyCustomerRegion RowKeyCustomerName Address11 Azure Way …… Timestamp T18:11 : Z Customer PartitionKeyCustomerRegion RowKeyCustomerName Address11 Azure Way …… Timestamp T18 :13: Z Customer PartitionKeyCustomerRegion RowKeyCustomerName Address11 Azure Way …… Timestamp T18 :13: Z 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

DEMO Concurrency

Entity Group Transactions Batch Insert/Update/Delete – The entire batch is treated as a transaction Call overload of SaveChanges context.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

DEMO Concurrency