【IT168 技术文档】理论上表存储应该是我们最熟悉的存储方式，它本身也是结构化的存储，类似于我们平时的关系型数据库的存储。不过这里首先要强调的还是编程思想的变化，Windows Azure 平台是云计算的平台，所以从设计开始，它的定位是托管方式的，全开放和分布式的。体现到Azure Service的表存储上也是一样，首先整个的表存储是租户式的设计，说到这里，一定有很多人会想起Saas中的多重租赁（Multi-tenancy）概念，并开始将Azure存储和其联系在一起联想翩翩了。Windows Azure 平台的存储设计是非常精巧的，我们先把焦点转回Azure Service是如何定义和操作表存储的。其中我们需要知道哪些理念。
第一篇：Azure Service探索:存储之本地存储
第二篇：Azure Service探索:存储之队列存储
第三篇：Azure Services探索:存储之Blobs存储
规则1：Azure的表存储也是跟随和隶属于一个帐号的，一个账号下面可以建立多个表存储 ，和队列一样表名跟随在帐号名的范围内，你可以从访问的REST路径看出规律: http://<Account>.table.core.windows.net/<TableName>
规则2：数据是保存在表存储中的，一个表是一个实体的集合，保存了一组实体的信息，每一个实体记录是一个行记录；一个实体是该实体的关键属性和相关的属性的集合，保存了一组实体属性的信息，实体的每一个属性是一个名/值对，对应一列。Entities <->Rows ，Properties<-> Columns .
基本上Azure 表存储的概念如下图：
Pictures source: http://blogs.msdn.com/jnak/archive/2008/10/28/walkthrough-simple-table-storage.aspx
套用上面的规则2，你可以发现一个联系人表是一个联系人实体的集合，保存了一组联系人的信息，每一个联系人记录是一个行记录；一个联系人是该联系人的关键属性和相关的属性的集合，保存了一组联系人属性(Name,Address)的信息，实体的每一个属性是一个名/值对(名字/小王，地址/北京王府井)，对应一列。
规则3：一个实体固定有两个关键属性，这两个关键属性联合唯一标示一个实体。第一个关键属性是：PartitionKey，它是实体在数据库信息中的分区标示/区域关键字，第二个属性是RowKey，它是在某个分区内能够唯一标示该实体的关键字。
下图可以清晰地看到规则3的定义
Pictures source: ES07.pptx of PDC 2008-Windows Azure Tables:Programming Cloud Table Storage
文档(Document)是一个Azure的表存储，保存了一组文档实体。每一个文档对应一行记录，每一个文档包含关键属性(Document,Version) 和一些相关属性 (ChangedOn, Description)；每一个属性是一个名值对，对应到数据库的一列。
根据规则3，PartitionKey其实对文档的一个细分或说颗粒化，用来作为分类/分区的标示，这个文档是FAQ文档还是样板文档，而RowKey属性在一个分类中，可以唯一标示和定位到这个文档。比如v2.0.1加上分类就可以唯一定位到v2.0.1版本的Examples文档。
其实这如何细分来确定这个颗粒度，是由应用来决定的，从上图可以看到，你可以在一个表里定义多个不同的文档分类关键字，也可以将整个表的PartitionKey都定义成一个，一样的关键字，这样分区就扩大到整个一张表，版本号就成为真正的关键字了。从规则3可以看出Azure的表存储的设计原则，一是侧重于直接贴近业务场景和实体对象，第二是要方便查询。
规则4：Azure运行环境会根据PartitionKey来对实体数据进行聚集和索引，PartitionKey是你进行实体查询的首要关键字，相当于你SQL 查询中最主要的Where条件。从伸缩性上来看，Azure运行环境会将不同分区的实体/数据放到不同的存储节点上，它尽力会将一个分区的数据(PartitionKey关键字相同的数据)放在一个存储节点上，而不是多个存储节点上，同时会对这个存储节点优先作分区的负载均衡(Automatically load balance partitions)
Pictures source: ES07.pptx of PDC 2008-Windows Azure Tables:Programming Cloud Table Storage
从上图看，我们根据规则4可以得出下面的结论：因为只要搜索单个分区，所以你查询所有FAQ Doc类的文档速度会很快；同样，如果你查询从截至到2008年5月30日之前所有的FAQ Doc类文档则速度会很慢，因为 这个查询需要检索多个分区，而如果每个分区落在不同的存储节点上，那就需要花费更多的时间。
