424      微信

分区设计__最佳实践_云数据库 PetaData-阿里云

用户存有海量数据的表应该按照数据规模进行拆解，表的数据将拆解成多个数据分区独立存储，通常的设计原则是：

主键(Primary Key)

单实例数据库不要求表一定要有主键，但是对于分布式数据库，主键则是必须的，以保证一行数据是全局唯一的，避免迁移过程出现问题。如果用户没有特殊的性能需求或业务耦合问题，则应将主键设计为无意义的整数值或者自增的；

分区键(Partition Key)

用户的分区表必须按照一种维度进行数据划分，用户在按照分区键维度进行查询时，就能做到线性性能增长，分区键通常有如下选择方法：

1) 按业务ID切分，如用户ID、商品ID等，适合每个业务ID的数据较均匀且查询简单的场景；

2) 按多个业务维度切分，用户建立多张表存入相同数据，但是每张表按照不同业务维度切分，查询时根据过滤条件选择不同的表，以提升访问性能，适合查询复杂且单一切分方式不能满足需求的场景；

3) 按自增主键切分，若表分区方式为分区表，主键为自增，且该字段同时为分区键，则此时写入为随机分区，查询需要读取所有分区，适合有数据偏斜且写多读少的场景；

4) 至少保证在分区键上有一个索引；

业务列

其它的列统归为此类，仅用于存储数据，通常要考虑：1) 列不宜过长，够用即可，临时加载的长列会消耗额外内存，影响查询性能；2) 准确定义列的类型，避免查询时使用的类型与表定义的类型不匹配，从而进行类型转换，以致不能正确使用索引；3) 优先使用timestamp类型代替其它时间日期类型，且使用时严格遵守mysql的时间日期格式；

主键索引

若主键是自增类型，则主键索引不会对整体性能优化有改善，若主键与业务相关，则可以对最频繁使用的SQL语句的查询条件建立主键索引，这样可以提升性能；

辅助索引

其他情况下，如果不能通过将SQL语句拆解成单分区的，且不能利用主键进行索引优化时，需要对全部分区进行扫描，此时可以对这部分全分区扫描的语句的查询条件建立索引，使得在每个分区上进行访问时，仍然能取得较高的性能

*注：PetaData目前暂不支持广播表（广播表的数据在每个数据分区均有相同副本，用于与分区表进行join）

最后更新：2016-11-23 17:16:03

  上一篇： 公测服务条款__服务条款_云数据库 PetaData-阿里云

  下一篇： 优化建议__最佳实践_云数据库 PetaData-阿里云