阿里分析型数据库ads学习记录

1.ads中非分区表关联问题

无法关联或关联出结果不对，主要因为ads目前的非分区表之间的关联仅支持分区列，且分区数相同，主因为ads关联首先根据分区对应，所以所关联的表与当前表分区字段必须一致，分区数也必须一致，否则得到的结果会跟你想象中差很多。而与分区表关联则不受此限制。
使用ads中的维度表

可以与任意表关联，无需对应分区，无需相同分区数。
实际上数据量不大的表优先考虑建成维度表，特别是需要与其他表要关联的表。

维度表的劣势：查询性能不随着扩容提升，浪费更多存储空间，但是对于数据量不大的情况下都不是问题。

2.ads不支持带偏移量的limit

实际上无法做成真实分页，而且最多只能取出前1w条数据。可以使用dump方式解决，但是不建议那么做，ads主要关注快速获得查询结果，并不适用此场景。

3.ads支持count(distinct columnName)
需修改后台配置，
/global/config/query -->新增enableUdfSysGroupDistinctConcat bool类型，值false，然后count distinct可以即时生效

4.UNION无法使用或结果错误

目前仅支持分区列UNION，所以带group by的聚合函数结果或查询出的非分区列结果都不可以使用union。

注：以上基于0.8.18版本，后续版本有所更新，会另写文详解。

之后更新会说明版本。

=====20160805更新===========

版本0.9.10

ads性能优化

1. 注意过滤条件加上表别名

2. 打平关联语句 （采用直接关联表而非关联子查询的方式）

3.将关联条件设置为表聚集列

为什么打平（直接关联表而不采用关联子查询的方式）会比子查询快，这里面涉及什么原理？

打平之后，关联的维度表成为右表，join的时候走索引，所以很快；而子查询情况下，维度表就只能作为左表（子查询会自动将其处理为左表），实时表成为右表。实时部分的数据因为没有强大的索引，所以只能走扫描，这样就慢了。

遇到一个坑！！！强调下！！！

select ... a join b where xrsj>.... 

（a为大表，上百亿数据，b为维度表，上万数据）

这种语句执行的时候，当xrsj这个字段只有a或者b表的时候是完全没问题的，碰巧就是a、b表都有xrsj这个字段的时候，按常理来说，应该报错的！怎么都应该报错才对，然后秀逗了，居然没有报错，还欢快地跑起来了，以至于我一个月都没找到为什么语句那么慢！

所以优化第一句就是过滤条件要加上表别名。

这个bug已经提交给ads开发经理了，不过回复我优先级不会很高，什么时候修复再说。

=====201608011更新===========

分区表与Group-By、Order-By查询

• Group-By条件包含分区列，则应该放到第一列，此时结果是精确的且查询性能很好
• Group-By表达式如果不包含分区列（或第一列不是分区列），则分组数量在范围内（<5000），结果是精确的，但性能随分组数量增加而降低
• Group-By表达式如果不包含分区列（或第一列不是分区列），且分组数量不在范围内（>=5000），此时结果是不精确的且性能随分组数量增加而降低
• 如果Group-By表达式第一列不是按分区列，则Having语句不支持
• 全局分组TOP(N)：Group-By表达式包含分区列，则应该放到第一列，同时包含Order-By表达式，如果分组数量在范围内（<1000），结果是精确的，但性能随分组数量增加而较大降低
• 全局模糊分组TOP(N)：Group-By表达式第一列如果不是分区列且包含Order-By表达式，而且分组
• 数量不在范围内（>=1000），此时结果是不精确的且性能随分组数量增加而较大降低
• 全数据排序：Order-By表达式第一列如果不是分区列，性能会随排序列或表达式取值增加而较大降

使用新引擎不受限制，我估计以后的问题，新引擎都不受限制，毕竟就是为了最大化兼容sql，但是效率较低，最重要的是我现在私有云没有新引擎：)

持续更新中...