列存小CU多导致的性能慢问题

问题现象

1. 系统IO长期飙升过高，查询偶发性变慢。
2. 查看偶发慢业务慢时的执行计划信息，慢在cstore scan，且扫描数据量不大但扫描CU个数较多。

   

   如图，一个CU能够存放6W条记录，而计划中7W记录需要扫描2000+ CU，说明当前可能存在小CU较多的情况 。

排查方法

查看相关表CU中数据分布情况，以下操作在DN执行

1. 查看列存表对应的cudesc表

   针对非分区表：

   1	SELECT 'cstore.'||relname FROM pg_class where oid = (SELECT relcudescrelid FROM pg_class c inner join pg_namespace n on c.relnamespace = n.oid where relname = 'table name' and nspname = 'schema name');

   针对分区表：

   1	SELECT 'cstore.'||relname FROM pg_class where oid in (SELECT p.relcudescrelid FROM pg_partition p,pg_class c,pg_namespace n where c.relnamespace = n.oid and p.parentid = c.oid and c.relname = 'table name' and n.nspname = 'schema name' and p.relcudescrelid != 0);

2. 查看cudesc中各CU的rowcount情况

   查询步骤一返回的cudesc表信息，查询结果类似如下，主要关注row_count过小（远小于6w）的CU数量，如果此数量较大，说明当前小CU多，CU膨胀问题严重，影响存储效率和查询访问效率。

   

触发场景

列存频繁小批量导入，针对含分区且分区个数比较多的场景，小CU问题更加突出。

解决方案

业务侧：

1. 对列存表进行攒批入库，单次入库量（有分区则针对单分区单次入库量）接近或大于6w*主DN个数。
2. 表数据量不大时建议改为行存表。

运维侧：

当业务侧因业务特征无法调整入库量时，定期对列存表进行vacuum full可达到整合小CU的目的，一定程度缓解小CU问题。