表格存储Table Store-建表时的注意事项-问答-阿里云开发者社区-阿里云

开发者社区> 问答> 正文

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

云栖大讲堂 2017-10-26 10:46:15 1981

建表时需要指定属性列吗?
不需要。Table Store支持半结构化的表,即建表时只需要指定主键列(1至4列),不需要在创建表的时候指定具有哪些属性列。Table Store表中包含的属性列个数无限制,且每一行数据可以拥有不同数量不同类型的属性列。在应用写入数据时,Table Store需要应用指定数据所有列(主键列及属性列)的列名和列值。

建表时主键(Primary Key)的第一列为分片键(Partition Key)怎么理解?
首先,主键的第一列为分片键,可以理解为当表的数据量达到一个设定值时,Table Store会根据分片键列值的范围来进行分片的操作,通过分片来达到数据访问负载均衡的目的。
建表时,表内的数据默认拥有一个分片,即该表的所有数据在一个数据分片上。当表拥有多个分片时,每个分片所存储的数据对应的是该表分片键列值某个范围内所有的数据。所有的分片键列值范围是按照其列值自然序切分的,即按照Interger或String(主键列数据类型)的自然序切分。
除了会影响到数据访问的性能,数据的分片也会影响到用户预留读/写吞吐量的使用率。当表拥有多个分片时,该表的预留读/写吞吐量会按照一定的比例预分配到各个分片上。

如何设定一个好的分片键?
在建表时,分片键的选择是很重要的,会影响当表数据量很大时访问的性能。应用在选择分片键时,应该遵循以下一些基本原则:
- 不要使用拥有固定值或取值范围较小的属性,如用户性别(Male/Female)。
- 尽量避免使用按自然序排序后会有明显访问热点的属性,如在查询最新数据场景中使用时间戳(TimeStamp)作为分片键。
- 尽量使用按自然序排序后访问热点比较分散的属性,如UserID。

Tips: 如果无法很好的预估会控制应用的访问热点,该怎么做?
建议的做法是在写入分片键之前根据应用的特点进行一次哈希(Hash)。如在写入一行数据时,将UserID通过简单的哈希算法生成一个哈希值,再在哈希值后拼接UserID作为分片键的值存入Table Store的表。通过这种轻量级的操作可以有效的解决部分访问热点问题。但是需要特别注意的是,由于分片键的值是由哈希值和实际值拼接的,应用将无法使用分片键进行范围读取的操作(getRange)。

为什么一个账户下会有表个数的限制?
每个Table Store用户一共可以建10个实例,每个实例可以建64个表,也就是Table Store限制在一个账户下最多可以建640个表。放开表个数的需求一般有以下几种情况:
- 数据量大、访问性能要求高怎么办:
不同于传统的SQL数据库(如mySQL) 解决海量数据访问需求的方法往往是分库分表,Table Store作为分布式实现方式很好的解决了数据量及访问延迟的瓶颈。也就是用户可以将结构化或半结构化的数据存在一张稀疏的大表中,不用担忧数据量过大后的访问的性能问题。
- 应用的快速增长:
除了数据本身及访问量的增长,用户可能使用Table Store为他们的客户(如用户的第三方伙伴,供应商等)提供服务。以用户为他们的供应商提供服务为例,那么用户有了一套基于Table Store的解决方案后,每来一个供应商我就部署一组Table Store的表。这样,100个表的限制很快就不够了。可这样做的问题会造成运维成本的不可控,也增加了后续全局数据分析的难度。所以建议在使用Table Store时可以更多的打破传统思想,使用大表的概念将同类型海量结构化及半结构化数据存在一张表上。
- Table Store服务本身的考虑:
基于Table Store分布式的实现,表的个数也成为了Table Store本身的一个资源属性。可以理解为在Table Store集群规模一定的情况下,表的个数是有一个最大值的。当然,Table Store的扩展能力可以有效的解决表个数的限制,但从Table Store服务本身资源可控性角度来看,Table Store设定了单个账户表个数的限制。
了解以上的情况后,如果仍然需要有增大一个帐号下表个数的需求,您可以开工单或者联系您的客户经理。
存储 SQL 运维 负载均衡 NoSQL 算法 数据挖掘 数据库
分享到
取消 提交回答
全部回答(0)
数据库
使用钉钉扫一扫加入圈子
+ 订阅

分享数据库前沿,解构实战干货,推动数据库技术变革

推荐文章
相似问题
推荐课程