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

版权声明:本文为©delin原创文章,未经©delin允许不得转载。 https://blog.csdn.net/jacklin929/article/details/51240536

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,但是效率较低,最重要的是我现在私有云没有新引擎:)

持续更新中...
阅读更多
想对作者说点什么? 我来说一句

没有更多推荐了,返回首页