During the BUILD Day two keynote, we announced the release of geo-replication and a new version of the REST API to enable functionality improvements for Windows Azure Blobs, Tables, and Queues. At this time we are now geo-replicating all Windows Azure Blob and Table data between two data centers.
Geo-Replication
Customers have continually emphasized the importance of Disaster Recovery capabilities in Azure as well as other cloud platforms. Wednesday’s announcement on Geo-replication helps in this area and does so without increasing costs to our customers. Geo-replication replicates your Windows Azure Blob and Table data between two locations that are hundreds of miles apart and within the same region (i.e., between North Central and South Central US, between North Europe and Europe West, and between East and South East Asia). We do not replicate data across different regions. Geo-replication is now turned on for all Windows Azure Storage accounts for Blobs and Tables. Note that there is no change in existing performance as updates are asynchronously geo-replicated.
New Blob, Tables and Queue features
For REST API improvements, we have just released the new version (“2011-08-18”), which contains:
- Table Upsert – allows a single request to be sent to Windows Azure Tables to either insert an entity (if it doesn’t exist) or update/replace the entity (if it exists).
- Table Projection (Select) – allows a client to retrieve a subset of an entity’s properties. This improves performance by reducing the serialization/deserialization cost and bandwidth used for retrieving entities.
- Improved Blob HTTP header support – improves experience for streaming applications and browser downloads.
- Queue UpdateMessage – allows clients to have a lease on a message and renew the lease while it processes it, as well as update the contents of the message to track the progress of the processing.
- Queue InsertMessage with visibility timeout – allows a newly inserted message to stay invisible on the queue until the timeout expires
Table Upsert
The Table Upsert allows a client to send a single request to either update or insert an entity; the appropriate action is taken based on if the entity already exists or not. This saves a call in the scenario where an application would want to insert the entity if it doesn’t exist or update it if it does exist. This feature is exposed via the InsertOrReplace Entity and InsertOrMerge Entity APIs.
- InsertOrReplace Entity – inserts the entity if it does not exist or replaces the existing entity if it does exist.
- InsertOrMerge Entity – inserts the entity if it does not exist or merges with the existing one if it does exist.
Table Projection (Select)
Table Projection allows you to retrieve a subset of the properties of one or more entities, and only returns those properties/columns from Azure Tables. Projection improves performance by reducing latency when retrieving data from a Windows Azure Table. It also saves bandwidth by returning only the properties of interest.
Improved Blob Download Experience
We have added additional HTTP header support to Windows Azure Blobs to improve the experience for streaming applications and resuming download. Without this support, some browsers would have to restart reading a blob from the beginning if there was an interruption in the download.
Queue UpdateMessage
With the current Queue API, once a worker retrieves a message from the queue, it has to specify a long enough visibility timeout so that it can finish processing the message before the timeout expires. In many scenarios, the worker may want to extend the visibility timeout if it needs more time to process the message. This new UpdateMessage API enables such scenarios. It allows the worker to use the visibility timeout as a lease on the message, so that it can periodically extend the lease and maintain the ownership of the message until the processing completes.
The UpdateMessage API also supports updating the content of the message. This allows the worker to update the message in the Queue to record progress information. Then if the worker crashes, this allows the next worker to continue processing the message from where the prior worker left off.
This functionality enables worker roles to take on longer running tasks than before. It also allows faster failover time, since the leases can be set at fairly small intervals (e.g. 1 minute) so that if a worker role fails, the message will become visible within a minute for another worker role to pick up.
Queue InsertMessage with Visibility Timeout
We have added support in the InsertMessage API to allow you to specify the initial visibility timeout value for a message. This allows a newly inserted message to stay invisible on the queue until the timeout expires. This allows scheduling of future work by adding messages that become visible at a later time.
For more information see our BUILD talk or one of the following blog posts
- Windows Azure Storage BUILD talk
- Geo-replication
- New Table Features
- New Queue Features
- New Blob Features
To read more about all of the Windows Azure-related announcements made at BUILD, please read the blog post, “JUST ANNOUNCED @ BUILD: New Windows Azure Toolkit for Windows 8, Windows Azure SDK 1.5, Geo-Replication for Windows Azure Storage, and More”. For more information about BUILD or to watch the keynotes, please visit the BUILD Virtual Press Room. And follow @WindowsAzure and @STBNewsBytes for the latest news and real-time talk about BUILD.
Brad Calder is General Manager for Windows Azure Storage.