00:00
好,接下来一个分区和索引。这个大家还有印象吗?先看这个标题区是什么?你能想到啥?是不是想到一个爬梯一声败啊,好,所以呢,哎,对,Click house,你记住最关键的不是什么组件,什么primary key,对吧,最关键的是什么,我。他去重的时候是不是根据autobi字段去做的呀,而且你的组件是不是也必须是autobi你的字段的前缀呀。就有一些很多细节嘛,你就记住奥特曼是最重要的就行了,好吧,所以咱们在建表的时候,首先分区怎么分好。分区跟have的分区概念它不一样吧,就你可以理解为分目录啊,没没毛病,避免全秒扫描,你用的时候是不是可以在V里面对分区字段进行过滤啊,这跟have来这个对比呢,没有太大的差别啊。
01:02
所以你生产上肯定会分区的吧,那分区原则呢?大家想一想能想到吗?你想想你have表离线数仓怎么分的区,正常来讲是不是按天分区会合适一点,一天一个分区啊,啊没毛病,这个也是最常用的一个用法啊好,那我按大家觉得我按分钟来分析好吗。力度不要太小,要注意分区的数量,好吧,同学们,如果你不按天分区,我的推荐建议是在三五三十个左右的分区,一张表图,大的表呢,我给个数,1亿条,大家注意,咱们是大数据开发,对吧?那么你的数据量不要再动不动就是十万一百万这种级别的,你要考虑随随便便也要500万条以上嘛,对吧,尤其是肯利格号就适合做这个啊,1亿条,那如果你不按天分区,你也不要说只分两个区三个区,那没啥意义,对吧?你可以分几十个区啊,那你说分1000个区呢,就没有太必要了,你要么按天分区,要么就几十个分区,1亿来估算的话,1亿条的话,呃,那还有这个索引呢,大家刚才也谈到了,是什么order by,这边都给大家标红了啊。
02:28
那关键出来了,咱们的all的BY同学们是不是可以多个字段呢?那顺序有没有讲究?对,我既然问的肯定是有讲究的,对吧?大家都是答题高手啊,我希望未来答题也比较顺利啊,那么好,其实有一个讲究是什么呢?呃,越前面是不是越先内索引呢?那你想想你查询频率高的是不是放在前面会好一点,对没没错嘛,就这么简单嘛,就像大家呃拍照或者干嘛摆阵型的时候,是不是个子高的先站前面啊,就按按照那个个子顺序站呗,对吧?或者怎么样啊,或者说你的微信列表啊,比如说你是个海王,你你你是两分半啊是吧,你几天一个换一个,几天换一个,但是总有几个在你聊天列表常常在前面的吧,那是不?
03:28
高频被你索引了呀啊,那你高频索引肯定就放前面嘛,对吧,你联系一下生活的例子都能想明白啊,高频率使用的,高频率查询的写前面啊。还有一个就是。基数特别大的。什么意思啊,不适合做索引链,比如说用户ID,像用户ID这种,咱们就不适合对他做索引,为啥?因为他比如说我有1亿条数据,那是不是用户的ID不同的。
04:07
是不是至少也是大几百万呢,也就是说重复率很少嘛,数据基本都不一样嘛,这种就叫做基数大,基数大啊。像这种就不适合了,因为你每条都都不一样啊,假设我们一条每一条都不一样。完全不一样啊,没有重复数据,那你对他做索引,大家觉得有没有意义啊。比如说我是从一编号到1亿,我要找。当然这个是有规律的,对吧?如果没规律呢,那比如说我要找1万这个编号的人,你是不是得挨个去还是得挨个去找啊,对吧?就是这个原因,基数大,你做索引就没有太大意义,这个了解就行了,那通常语法就是一个法地升拜一个order by啊好,来我们总结一下,总结一下,首先我们电表一定要考虑分区,对吧,避免全表扫描,好另外一点怎么来分区比较好呢?业务上生产上常规是按天来分区,也就是说主要按什么时间,大家注意在老一点的可里格号,你不按时间分区它是不行的。
05:22
老一点的版本它是不按十天分区它是不行的啊,当然新版本你比较灵活了啊,但咱们使用上还是这么来,那如果不按十天分区,那咱们按照一个原则,什么原则啊,一条数据分三呃十到30个左右吗?可以吧。好,这是第一个,大家要记住的,第二一个order by,它会做索引吗?那多个字段顺序有讲究。查询频率高的放前面,基数大的尽量不做索引。什么叫基数大?就是列的,它的重复值很少,量特别大,比如说用户ID啊。
06:12
但当然不是说一定不能做啊,比如说用户ID,咱们官方案例里面,那是截取的官方数据集的建表,你看人家用户ID还是取了,但是他会做一个哈希啊。
我来说两句