Azure in a Day Azure Tables Module 1: Azure Tables Overview Module 2: REST API – DEMO: Azure Table...
-
Upload
oswin-richards -
Category
Documents
-
view
225 -
download
0
Transcript of Azure in a Day Azure Tables Module 1: Azure Tables Overview Module 2: REST API – DEMO: Azure Table...
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