pb 级云数据库petadata 最佳实践.pdfVIP

PB 级云数据库 PetaData 最佳实践 PB 级云数据库 PetaData/最佳实践 最佳实践 分区表的设计 用户存有海量数据的表应该按照数据规模进行拆解，表的数据将拆解成多个数据分区独立存储，通常的设计原 则是： 1. 主键(Primary Key):单实例数据库不不要求表一定要有主键，但是对于分布式数据库，主键则是必须 的，以保证一行数据是全局唯一的，避免迁移过程出现问题。如果用户没有特殊的性能需求或业务耦 合问题，则应将主键设计为无意义的整数值或者自增的； 2. 分区键(Partition Key):用户的分区表必须按照一种维度进行数据划分，用户在按照分区键维度进行查 询时，就能做到线性性能增长，分区键通常有如下选择方法： 1) 按业务ID切分，如用户ID、商品 ID等，适合每个业务ID的数据较均匀且查询简单的场景； 2) 按多个业务维度切分，用户建立多张表 存入相同数据，但是每张表按照不同业务维度切分，查询时根据过滤条件选择不同的表，以提升访问 性能，适合查询复杂且单一切分方式不能满足需求的场景； 3) 按自增主键切分，若表分区方式为分 区表，主键为自增，且该字段同时为分区键，则此时写入为随机分区，查询需要读取所有分区，适合 有数据偏斜且写多读少的场景； 4) 至少保证在分区键上有一个索引； 业务列 ，其它的列统归为此类，仅用于存储数据，通常要考虑： 1) 列不宜过长，够用即可，临时加 载的长列会消耗额外内存，影响查询性能； 2) 准确定义列的类型，避免查询时使用的类型与表定义 的类型不匹配，从而进行类型转换，以致不能正确使用索引； 3) 优先使用timestamp类型代替其它 时间日期类型，且使用时严格遵守mysql的时间日期格式； 主键索引 ，若主键是自增类型，则主键索引不会对整体性能优化有改善，若主键与业务相关，则可以 对最频繁使用的SQL语句的查询条件建立主键索引，这样可以提升性能； 5. 辅助索引 ，其他情况下，如果不能通过将SQL语句拆解成单分区的，且不能利用主键进行索引优化时 ，需要对全部分区进行扫描，此时可以对这部分全分区扫描的语句的查询条件建立索引，使得在每个 分区上进行访问时，仍然能取得较高的性能 *注：PetaData目前暂不支持广播表（广播表的数据在每个数据分区均有相同副本，用于与分区表进行join） 性能优化原则 常用优化包括 1 PB 级云数据库 PetaData/最佳实践 1) 合理的选择拆分字段。选择拆分字段时需要综合考虑查询性能、分布式事务、热点、数据迁移等多个因素； 2) 掌握SQL的执行计划，尤其是核心SQL。对于不确定的SQL应在分布式数据库执行 explain sql命令，确定 SQL有没有跨分区、有没有改写以及底层有没有合适的索引，合并时是否进行了排序和分组动作； 3) 对底层MySQL建立合适的索引，这一点看似与分布式数据库无关，但却是最重要的。分布式数据库的高性能 依赖于底层数据库的高性能，而对底层数据库性能来说，建立需要的索引是重要的环节； 4) 确保语句能正确使用到索引，例如查询条件能被索引完全覆盖到，保证分区键上有索引等； 5) 查询尽量在单机完成，最为简单的方式就是在分区字段上指定等值条件，使操作只发送到一个后台数据库节 点。若不指定，则操作需要发送到每个后台节点，可能导致性能大幅下降； 6) 尽量避免分布式事务和分布式查询； 7) 同时使用其他适用于MySQL的优化手段； 设计表结构的过程