Blob：
Binary large objects，可以理解为一堆bytes，可以用来存储影像，视频等等。在使用Blob时，需要先通过storage account创建一个或多个“container”，其中每个container都可以包含一个或者多个blob。
每个blob都有自己的URI，作为唯一确定这个blob的地址，格式如下：
http://<StorageAccount>.blob.core.windows.net/<Container>/<BlobName>
其中container不能嵌套，但blob名字可以包含"/"，意味着可以通过起名字来让blobs看起来有层次的样子。
blob最大可以有50G字节大小，每个blob可以被分成很多个块（Block), 这样，在传输过程中，如果发生传输错误或者中断，可以很方便的从某一块进行续传，而不用整个blob重新传输。
container可以标记为public或者private，private的container中存储的blobs必须通过storage account才可以访问。
Table：
如图，每个Table包含若干个Entities, 每个Entity包含若干属性，每个属性都存储了Name, Type和Value.
但需要注意的是这里的Table与传统意义上关系数据库中的Table不是一种概念，这里的Table里面每个Entity可以有不同的属性，换言之，Windows Azure Table是没有schema的。（Table如此设计的原因是为了满足大容量可扩展性的需要，用户只需要create新的Table存储entities即可，而无需像传统意义的Table那样在大容量数据环境下依赖于机器性能的要求以及数据库的优化工作等等）
Table可以通过ADO.NET Data Services或者LINQ来进行访问，与blob相同，通过http协议，其URI格式如下：
http://<StorageAccount>.table.core.windows.net/<TableName>?$filter=<Query>
Queue：
Queue不同于Table和Blob，Table和Blob主要用于数据的存储访问，而Queue主要用于Windows Azure不同部分的通信，例如Web Role与Worker Role之间的消息传递。
Queue的URI格式如下：
http://<StorageAccount>.queue.core.windows.net/<QueueName>
Web Role 与 Worker Role 之间通过 Queue 传递消息的简单流程如上图所示
Queue 中每条消息长度最大为8KB，当Web Role向Queue中写入一个消息后，Worker Role读取Queue中消息时，Queue中的消息会在一段时间（默认30s）不可见，但并不会被自动删除，用户需要处理完成之后显示的手动删除该消息（基于异常处理的考虑）。
这里的Queue同样与传统意义的先进先出的Queue不同，他对于消息的处理顺序没有规定，并且不强制规定每个消息只能够被处理一次。
