VS2010助攻Azure:打造Table Storage库

         Windows Azure 内含有三个基本的服务，分别是 BLOB，Queue 以及 Table 三种，各负有不同的任务，BLOB 是指在云端上储存数据或二进位资料;Queue 是储存需要按顺序排列的数据，并且会有一个程序会依据顺序 (FIFO) 来处理这些数据;而 Table 则是储存数据用，它的作用有点像是关系型数据库，但它只是独立存在的一个个体，无法与其他表格有所关联，若是要实作关系型数据库的应用，那么SQL Azure 会比Table 更好用。

　　那么Table Storage是在做什么的呢?其实你可以将它视为是一个简单的结构化数据储存空间 (structural data storage)，虽然储存它的媒介也是数据库，然而不像关系型数据库那样的严谨，它可以储存一些需要结构化或是有制式结构的零散数据，像是影像档桉的 EXIF 资料，图档的简要说明，或者是主要数据的延伸资料等等，等于是辅助应用程序做描述性数据 (metadata) 或是轻量数据 (lightweight data) 的一个空间，若应用程序没有需要使用到 SQL Azure关系型数据库的数据量以及功能 (例如 FK) 的话，用 Table Storage是绰绰有余的。

　　Table Storage 的数据库组成是由一个TableContainer以及一个TableRow资料表所组成：

　　每一个数据表都是一个Container，注册在TableContainer数据表中，并且使用 AccountName 和 TableName 来识别，这可以让不同的帐户名称可以有相同的数据表名称，且不至于发生冲突。而表中的每一列则包含了更多的键值，除了 AccountName 和 TableName 外，又加入了 PartitionKey 以及 RowKey 两种，其中 PartitionKey 是作为识别在不同的数据表中的同一条数据，或者是作为 Grouping 的数据，例如下列的图示：

　　PartitionKey 可以作为不同但具有相同属性的数据列的识别，以数据库设计来说，就是利用复合主键 (compoud key) 来实作数据群组识别的功能。RowKey 则是专属该列的识别键，实际储存到数据库时，PartitionKey 会和 RowKey 一起作为一个数据列的识别 (identifier)。在 Table Storage 中，数据列被称为 Entity，每个 Entity 都必须有不同的 PartitionKey 以及 RowKey，简单的说，在 Table Storage 的核心中，就已经包含了一个由 ADO.NET Entity Framework 所设计的 Entity Model，这点在开发 Table Storage 的应用程序时会有更深的感触，因为 Table Storage 所开放出来的 REST API，其实就是由 ADO.NET Data Services (以后会更名为 WCF Data Services) 所构成的 API，在 Windows Azure SDK 上所显露的 REST API，基本上就和 ADO.NET Data Services 几乎一模一样。

Table Storage 的数据存储结构，其实与 ASP.NET 的 Profile 行为非常像，资料不是由栏位归档，而是由 XML 做组织。例如下列的代码：

　　实际储存在 Table Storage 中的数据如下图：

　　请注意 Data 栏位，那个栏位就是储存这个 Entity 的所有属性，属性以名称作为标签名称，其实值以标签的 InnerText 所保存，这个技巧被广泛用在很多的系统中，架构上也类似笔者曾发表的 Profile 架构设计。用 XML 来管理半结构化的资料，可以降低设计多个表格的负担，但它的缺点就是会受限数据类型 (因为要储存在 XML)，因此 Table Storage 的 Entity 栏位，只支持下列的数据类型：

　　同时，为了要让 ADO.NET Data Services REST API 可以顺利执行，Table Storage 的 Entity 名称与属性名称有下列的限制：

　　1. 表格名称必须是英文字母，不可以由数字开头，不分大小写，且长度最小 3 个字元，最长 63 个字元。

　　2. 栏位名称必须要让 XML 可以接受，且最长是 255 字元，最好是依据 C# 的识别项规范来命名。

　　而 PartitionKey 以及 RowKey 则有下列的限制：

　　1. 不可以包含 “\”，”/”，”#”，以及 “?” 四种字元。

　　2. 在每一次对 Entity 的新增，修改与删除时，都必须要设定 PartitionKey 以及 RowKey。

　　3. PartitionKey 最长 1KB，RowKey 最长也是 1KB。

　　上面针对 Table Storage 的讨论，其来源都是 SDK 以及在 Development Storage 资料库中所得到的资讯，也许会和正式的 Windows Azure Table Storage 的实体架构有所出入。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/9914407/viewspace-666383/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/9914407/viewspace-666383/