本文属于【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开始较为深入的研究。