全部产品
云市场

表格存储Table Store-建表时的注意事项

更新时间:2017-12-06 16:11:24

建表时需要指定属性列吗?

不需要。Table Store支持半结构化的表,即建表时只需要指定主键列(1至4列),不需要在创建表的时候指定属性列。

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

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

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

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

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

如何设定一个好的分区键?

建表时,分区键的选择是很重要的,会影响当表数据量很大时访问的性能。应用程序在选择分区键时,应该遵循以下基本原则:

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

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

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

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

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

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

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

放开表个数的需求一般有以下几种情况:

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

    不同于传统的SQL数据库(如mySQL) 解决海量数据访问需求的方法是分库分表,Table Store作为分布式实现方式很好地解决了数据量及访问延迟的瓶颈。

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

  • 应用的快速增长

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

    建议在使用Table Store时打破传统思想,使用大表的概念将同类型海量结构化及半结构化数据存在一张表上。

  • Table Store服务本身的考虑

    基于Table Store分布式的实现,表的个数也成为了Table Store本身的一个资源属性。可以理解为在Table Store集群规模一定的情况下,表的个数是有一个最大值的。当然,Table Store的扩展能力可以有效地解决表个数的限制,但从Table Store服务本身资源可控性角度来看,Table Store设定了单个账户表个数的限制。

如果您仍然需要提高一个帐号下表个数的限制,请提交工单