使用宽表模型时创建数据表的注意事项

表格存储支持半结构化的表,即创建数据表时只需要指定主键列(14列),不需要在创建表时指定属性列。

表格存储表中包含的属性列个数无限制,且每一行数据可以拥有不同数量不同类型的属性列。在应用程序写入数据到数据表时,应用程序需要指定数据所有列(包括主键列及属性列)的列名和列值。

如何理解建表时主键(Primary Key)的第一列为分区键(Partition Key)?

主键的第一列为分区键,可以理解为当表的数据量达到一个设定值时,表格存储会根据分区键列值的范围来进行分区的操作,通过分区来达到数据访问负载均衡的目的。

创建数据表时,表内的数据默认拥有一个分区,即该表的所有数据在一个数据分区上。当表拥有多个分区时,每个分区所存储的数据对应的是该表分区键列值某个范围内的所有数据。所有的分区键列值范围是按照其列值的自然序进行切分的,即按照主键列数据类型(例如Integer、String)的自然序切分。

除了会影响到数据访问的性能,数据的分区也会影响到您预留读吞吐量和预留写吞吐量的使用率。当表拥有多个分区时,该表的预留读吞吐量和预留写吞吐量会按照一定比例预分配到各个分区上。

如何设定一个合适的分区键?

创建数据表时,分区键的选择会影响当表数据量很大时访问的性能。

在选择分区键时,请遵循以下基本原则:

  • 不要使用拥有固定值或取值范围较小的属性,例如客户性别(Male、Female)。

  • 尽量避免使用按自然序排序后会有明显访问热点的属性,例如在查询最新数据场景中使用时间戳(TimeStamp)作为分区键。

  • 尽量使用按自然序排序后访问热点比较分散的属性,例如用户ID(UserID)。

更多信息,请参见表操作篇

如果无法预估访问热点,该怎么做?

建议在写入分区键前,根据应用程序的特点进行一次哈希(Hash)。例如在写入一行数据时将UserID通过简单的哈希算法生成一个哈希值,然后在哈希值后拼接UserID作为分区键的值存入表格存储的表。通过这种轻量级的操作可以有效地解决部分访问热点问题。但是由于分区键的值是由哈希值和实际值拼接而成的,应用程序将无法使用分区键进行范围读取的操作(GetRange)。

为什么一个账号下会有表个数的限制?

每个表格存储用户可以创建10个实例,每个实例可以创建64个表,即表格存储限制在一个账号下最多可以创建640个表。

不限制表个数的需求一般有以下几种情况:

  • 数据量大、访问性能要求高

    不同于传统的数据库(例如MySQL) 解决海量数据访问需求的方法是分库分表,表格存储作为分布式实现方式解决了数据量及访问延迟的瓶颈。

    您可以将结构化或半结构化的数据存储在一张稀疏的大表中,无需担心数据量过大后的访问性能问题。

  • 应用的快速增长

    除了数据本身及访问量的增长,您可能使用表格存储为您的客户(例如第三方伙伴、供应商等)提供服务。以为供应商提供服务为例,您有了一套基于表格存储的解决方案后,每增加一个供应商就部署一组表格存储的表。这样,表的个数很快达到上限。如果您不断提高表个数的上限,会造成运维成本不可控以及增加了后续全局数据分析的难度。

    建议在使用表格存储时使用大表的概念将同类型海量结构化及半结构化数据存储到一张表中。

  • 表格存储服务本身的考虑

    基于表格存储分布式的实现,表的个数成为了表格存储本身的一个资源属性。可以理解为在表格存储集群规模确定的情况下,表的个数是有一个最大值的。当然,表格存储的扩展能力可以有效地解决表个数的限制,但从表格存储服务本身资源可控性角度,表格存储设定了单个账号表个数的限制。更多信息,请参见通用限制

如果您仍然需要提高一个账号下表个数的限制,请提交工单进行申请。