ADS培训材料-20170915.pptx

ADS 性能优化最佳实践 提纲 ADS 架构 资源选择 建表优化 写入优化 查询优化 ADS 架构 资源类型选择 资源模型选择  数据量超过100GB，均建议C8。 大存储VS高性能 高性能 所有数据预先下载到SSD，随机读性能好。 单机SSD磁盘有限，单机可存储数据不超过1TB。 并发高，单表查询查询毫秒级别 大存储 内存，SSD，SATA（pangu）分层存储，单机可存5-10TB。 数据按需加载到SSD中，在数据具有热点的情况下，性能接近高性能。 新导入数据，第一次查询慢，建议预热查询。 并发低，单表查询秒级。 建表优化-分区列选择 AnalyticDB表一级分区采用hash分区，可指定任意一列（不支持多列）作为分区列。 选择依据 如果有多个事实表（不包括维度表）进行join，选择join列作为分区列。 选择group by 或distinct 包含的列作为分区列。 选择值分布均匀的列，不要选择分区倾斜的列作为分区列。 常用SQL包含某列的等值或in查询条件，选择该列作为分区列。 建表优化-分区数选择 原理 分区并行执行，FRONT 聚合所有分区结果。 分区数过多，聚合开销大。增加FRONTNODE压力，容易长尾。 分区数过少，单线程运行时间长，RT长。 选择依据 参与join的多个事实表分区数必须相同 。 单分区的数据记录数建议为300万条到2000万之间。如果为二级分区，保证每个二级分区的记录数为300万条到2000万条之间。 单表一级分区数最大值为256。 单计算节点的分区数（包括二级分区）不能超过1万. 建表优化-二级分区 使用二级分区场景 数据增量增加 查询带有时间范围 如何设置二级分区列 每个二级分区的数据量/一级分区个数最好在300万条到2000万条之间。 建表优化-列类型 原理 AnalyticDB处理数值类型的性能远好于处理字符串类型。建议尽可能使用数值类型。 常见将字符串转换为数值类型方法 包含字符前缀或后缀，例如E12345，E12346等。可以直接去掉前缀或者将前缀映射为数字。 该列只有少数几个值，例如国家名。可以对每个国家编码，每个国家对应一个唯一数字。 建表优化-主键 ADS默认支持主键覆盖，即相同主键下，后一条覆盖前一条数据。 设置主键的原理 主键必须包括分区键，二级分区键 主键尽可能少，短 主键尽可能递增或递减 Insert 语句最优写法 按hash分区列聚合写入 保证每个batch 写的数据落在同一个hash分区中。 去列名 保持主键相对有序 增加ignore关键字 当写入具有时段性时，每次写完后，执行optimize 操作。 查询优化-索引 AnalyticDB默认所有条件走索引。 在以下四种情况下，索引性能较差。 范围查询（或等值查询）筛选能力差，即满足条件的记录数/表总记录超过10%。 不等于条件查询（不包括not null）。 中缀或后缀查询，例如 like ‘%abc’ 或like ‘%abc%’。 AND 条件中某一条件具有高筛选能力，其他条件走索引性能比扫描性能差。 强制走扫描方法 /*+ no-index=[table1.x;table2.x;y]*/。 查询优化-二级分区 增加二级分区条件 显式增加二级分区条件，减少搜索范围 例子： select * from table where id = 3 and time between ‘2016-04-01 00:00:00’ and ‘2016-04-01 12:00:00’; 如果根据业务场景确认满足time between ‘2016-04-01 00:00:00’ and ‘2016-04-01 12:00:00’ 的二级分区列则可以将该SQL改写为 select * from table where id = 3 and time between ‘2016-04-01 00:00:00’ and ‘2016-04-01 12:00:00’ and pid = 查询优化-改写 避免条件中带函数 例如以下SQL： Select * from table where year（date_test） 1990 应该改为 Select * from table where date_test ‘1990-00-00’ 查询优化-多表查询 可join 条件 对于COMPUTENODE模式的表Join查询，需要满足以下几个条件： 连接计算的所有事实表必须在同一个表组。 所有事实表的一级分区数相同。 事实表Join时， on条件必须包含分区列且必须是等值查询，其他列无限制。 Left join时，右表是事实表时，左表不能是维度表。 查询优化-子查询 原理 AnalyticDB会首