【Azure 架构师学习笔记】-Azure Storage Account（1）-类型简介

本文属于【Azure 架构师学习笔记】系列。
本文属于【Azure Storage Account】系列。

前言

大数据引起了存储革命， 云计算又为大容量高速存储提供了可能的方案，每个商业云供应商都会提供特殊的云存储。而Azure 对应的云存储则称为存储帐户(Storage account) 。

它被广泛使用在各种云系统、服务中，作为数据的临时或者永久存储，现在建立在云上的PaaS类型的系统，几乎无一例外会使用到它，虽然可能需要自建，也可能是服务自带的。

Storage Account（下称SA）具有可扩展性，相对价格低廉，性能稳定的特点， 不过在正式使用时，往往会有一些疑问，SA 到底怎么用？这就要引出SA的四种类型，由于工作需要用到其中一种不常用的类型（常用类型为“容器”/container，也称为blob），所以本文从SA 的类型入手。

类型

SA有4种自带类型：File，Blob， Queue 和Table。对应的名称File Shares， Containers， Queues 和Tables， 如下图：

Blob Storage

blob是“binary large object”的缩写，通常指非结构化如图片，视频，音乐文件，备份文件等。 因为结构化的数据更加适合存储在数据库中，基于大数据时代的大数据包含了很大比重的非结构化数据，所以blob就用来做一个补充数据库在这部分需求上的不足。

Blob 可以拆分到两种访问层，热和冷。 热用于频繁访问，冷则适用于不经常访问。这种冷热之分，还影响可用性，如冷（99%）热（99.9%）。

另外冷热层的主要区别在于费用而不是性能，性能上两者没区别，但是冷层的每次访问费用会比热的高。

Queue Storage

这将是接下来几篇文章的重点。它类似于消息队列服务（MQ）。它可以用来解耦组件，然后进行可靠的异步通信，注意它的强项在于异步而不是实时同步。
它并不适合用来存储用户数据，这是Blob Storage的工作，Queue Storage的数据是Queue和Message，也就是队列和消息。
Queue Storage的结构如下图所示，分为：
Account：你的存储账号
Queue：Message的组合，可以根据不同需求创建Queue，但是名字必须小写。
Message：真正的“数据”，但是每个消息最多64KB.

Table Storage

过去几十年中，数据库主要以关系型数据库为主，随着时代的发展，出现了各种非关系型数据，然后出现了各种非关系型数据库，其中半结构化（semi-structured）的数据存储称为NoSQL Datastore。

Table Storage会以Key-Vaule的格式存储数以PB计的半结构化数据。然后Table Storage通过REST或者其他技术来访问数据。这里的Table和传统的关系型/结构化数据库中的表不同，它是无结构化的，同时表名在你的SA 中必须唯一，不能长于63个字符。实际上它有点把SA当成一个数据库管理系统了。

由于Table Storage不是这次的重点，所以先略过。

File Storage

Blob Storage常用于存文件，这个File Storage又有什么特点呢？它的优点在于“share”， 正如它在Azure Portal上的名字一样。通过SMB 协议，允许应用程序甚至用户同时访问。

小结

在对Storage Account有了大概了解之后，接下来就是对Queue Storage开始较为深入的研究。