Windows Azure 平台提供不同的存储服务来存储瞬态和持久态的数据:
无结构二进制和文本数据Unstructured binary and text data
二进制和文本消息Binary and text messages
结构化数据Structured data
为了支持这些类型的数据, Windows Azure 提供三种不同的存储服务: Blobs,Queues,和 Tables。
下表列出了三种存储服务的异同:
存储类型
URL schema
最大大小
推荐 用途
Blob
http://[StorageAccount].blob.core.windows.net/[ContainerName]/[BlobName]
Block Blob:最大200GB
Page Blob:最大1TB
存储大尺寸二进制和文本文件
Queue
http://[StorageAccount].queue.core.windows.net/[QueueName]
8 KB
在本地和云端进行可靠的,持久态的消息通信。小尺寸二进制和文本消息
Table
http://[StorageAccount].table.core.windows.net/[TableName]?$filter=[Query]
数据表可以无限大。实体最大1 MB.
由多个属性组成的可查询的结构化实体
本地和云端各种大型客户端应用都可以通过RESTful 接口无缝的访问存储服务。可以使用微软,第三方或者开发技术来实现使用存储服务的应用:
.NET Framework : 本地或 云端.NET 应用通过Windows Azure SDK 中的Windows Azure Storage Client Library 来访问存储服务。
Java : Windows Azure SDK for Java 使得Java程序也能便捷的访问Windows Azure存储服务。该SDK 包含在Windows Azure Tools for Eclipse 项目中。另外, AppFabric SDK for Java 使得Java项目也能使用Windows Azure AppFabric 中的 service bus 和 access control服务。
PHP : Windows Azure SDK for PHP 使得 PHP 能够访问 Windows Azure 存储服务。
更多存储服务的信息参见如下:
"About the Storage Services API " on MSDN.
"Using the Windows Azure Storage Services " on MSDN.
"Understanding Data Storage Offerings on the Windows Azure Platform " on TechNet.
Blob Service
Blob 服务提供二进制文件和文本文件的存储。通过Blob的 REST API 能够访问2种资源: Containers 和 Blobs 。容器可以看做包含多个文件的文件夹,而blob便是属于某个容器的文件。有如下2种blob:
Block Blobs : 该类型用于流式访问。
Page Blobs: 该类型用于随机读写操作,能够向blob中写入一部分字节。
容器和blob支持用户定义的元数据, 在请求操作的头部填入相应的名值对 。使用 REST API,开发者可以创建和文件系统类似的层次性命名。Blob 名可以加入配置路径分隔符。举例,MyGroup/MyBlob1 和 MyGroup/MyBlob2 意味着一个虚拟的组织层级。 Blob的枚举操作支持虚拟层级的遍历。所以,你可以放回某个组下面的所有blob。例如,您可以返回MyGroup 下的所有blob。
Block Blobs 可以通过2种方法创建。 不超过64MB 的Block blobs 可以通过调用Put Blob 操作进行上传。大于64 MB的 Block blobs 必须分块上传,每块不超过4MB。当所有的分块成功上传之后,通过调用Put Block List 操作进行合并,成为单个连续的blob。Block blob目前最大支持200GB。
Page blobs 可以由调用Put Blob 操作来创建和初始化,支持最大尺寸。通过调用Put Page 操作,向page blob写入内容。Page blob 目前最大支持 1 TB。
Blobs 支持条件更新,更多请参见:
"Understanding Block Blobs and Page Blobs " on MSDN.
"Blob Service Concepts " on MSDN.
"Blob Service API " on MSDN.
"Windows Azure Storage Client Library " on MSDN.
Queue Service
Queue 服务提供本地和云端应用,或同一Windows Azure应用的不同role之间可靠的持久态消息通信。通过REST API 可以访问2种实体: Queues 和 Messages . Queues 支持用户定义的元数据,在请求操作的头部填入相应的名值对。每个存储账户可以拥有无限的消息队列。每个消息队列可以拥有无数的消息。单条消息最大8 KB。当从队列读取消息之后,消耗者应该处理该消息,并随后删除它。消息被读取之后,在特定间隔内,对于其他消耗者是不可见的。当间隔到期,而消息又没有被删除,其他消耗者便能访问该消息。更多请见:
"Queue Service Concepts " on MSDN.
"Queue Service API " on MSDN.
"Windows Azure Storage Client Library " on MSDN.
Table Service
Table 服务提供结构化存储。Table 服务支持与 WCF Data Services REST API 兼容的REST API 。开发者可以使用.NET Client Library for WCF Data Services 来访问 Table 服务。一个存储账号内,开发者可以创建多个表。每个表由唯一的名称和存储账户标示。 Tables 将数据存储为实体。一个实体便是由命名属性和相关的值组成的集合。Tables 被划分在不同存储节点内,以便能够支持负载平衡。每个表的第一个属性: partition key,指明了该实体如何被划分。 第二个属性 : row key,能够确定在某个分区内的实体。Partition key 和row key 结合可以作为实体的主键。任何情况下,都应该把tables当做.NET Dictionary 对象,而不是关系型数据库内的表。实际上,每张table都是相互独立的, Table 服务并不支持多张表的join操作��如果你需要完全的云端关系型数据库,可以试试SQL Azure 。另一不同是,table并不像传统关系型数据库那样必须拥有schema。换言之,同一个table内的实体不必暴露相同的属性。更多请见:
"Table Service Concepts " on MSDN.
"Table Service API " on MSDN.
"Windows Azure Storage Client Library " on MSDN.
"Understanding the Table Service Data Model " on MSDN.
"Querying Tables and Entities " on MSDN.
"Client Applications of ADO.NET Data Services " on MSDN.
Solution
在冗长而又必须的简介之后,我们试着写一些代码。在调研期间,我发现了几个相当不错的工具来管理Windows Azure 存储服务的数据。其中,Neudesic 编写的 Azure Storage Explorer 最为出色。既然要学习某个技术,最好便是能用其解决一些问题。我打算创建一个Windows Forms 应用来处理 to handle Windows Azure Storage Services: Blobs, Queues 和 Tables。下图是应用的架构:
本文来自CSDN博客,转载请标明出处:http://blog.csdn.net/azurechina/archive/2011/02/25/6206932.aspx