阿里云-表格存储服务开发者手册-D

1、表格存储开发者手册表格存储/开发者手册表格存储/开发者手册 PAGE 28 PAGE 28开发者手册访问控制Table Store通过AccessKey和实例（Instance）来保证Table Store的访问安全性。实例的访问对Table Store表数据的访问，首先需要确定该表所在的实例。实例是阿里云用户开通Table Store服务后，管理资源的逻辑容器。用户可以通过阿里云官网控制台，对Table Store实例进行创建、管理及删除等操作。成功创建实例后，在实例中管理Table Store的表。其中实例名称名称（Instance Name）在阿里云节点 HYPERLINK http:/

2、instanceN/ 公网访问地址：http:/instanceN HYPERLINK http:/instanceN/ 公网访问地址：http:/instanceN HYPERLINK http:/instanceN/ 阿里云私网地址：http:/instanceN示例（华东1(杭州)节点，实例名称为myInstance的访问域名）: HYPERLINK http:/myI/ HYPERLINK http:/myI/ 公网：http:/myI HYPERLINK http:/myI/ 私网：http:/myIAccessKeyTable Store根据AccessKey对请求进行身份认证和鉴

3、权，每个合法的Table Store请求都必须携带正确的AccessKey信息。每个阿里云账户可以创建至多5个AccessKey，用户可以在阿里云用户中心中管理自己的AccessKey。AccessKey由AccessKeyID和AccessKeySecret组成。AccessKeyID用于标识AccessKey，AccessKeySecret用于加密Table Store请求。AccessKeySecret是认证请求身份的重要凭证，因此需要保证AccessKeySecret的保密和安全。阿里云账户下的AccessKey可以被用于访问该阿里云账户中的所 有实例。AccessKey有启用和禁用两

4、种状态。只有处于启用状态的AccessKey可以被用来访问Table Store。在阿里云用户中心可以切换AccessKey的启用/禁用状态。AccessKey切换状态后等待1分钟生效。Table Store表创建Table Store表时，需要指定表名、主键和预留读写吞吐量。在传统数据库中，表具有预定义的结构信息，比如表的名称、主键、列名和类型，表中的所有行都具有相同的列集合。Table Store是NoSQL数据库:除了主键需要格式外，没有其他的格式信息。本章将介绍表的概念和使用。表名Table Store表的名称必须符合以下约束:由英文字符(a-z)(A-Z)，数字(0-9)，下划线(_

5、)组成首字母必须为英文字母(a-z)(A-Z)或下划线(_)大小写敏感长度在1255字符之间同一个实例下不能有同名的表，但不同实例内的表名字可以相同主键创建Table Store表时必须指定表的主键。主键包含14个主键列。每一个主键列都有名字和类型。Table Store对主键列的名字和类型都有限制，详细信息可以参考Table Store数据模型的主键一节Table Store根据表的主键索引数据，表中的行按照它们的主键进行升序排序。配置预留读写吞吐量为了确保应用获得稳定、低延时的服务，应用可以在在创建表的时候指定预留读写吞吐量。如果预留读写吞吐 量不为0，Table Store根据预留读写吞

6、吐量来为表分配相应的资源，满足应用的预留吞吐量需求，同时根据配置的预留读写吞吐量收取相应的费用。应用可以根据自身的业务需求动态上调和下调表的预留读写吞吐量。预 留读写吞吐量通过读服务能力单元和写服务能力单元这两个数值来设置。通过UpdateTable操作可以更新表的预留读写吞吐量。预留读写吞吐量的更新有如下规则:一张表上的两次更新的间隔必须大于2分钟，例如12:43 AM更新了某个表的预留读写吞吐量，那么只有在12:45 AM之后才能再次更新该表的预留读写吞吐量。更新间隔必须大于2分钟的限制是针对表的，12:43 AM 12:45 AM之间用户还能更新其他表的预留读写吞吐量每个自然日内(UTC

7、时间00:00:00到第二天的00:00:00，北京时间早上8点到第二天早上8点)，上调或 者下调预留读写吞吐量的总次数不做限制，但是两次调整之间的时间间隔仍然需要大于2分钟。调整 预留读写吞吐量的定义是，只要读服务能力单元或写服务能力单元配置其中一项进行了更新，则此次 操作被视为对表进行了更新。预留读写吞吐量调整完毕后1分钟内生效对于访问消耗的读写吞吐量中超出预留读写吞吐量的部分会计入按量读写吞吐量，并根据按量读写吞吐量单价 进行计费。由于预留读写吞吐量在单价上低于按量读写吞吐量，配置合适的预留读写吞吐量可以进一步降低成本。例如在 用户刚建表之后如果需要导入大量数据，可以设置较大的预留写吞吐

8、量，能够以较低的写成本将数据导入进来，当数据导入完毕后，再将预留读写吞吐量下调。分片键下的数据量限制Table Store按照分片键的范围对表的数据进行分区，拥有相同分片键的行会被划分到同一个分片。为了防止分片过大无法切分，单个分片键下的所有行数据大小之和建议不要超过1GB。建表后加载时间Table Store表在被创建之后需要1分钟进行加载，在此期间对该表的读写数据操作均会失败。应用程序应该等待表加载完毕后再进行数据操作。最佳实践Table Store表的最佳实践使用Table Store SDK 进行表操作使用TableStore Java SDK 进行表操作使用TableStore Py

9、thon SDK 进行表操作Table Store数据操作Table Store的表由行组成。每一行包含主键和属性。这一章将介绍操作Table Store数据的方法。Table Store行简介组成Table Store表的基本单位是行，行由主键和属性组成，其中主键是必须的，且每一行的主键列的名称和类型相同，属性不是必须的，并且每一行的属性可以不同。更多信息请参考Table Store数据模型。Table Store数据操作有以下三种类型: 单行操作GetRow - 读取单行数据PutRow - 新插入一行。如果该行内容已经存在，先删除旧行，再写入新行UpdateRow - 更新一行。应用可以

10、增加、删除一行中的属性列，或者更新已经存在的属性列的值。如果该行不存在，那么新增一行DeleteRow - 删除一行批量操作BatchGetRow - 批量读取多行数据BatchWriteRow - 批量插入、更新、删除多行数据范围读取GetRange - 读取表中一个范围内的数据本章将介绍以上几种操作。Table Store单行操作单行写入操作Table Store的单行写操作有三种:PutRow，UpdateRow和DeleteRow。下面分别讲述每一种操作的行为语义和注意事项:PutRow新写入一行。如果这一行已经存在，则这一行旧的数据会先被删除，再新写入一行。UpdateRow更新一行

11、的数据。Table Store会根据请求的内容在这一行中新增列，修改或者删除指定列的值。如果这一行不存在，则会插入新的一行。但是有一种特殊的场景，UpdateRow请求只包含删除指定的列，且该行不存在，该请求不会插入新行。DeleteRow删除一行。如果删除的行不存在，则不会发生任何变化。应用程序通过设置请求中的condition字段来指定写入操作执行时是否要对行的存在性进行检查。condition有 三种类型:IGNOREEXPECT_EXISTEXPECT_NOT_EXIST的DeleteRow、UpdateRow操作是没有意义的，删除一个不存在的行是无意 义的，如果需要更新不存在的行可以

12、使用PutRow操作。如果操作发生错误，如参数检查失败，单行数据量过多，行存在性检查失败等等，会返回错误码给应用程序。 如果操作成功，TableStore会将操作消耗的服务能力单元返回给应用程序。各操作消耗的写服务能力单元的计算规则:PutRow - 本次消耗的写CU为修改的行主键数据大小与属性列数据大小之和除以4KB向上取整，若指定条件检查不为IGNORE，还需消耗该行主键数据大小除以4KB向上取整的读CU。如果操作不满足应 用指定的行存在性检查条件，则操作失败并消耗1单位写服务能力单元和1单位读服务能力单元PutRow详解UpdateRow - 本次消耗的写CU为修改的行主键数据大小与属性

13、列数据大小之和除以4KB向上取整，UpdateRow中包含的需要删除的属性列，只有其列名计入该属性列数据大小，若指定条件检查不 为IGNORE，还需消耗该行主键数据大小除以4KB向上取整的读CU。如果操作不满足应用指定的行存 在性检查条件，则操作失败并消耗1单位写服务能力单元和1单位读服务能力单元 UpdateRow详解DeleteRow - 被删除的行主键数据大小除以4KB向上取整。若指定条件检查不为IGNORE，还需消耗该行主键数据大小除以4KB向上取整的读CU。如果操作不满足应用程序指定的行存在性检查条件，则 操作失败并消耗1DeleteRow详解写操作会根据指定的condition情况

14、消耗一定的读服务能力单元。/PutRow操作/row_size=len(pk)+len(value1)+len(value2)+8Byte+1300Byte+3000Byte=4322Byte/PutRow操作/row_size=len(pk)+len(value1)+len(value2)+8Byte+1300Byte+3000Byte=4322Byteprimary_keys:pk:1,attributes:value1:String(1300Byte), value2:String(3000Byte)/原来的行/row_size=len(pk)+len(value2)+8Byte+900

15、Byte=916Byte/row_primarykey_size=len(pk)+8Byte=10Byteprimary_keys:pk:1, attributes:value2:String(900Byte)读写服务能力单元的消耗情况如下：设置condition设置为EXPECT_EXIST时：消耗的写服务能力单元为4322Byte除以4KB向上取整，消耗 的读服务能力单元为该行主键数据大小10Byte除以4KB向上取整，该PutRow操作消耗2个单位的写服 务能力单元和1个单位的读服务能力单元。设置condition设置为IGNORE时：消耗的写服务能力单元为4322Byte除以4KB向上

16、取整，消耗0个读 服务能力单元，该PutRow操作消耗2个单位的写服务能力单元和0个单位的读服务能力单元。设置condition设置为EXPECT_NOT_EXIST时：指定的行存在性检查条件检查失败，该PutRow操作消 耗1个单位的写服务能力单元和1个单位的读服务能力单元。/UpdateRow操作/删除的属性列列名长度计入row_size/UpdateRow操作/删除的属性列列名长度计入row_size/row_size=len(pk)+len(value1)+len(value2)+8Byte+900Byte=922Byteprimary_keys:pk:1, attributes:va

17、lue1:String(900Byte), value2:Delete/原来的行不存在/row_size=0读写服务能力单元的消耗情况如下：设置condition设置为IGNORE时，消耗的写服务能力单元为922Byte除以4KB向上取整，该UpdateRow操作消耗1个单位的写服务能力单元和0个读服务能力单元。设置condition设置为EXPECT_EXIST时：指定的行存在性检查条件检查失败，该PutRow操作消耗1个 单位的写服务能力单元和1个单位的读服务能力单元。/UpdateRow操作/row_size=len(pk)+len(value1)+len(value2)+8Byte+1

18、300Byte+3000Byte=4322Byte/UpdateRow操作/row_size=len(pk)+len(value1)+len(value2)+8Byte+1300Byte+3000Byte=4322Byteprimary_keys:pk:1,attributes:value1:String(1300Byte), value2:String(3000Byte)/原来的行/row_size=len(pk)+len(value1)+8Byte+900Byte=916Byte/row_primarykey_size=len(pk)+8Byte=10Byte/row_primarykey

19、_size=len(pk)+8Byte=10Byteprimary_keys:pk:1, attributes:value1:String(900Byte)读写服务能力单元的消耗情况如下：设置condition设置为EXPECT_EXIST时：消耗的写服务能力单元为4322Byte除以4KB向上取整，消耗 的读服务能力单元为该行主键数据大小10Byte除以4KB向上取整，该UpdateRow操作消耗2个单位的 写服务能力单元和1个单位的读服务能力单元。设置condition设置为IGNORE时：消耗的写服务能力单元为4322Byte除以4KB向上取整，消耗0个读 服务能力单元，该UpdateR

20、ow操作消耗2个单位的写服务能力单元和0个单位的读服务能力单元。/原来的行不存在/row_size=0/原来的行不存在/row_size=0/DeleteRow操作/row_size=0/row_primarykey_size=len(pk)+8Byte=10Byteprimary_keys:pk:1,修改前和后修改后的数据大小均为0，无论读写操作成功还是失败至少消耗一个单位服务能力单元，因此该DeleteRow操作消耗1个单位的写服务能力单元。 读写服务能力单元的消耗情况如下：设置condition设置为EXPECT_EXIST时：消耗的写服务能力单元为该行主键数据大小10Byte除以4KB

21、向上取整，消耗的读服务能力单元为改该主键数据大小10Byte除以4KB向上取整，该DeleteRow操作消耗1个单位的写服务能力单元和1个单位的读服务能力单元。设置condition设置为IGNORE时：消耗的写服务能力单元为该行主键数据大小10Byte除以4KB向上取 整，消耗0个读服务能力单元，该DeleteRow操作消耗1个单位的写服务能力单元和0个单位的读服务 能力单元。更多的信息可以参看API Reference中的PutRow,UpdateRow,DeleteRow章节。单行读取操作Table Store的单行读操作只有一种:GetRow应用程序提供完整的主键和需要返回的列名。列名

22、可以是主键列或属性列。也可以不指定要返回的列名，此时请求返回整行数据。Table Store根据被读取的行的主键的数据大小与实际读取的属性列数据大小之和计算读服务能力单元。将行数据大小除以4KB向上取整作为本次读取操作消耗的读服务能力单元。如果操作指定的行不存在，则消耗1单位读 服务能力单元。单行读取操作不会消耗写服务能力单元。/被读取的行/row_size=len(pk)+len(value1)+len(value2)+8Byte+1200Byte+3100Byte=4322Byte/被读取的行/row_size=len(pk)+len(value1)+len(value2)+8Byte+1

23、200Byte+3100Byte=4322Byteprimary_keys:pk:1,attributes:value1:String(1200Byte), value2:String(3100Byte)/GetRow操作/获取的数据size=len(pk)+len(value1)+8Byte+1200Byte=1218Byteprimary_keys:pk:1, columns_to_get:value1消耗的读服务能力单元为1218Byte除以4KB向上取整，该GetRow操作消耗1个单位的读服务能力单元。 更多信息可以参看APIReference的GetRow多行操作Table Stor

24、e提供了BatchWriteRow和BatchGetRow两种多行操作。BatchWriteRow用于插入、修改、删除一个表或者多个表中的多行记录。BatchWriteRow操作由多个PutRow、UpdateRow、DeleteRow子操作组成。BatchWriteRow的各个子操作独立执行，Table Store会将各个子操作的执行结果分别返回给应用程序，可能存在部分请求成功、部分请求失败的现象。即使整个请求没 有返回错误，应用程序也必须要检查每个子操作返回的结果，从而拿到正确的状态。BatchWriteRow的各个子 操作单独计算写服务能力单元。BatchGetRow用于读取一个表或者多

25、个表中的多行记录。BatchGetRow各个子操作独立执行，Table Store会将各个子操作的执行结果分别返回给应用程序，可能存在部分请求成功、部分请求失败的现象。即使整个请求 没有返回错误，应用程序也必须要检查每个子操作返回的结果，从而拿到正确的状态。BatchGetRow的各个子 操作单独计算读服务能力单元。更多信息可以参看API Reference中的BatchWriteRow与BatchGetRow章节。范围读取操作Table Store提供了范围读取操作GetRange。该操作将指定主键范围内的数据返回给应用程序。Table Store表中的行按主键进行从小到大排序，GetRan

26、ge的读取范围是一个左闭右开的区间。操作会返回主键属于该区间的行数据，区间的起始点是有效的主键或者是由INF_MIN和INF_MAX类型组成的虚拟点，虚拟点 的列数必须与主键相同。其中，INF_MIN表示无限小，任何类型的值都比它大，INF_MAX表示无限大，任何类 型的值都比它小。A和B，AB。如正 序读取A, B)，则按从A至B的顺序返回主键大于等于A，小于B的行。逆序读取B,A)，则按从B至A的顺序返回大于A，小于等于B的数据。GetRange操作可以指定最大返回行数，Table Store按照正序或者逆序最多返回指定的行数之后即结束该操作的执行，即使该区间内仍有未返回的数据。GetRa

27、nge操作可能在以下几种情况下停止执行并返回数据给应用程序：1）返回的行数据大小之和达到1MB；2）返回的行数等于5000；3）返回的行数等于最大返回行数；4）当前剩余的预留读吞吐量已被全部使 用，余量不足以读取下一条数据。同时GetRange请求的返回结果中还包含下一条未读数据的主键，应用程序可 以使用该返回值作为下一次GetRange操作的起始点继续读取。如果下一条未读数据的主键为空，表示读取区间 内的数据全部返回。Table Store计算读取区间起始点到下一条未读数据的起始点的所有行主键数据大小与实际读取的属性列数据大小之和。将数据大小之和除以4KB向上取整计算消耗的读服务能力单元。如

28、读取范围中包含10行，每行主键数 据大小与实际读取到的属性列数据之和占用数据大小为330Byte。则消耗的读服务能力单元为1(数据总和3.3KB，除以4KB向上取整为1)。下面举例说明GetRange操作的行为。假设表的内容如下，PK1，PK2是表的主键列，类型分别为String和Integer。A，B是表的属性列。PK1PK2Attr1Attr2A2HellBellA5Hello不存在A6不存在BloodB10Apple不存在C1不存在不存在C9Alpha不存在/请求table_name: table_name /请求table_name: table_name direction: FOR

29、WARDinclusive_start_primary_key:(PK1,STRING,A),(PK2,INTEGER,2) exclusive_end_primary_key:(PK1,STRING,C),(PK2,INTEGER,1)/响应cosumed_read_capacity_unit: 1rows: rows: primary_key_columns:(PK1, STRING, A), (PK2, INTEGER, 2) attribute_columns:(Attr1,STRING,Hell),(Attr2,STRING,Bell),primary_key_columns:(PK

30、1, STRING, A), (PK2, INTEGER, 5) attribute_columns:(Attr1, STRING, Hello),primary_key_columns:(PK1, STRING, A), (PK2, INTEGER, 6) attribute_columns:(Attr2, STRING, Blood)，primary_key_columns:(PK1, STRING, B), (PK2, INTEGER, 10) attribute_columns:(Attr1, STRING, Apple)/请求table_name: table_name /请求tab

31、le_name: table_name direction: FORWARDinclusive_start_primary_key: (PK1, INF_MIN) exclusive_end_primary_key: (PK1, INF_MAX)/响应cosumed_read_capacity_unit: 1 rows: primary_key_columns:(PK1, STRING, A), (PK2, INTEGER, 2) attribute_columns:(Attr1,STRING,Hell),(Attr2,STRING,Bell),primary_key_columns:(PK1

32、, STRING, A), (PK2, INTEGER, 5) attribute_columns:(Attr1, STRING, Hello),primary_key_columns:(PK1, STRING, A), (PK2, INTEGER, 6) attribute_columns:(Attr2, STRING, Blood)，primary_key_columns:(PK1, STRING, B), (PK2, INTEGER, 10) attribute_columns:(Attr1, STRING, Apple)primary_key_columns:(PK1, STRING,

33、 C), (PK2, INTEGER, 1)primary_key_columns:(PK1, STRING, C), (PK2, INTEGER, 9) attribute_columns:(Attr1, STRING, Alpha)/请求table_name: table_name /请求table_name: table_name direction: FORWARDinclusive_start_primary_key: (PK1, STRING, A), (PK2, INF_MIN) exclusive_end_primary_key: (PK1, STRING, A), (PK2,

34、 INF_MAX)/响应cosumed_read_capacity_unit: 1 rows: primary_key_columns:(PK1, STRING, A), (PK2, INTEGER, 2) attribute_columns:(Attr1,STRING,Hell),(Attr2,STRING,Bell),primary_key_columns:(PK1, STRING, A), (PK2, INTEGER, 5) attribute_columns:(Attr1, STRING, Hello),primary_key_columns:(PK1, STRING, A), (PK

35、2, INTEGER, 6) attribute_columns:(Attr2, STRING, Blood)例子4，逆序读取/请求/请求table_name: table_name direction: BACKWARDinclusive_start_primary_key:(PK1,STRING,C),(PK2,INTEGER,1) exclusive_end_primary_key:(PK1,STRING,A),(PK2,INTEGER,5)/响应cosumed_read_capacity_unit: 1 rows: primary_key_columns:(PK1, STRING, C

36、), (PK2, INTEGER, 1),primary_key_columns:(PK1, STRING, B), (PK2, INTEGER, 10) attribute_columns:(Attr1, STRING, Apple),primary_key_columns:(PK1, STRING, A), (PK2, INTEGER, 6) attribute_columns:(Attr2, STRING, Blood)/请求table_name: table_name/请求table_name: table_namedirection: FORWARDdirection: FORWAR

37、Dinclusive_start_primary_key:(PK1,STRING,C),(PK2,INF_MIN) exclusive_end_primary_key:(PK1,STRING,C),(PK2,INF_MAX) columns_to_get:Attr1/响应cosumed_read_capacity_unit: 1 rows: attribute_columns: Attr1, STRING, Alpha/请求table_name: table_name /请求table_name: table_name direction: FORWARDinclusive_start_pri

38、mary_key:(PK1,STRING,C),(PK2,INF_MIN) exclusive_end_primary_key:(PK1,STRING,C),(PK2,INF_MAX) columns_to_get: Attr1,PK1/响应cosumed_read_capacity_unit: 1 rows: primary_key_columns:(PK1, STRING, C)primary_key_columns:(PK1, STRING, C) attribute_columns:(Attr1, STRING, Alpha)例子7，使用limit和断点/请求1/请求1table_na

39、me: table_name direction: FORWARDinclusive_start_primary_key:(PK1,STRING,A),(PK2,INF_MIN) exclusive_end_primary_key:(PK1,STRING,A),(PK2,INF_MAX) limit:2/ 响 应 1 cosumed_read_capacity_unit: 1 rows: primary_key_columns:(PK1, STRING, A), (PK2, INTEGER, 2) attribute_columns:(Attr1,STRING,Hell),(Attr2,STR

40、ING,Bell),primary_key_columns:(PK1, STRING, A), (PK2, INTEGER, 5) attribute_columns:(Attr1, STRING, Hello)next_start_primary_key:(PK1, STRING, A), (PK2, INTEGER, 6)/请求2table_name: table_name direction: FORWARDinclusive_start_primary_key:(PK1,STRING,A),(PK2,INTEGER,6) exclusive_end_primary_key: (PK1,

41、 STRING, A), (PK2, INF_MAX) limit:2/ 响 应 2 cosumed_read_capacity_unit: 1 rows: primary_key_columns:(PK1, STRING, A), (PK2, INTEGER, 6) attribute_columns:(Attr2, STRING, Blood)例子8，GetRange操作消耗的读服务能力单元计算。在以下表中执行GetRange操作，其中PK1是表的主键列，Attr1、Attr2是表的属性列。PK1Attr1Attr21不存在String(1000Byte)28String(1000Byte

42、)3String(1000Byte)不存在4String(1000Byte)String(1000Byte)/请求/请求table_name: table2_name direction: FORWARDinclusive_start_primary_key:(PK1,INTEGER,1) exclusive_end_primary_key:(PK1,INTEGER,4) columns_to_get: PK1,Attr1/响应cosumed_read_capacity_unit: 1 rows: primary_key_columns:(PK1, INTEGER, 1),primary_ke

43、y_columns:(PK1, INTEGER, 2),attribute_columns:(Attr1, INTEGER, 8),primary_key_columns:(PK1, INTEGER, 3), attribute_columns:(Attr1, STRING, String(1000Byte),此次GetRange请求中获取的第一行数据大小为len(PK1)8Byte11Byte第二行数据大小为：len(PK1)8Bytelen(Attr18Byte24Byte第三行数据大小为：len(PK1)8Bytelen(Attr11000Byte1016Byte24Byte1016By

44、te1051Byte除以4KB向上取整，该GetRange操作消耗1个单位的读服务能力单元。更多详细信息可以参看API Reference中的GetRange章节。最佳实践Table Store数据操作的最佳实践使用Table Store SDK 进行表操作使用TableStore Java SDK 进行表操作使用TableStore Python SDK 进行表操作使用Table Store API应用程序可以使用阿里云官方发布的Table Store SDK来访问Table Store，也可以通过POST方法发送HTTP请求来访问Table Store。本章将介绍HTTP请求结构和数据格式

45、，以及如何构造HTTP请求和解析HTTP请求的返回结果。最后介绍Table Store请求返回的错误状态码。Java和Python语言的开发者可使用官方的Java和Python SDK。如果需要使用Java和Python以外的语言访问Table Store，可以根据本章内容使用HTTP消息与Table Store进行交互，也可以自行编写SDK。当前Table Store API版本API Version: 2014-08-08HTTP消息Table Store接收应用程序的HTTP请求，执行相应的逻辑并以HTTP消息返回处理后的结果数据。HTTP请求和响应中的数据通过ProtocolBuffe

46、r协议格式进行组织，关于ProtocolBuffer协议的更多内容，请参考Table StoreProtocolBuffer。下面分别介绍HTTP请求header和body以及响应的具体格式。HTTP RequestHTTP Request URL外网访问URL:http:/./内网访问URL:http:/./外网访问URL:http:/./内网访问URL:http:/./instance 实例名称。实例由用户创建，可以在Table Store控制台查看云账户下拥有的Instance信息。大小写不敏感。region阿里云服务节点。Table Store服务会部署在多个地理位置不同的阿里云服务节

47、点内。创建实例时需要制定阿里云节点，可以在Table Store控制台查看实例所在的阿里云服务节点名称。大小写不敏感。operation HYPERLINK http:/myI/ListTable http:/myI/ListTableTable Store操作名称，可以在API Reference一章查看所有的Table Store操作名。大小写敏感。 HYPERLINK http:/myI/ListTable http:/myI/ListTableHTTP Request HeaderTable Store规定HTTP请求的Header必须包含以下信息:x-ots-date请求发出时间，日

48、期格式采用rfc822标准，并使用UTC时间，格式为%a, %d %b %Y %H:%M:%S GMTx-ots-apiversion API版本号为2014-08-08x-ots-accesskeyid 用户的AccessKeyIDx-ots-instancename 实例名称x-ots-contentmd5对HTTP body中计算出的MD5，使用base64进行编码x-ots-signature请求的签名。签名计算方式如下:Signature = base64(HmacSha1(AccessKeySecret, StringToSign);Signature = base64(HmacS

49、ha1(AccessKeySecret, StringToSign);StringToSign = CanonicalURI + n + HTTPRequestMethod + nn + CanonicalHeadersCanonicalHeaders = LowerCase (HeaderName1) + : + Trim(HeaderValue1) + n + . + LowerCase (HeaderNameN)+ : + Trim(HeaderValueN) + n伪代码中使用到的函数的说明:HmacSha1 - Hmac-Sha1加密算法。计算Table Store请求签名时请将St

50、ringToSign作为消息，AccessKeySecret作为密钥base64 - base64编码算法LowerCase - 将字符串中的字母全部变成小写Trim - 去除字符串首尾处的空白字符CanonicalURI HYPERLINK http:/myI/ListTable http:/myI/ListTable HYPERLINK http:/myI/ListTable http:/myI/ListTableHTTPRequestMethodHTTP请求方法，如GET、POST或PUT等，Table Store的HTTP API只支持POST方法。注意POST需要大写Canonica

51、lHeadersCanonicalHeaders是Table Store HTTP header按照以下规则构造的字符串(不包括x-ots-signature头):需要包含且只包含所有以x-ots-开头的Table Store标准头header项名称全部小写，值必须经过trim去除空格header项按照名字的字典序从小到大排序 header项的名称和值之间以:相隔每个header之间以换行符相隔Table Store会对HTTP请求进行验证:验证x-ots-contentmd5头的值与HTTPBody中所含数据计算出的MD5是否一致验证请求头中包含的签名是否正确验证x-ots-date包含的时

52、间与服务器时间相差小于15分钟若认证未通过，Table Store会直接返回身份认证错误。HTTP Request BodyTable Store规定HTTP请求的Body部分是Table Store定义的ProtocolBuffer消息序列化之后的字符串，Body长度不超过2MB。Table Store请求的ProtocolBuffer消息定义可以参看TableStore ProtocolBuffer 消息定义。HTTP ResponseHTTP Response HeaderTable Store规定HTTP响应的Header包含以下信息:x-ots-date请求发出时间，日期格式采用rf

53、c822标准，并使用UTC时间，格式为%a, %d %b %Y %H:%M:%S GMTx-ots-requestid 本次请求的请求IDx-ots-contenttype响应的内容类型。固定为protocol buffer的字符串x-ots-contentmd5根据响应内容计算出的MD5值，使用Base64编码Authorization响应的签名。只有请求的签名被Table Store验证通过的条件下，响应才会包含签名。签名计算方式如下:Authorization=OTS+AccessKeyID+:+base64(HmacSha1(AccessKeySecret, stringToSign)

54、StringToSign = CanonicalHeaders + CanonicalURICanonicalHeaders=LowerCase(HeaderName1)+:+Trim(HeaderValue1)+n+.+ LowerCase (HeaderNameN) + : + Trim(HeaderValueN) +n伪代码中使用到的函数的说明: 与上面请求中所用到的函数相同CanonicalURI HYPERLINK http:/myI/ListTable http:/myI/ListTable HYPERLINK http:/myI/ListTable http:/myI/ListT

55、ableCanonicalHeadersCanonicalHeaders是Table Store HTTP header按照以下规则构造的字符串(不包括x-ots- signature头):需要包含且只包含所有以x-ots-开头的Table Store标准头header项名称全部小写，值必须经过trim去除空格header项按照名字的字典序从小到大排序 header项的名称和值之间以:相隔每个header之间以换行符相隔客户端应该对Table Store响应进行以下验证:验证响应头中包含的签名是否正确验证x-ots-date包含的时间与客户端时间是否相差15分钟（正负15分钟）验证x-ots-

56、contentmd5头的值与响应数据计算出的MD5是否一致如验证不通过，用户应该在代码中拒绝这个响应所包含的数据，该响应有可能不是Table Store服务返回的。HTTP Response ContentTable Store规定HTTP响应的内容是Table Store定义的ProtocolBuffer消息序列化之后的字符串，Body长度 不超过2MB。每一个Table Store请求消息对应一个Table Store响应消息，应用程序将响应内容反序列化之后，读取Table Store操作的结果。签名示例下面提供了两个请求和响应的签名验证示例，用户可以在实现签名算法后用下面的例子测试算法的

57、实现是否正 确。请求签名示例POST /ListTable HTTP/1.0 x-ots-date: Tue, 12 Aug 2014 10:23:03 GMT x-ots-apiversion:2014-08-08x-ots-accesskeyid: 29j2NtzlUr8hjP8bPOST /ListTable HTTP/1.0 x-ots-date: Tue, 12 Aug 2014 10:23:03 GMT x-ots-apiversion:2014-08-08x-ots-accesskeyid: 29j2NtzlUr8hjP8bx-ots-contentmd5: 1B2M2Y8Asg

58、TpgAmY7PhCfg= x-ots-instancename: naketest那么用户请求的签名结果如下stringToSign = /ListTablenPOSTnnx-ots-accesskeyid:29j2NtzlUr8hjP8bnx-ots-apiversion:2014-08-08nx-ots- stringToSign = /ListTablenPOSTnnx-ots-accesskeyid:29j2NtzlUr8hjP8bnx-ots-apiversion:2014-08-08nx-ots- contentmd5:1B2M2Y8AsgTpgAmY7PhCfg=nx-ots-

59、date:Tue, 12 Aug 2014 10:23:03 GMTnx-ots- instancename:naketestnsignature = base64(HmacSha1(8AKqXmNBkl85QK70cAOuH4bBd3gS0J, stringToSign)= 4xap392B7EBpN+RmlHgNowjoG1w=响应签名示例假设用户的AccessKeyID为:29j2NtzlUr8hjP8b，AccessKeySecret为: AKqXmNBkl85QK70cAOuH4bBd3gS0J/ListTable/ListTablex-ots-contentmd5: 1B2M2Y8

60、AsgTpgAmY7PhCfg=x-ots-requestid: 0005006c-0e81-db74-4a34-ce0a5df229a1 x-ots-contenttype: protocol bufferx-ots-date:Tue, 12 Aug 2014 10:23:03 GMTstringToSign = x-ots-contentmd5:1B2M2Y8AsgTpgAmY7PhCfg=nx-ots-contenttype:protocol buffernx-ots- date:Tue, 12 Aug 2014 10:23:03 GMTnx-ots-requestid:0005006c