Blogs  >  Windows Azure Storage at BUILD 2011: Geo-Replication and new Blob, Table and Queue features

Windows Azure Storage at BUILD 2011: Geo-Replication and new Blob, Table and Queue features

Windows Azure Storage at BUILD 2011: Geo-Replication and new Blob, Table and Queue features


We are excited to release 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, at no additional cost, between two data centers for additional data durability in case of a major disaster.

Geo-Replication

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.  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 clients to queue up future work items.  It 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

Brad Calder

Comments (0)