数据也有生辰八字,你信吗?列与列之间、行与行之间、元素与元素之间如何相生相克?查询慢?不要信什么这都是上天注定的,一切都可以通过数据改运实现全局和局部的顺滑优化?
怎么回事呢?且听我细细道来。
数据存储是上天注定的(写入时就决定了),但是我们可以按需改命,例如有个业务是运营商的通话流水,查询需求通常是按某个手机号码查询一个月的流水。而实际上数据是产生时即时写入数据库的,所以存放散乱。查询时耗费大量IO。需求是高效的按手机和月查询通话详单,所以我们需要将用户一个月的数据(通常是按月分区)进行重排即可。你就是上帝之手,数据的命运掌握在你的手中。
精髓就是:
1、局部、全局 两列相对相关性。决定了按某列排序后,另一列的离散度。
2、编排的目的是,可以尽可能的让更多的列有序的存储,从而可以过滤最多的行。
3、全局相关性,决定了按某一列排序时,另一列的离散度。
4、局部相关性,决定了在某些记录中,两列的线性相关性。
5、按局部相关性编排,可以尽可能的让更多的列有序的存储,从而可以过滤最多的行。但是算法较复杂,需要算出什么样的行在一起,按什么排序存放才能获得最佳过滤性。
6、关于多列(或数组)的数据编排,方法1,通过排列组合,计算每两列(元素)的线性相关性,根据这个找出最佳的多列排序组合,从而提高整体相关性(提高压缩比)。
7、编排后,与存储(行号)线性相关性差的列,如果选择性较好(DISTINCT VALUE较多)时,并且业务有过滤数据的需求,建议还是需要建索引。
8、关于多列(或数组)的数据编排,方法2,通过kmean,算出数据归为哪类,每类聚合存放,从而提高数据的局部聚集性,过滤性。这个方法是最优雅的。
9、经过编排,结合PG的BRIN索引,就可以实现任意列的高效过滤。
没错
额,神学
学习
诚然... 同感...(雲下塵埃)