表格存储对实例的数据总量按小时计费。表格存储以固定的时间间隔统计数据总量,然后计算每小时数据总量的平均值。
如下图所示,表格存储中实例的数据总量是所有表的数据量之和,表的数据量是表中所有行的数据量之和,所有行的数据量是所有单行数据的主键列和属性列数据量之和。
关于最新的单价信息,请参见表格存储价格详情页。
下面举例说明如何计算单行和表的数据量。
计算行数据量
表格存储的每行数据都占用一定的存储空间。开启多版本或设置数据表生命周期后,每一个版本的数据需要包括版本号(占用8字节)、列名和数据值。
存储空间的计算公式:单行数据量=主键列的数据量+所有属性列的数据量
主键列的数据量=主键列的名字长度之和+主键列的值的数据量之和
属性列的数据量计算方式,请参考本文中关于行及表的数据量计算示例的具体说明。
值的数据量的计算方式请参见下表。
数据类型 | 字节数 |
String | UTF-8字符串占用的字节数(表格存储允许值为空的String类型,如果字符串为空,则数据大小为0。) |
Integer | 8 |
Double | 8 |
Boolean | 1 |
Binary | 二进制数据占用的字节数 |
行数据量的计算示例:
数据表主键列为ID(Integer),其他均为属性列。
ID | Name | Length | Comments |
1 | timestamp=1466676354000,value=‘zhangsan’ | timestamp=1466676354000,value=20 | timestamp=1466676354000,value=String(100 Bytes) timestamp=1466679954000,value=String(150 Bytes) |
其中Comments有两个有效版本:
当MaxVersions=2且TTL=2592000时:
单个属性列的数据量=(属性列名字长度之和+8)*有效版本个数+该属性列所有有效版本的值数据量之和
说明在使用多版本(即Max versions>1)或者使用了TTL(即TTL > -1)的场景下,每个版本号需要占用8字节(以下提到的timestamp等同于版本号)。
该行数据量=10+20+22+282=334 Bytes,详情如下:
主键列数据量=len(‘ID’)+len(1)=10 Bytes
属性列Name数据量=(len(‘Name’)+8)*1+len(‘zhangsan’)=20 Bytes
属性列Length数据量=(len(‘Length’)+8)*1+len(20)=22 Bytes
属性列Comments数据量=
(len(‘Comments’)+8)*2+100+150=282 Bytes
当MaxVersions=1且TTL=-1时:
单个属性列的数据量=属性列名字长度之和+属性列的值的数据量之和
说明在不使用多版本(即Max versions=1)且不使用TTL(即TTL=-1)的场景下,版本号不占用字节。
虽然Comments有两个版本,但由于MaxVersions=1,只计算最新的版本。
该行数据量=10+12+14+158=194 Bytes,详情如下:
主键列数据量=
len(‘ID’)+len(1)=10 Bytes
属性列Name数据量=
len(‘Name’)+len(‘zhangsan’)=12 Bytes
属性列Length数据量=
len(‘Length’)+len(20)=14 Bytes
属性列Comments数据量=len(‘Comments’)+150(Bytes)=158 Bytes
计算表数据量
表的数据量是表中所有行的数据量之和。假设存在如下表,ID是主键列,其他均为属性列。当该表Max versions=2且TTL=-1时,其数据量计算方式如下图所示。
对于ID=1的行,其数据量=10(主键列数据量)+282(Comments属性列两个版本的数据量)=292 Bytes。
对于ID=2的行,其数据量=10(主键列数据量)+216(Comments属性列一个版本的数据量)+22(Length属性列一个版本的数据量)=248 Bytes。
因此该表的数据量之和为292+248=540 Bytes。假设一小时内表的数据量之和未发生变化,将会按540 Bytes进行计费。表格存储对单表数据存储量没有限制,用户可以根据自己的实际需求使用,按量付费。
表格存储会异步对各个数据分区过期的数据及超过最大版本号的版本数据进行清理操作,并在清理操作完成后统计该数据分区数据量。清理时长与总数据量相关,一般会在24小时内完成。数据清理操作完成后新写入的数据将在下一个数据清理操作之后计入该分区数据量。
存储量统计周期
表格存储的存储量计量会存在一定延迟,一般在24小时内完成。
表格存储数据表基于LSM架构实现,数据会采取追加写入的方式写入内存,当数据满足一定条件后会转存形成一个小的数据文件。对于单行数据的多次更新与删除操作可能会分散到多个小文件中,直接计算所有文件大小会造成冗余计量。而系统会定期进行数据文件合并(compaction)清理冗余数据,为了保障存储计量的准确性,只记录每次合并后的文件大小。
因此数据写入、更新或删除后,短时间内表大小可能不会有变化,存储量统计存在一定延迟。存储量统计周期与系统合并数据文件的周期一致。