The ability to execute code in Windows Azure Compute is a fundamental part of an Azure platform, but it’s not enough. Applications also need persistent storage. Meeting this need is the goal of the Windows Azure storage service, generally the when we hear the sound “Storage” it is obvious that we are thinking about Relational Data Base, Storage medias but this Windows Azure Storage is not a Relational DB / Storage media. This is different and completely no SQL. Below is the crisp definition for Windows Azure Storage.
Applications work with data in many different ways. Accordingly, the Windows Azure storage service provides several options. Those options were depicted in above picture (Picture 1)
The simplest way to store data in Windows Azure storage is to use blobs. A blob contains binary data, and as Picture 1 suggests, there’s a simple hierarchy: Each container can contain one or more blobs. Blobs can be big—up to a terabyte—and they can also have associated metadata, such as information about where a JPEG photograph was taken or who the singer is for an MP3 file. Blobs also provide the underlying storage for Windows Azure drives, a mechanism that lets a Windows Azure role instance interact with persistent storage as if it were a local NTFS file system.
Blobs are just right for some situations, but they’re too unstructured for others. To let applications work with data in a more fine-grained way, Windows Azure storage provides tables. Don’t be misled by the name: These aren’t relational tables. The data each one holds is actually stored in a group of entities that contain properties. And rather than using SQL, an application can query a table’s data using the conventions defined by OData. This approach allows scale-out storage—scaling by spreading data across many machines—more effectively than would a standard relational database. In fact, a single Windows Azure table can contain billions of entities holding terabytes of data.
Blobs and tables are both focused on storing and accessing data. The third option in Windows Azure storage, queues, has a quite different purpose. A primary function of queues is to provide a way for Web role instances to communicate asynchronously with Worker role instances. For example, a user might submit a request to perform some compute-intensive task via a Web interface implemented by a Windows Azure Web role. The Web role instance that receives this request can write a message into a queue describing the work to be done. A Worker role instance that’s waiting on this queue can then read the message and carry out the task it specifies. Any results can be returned via another queue or handled in some other way.
Regardless of how data is stored—in blobs, tables, or queues—all information held in Windows Azure storage is replicated three times. This replication allows fault tolerance, since losing a copy isn’t fatal. The system provides strong consistency, however, so an application that immediately reads data it has just written is guaranteed to get back what it wrote. Windows Azure also keeps a backup copy of all data in another data center in the same part of the world. If the data center holding the main copy is unavailable or destroyed, this backup remains accessible.
Windows Azure storage can be accessed by a Windows Azure application, by an on-premises application, or by an application running at a hoster or on another cloud platform. In all of these cases, all three Windows Azure storage styles use the conventions of REST to identify and expose data, as Figure 4 suggests. Blobs, tables, and queues are all named using URIs and accessed via standard HTTP operations. A .NET client can use a Windows Azure-provided library to do this, but it’s not required—an application can also make raw HTTP calls.
Creating Windows Azure applications that use blobs, tables, and queues can certainly be useful. Applications that rely on relational storage can instead use SQL Azure, another component of the Windows Azure platform. Applications running on Windows Azure (or in other places) can use this technology to get familiar SQL-based access to relational storage in the cloud.
References
1. MSDN
2. Windows Azure updates April 2011
3. David Chappell’s Azure Platform
No comments:
Post a Comment