GPDB总结

一棵大菜

已于 2022-10-13 19:44:06 修改

阅读量568

点赞数 1

分类专栏： Greenplum 文章标签：数据库

于 2022-09-23 20:11:23 首次发布

本文链接：https://blog.csdn.net/Jeni_/article/details/127017296

版权

Greenplum 专栏收录该内容

3 篇文章 1 订阅

订阅专栏

1.Analyze

统计数据是描述存储在数据库中的数据的元数据，查询规划器需要最新的统计信息来为查询选择最佳的执行计划。通过执行analyze语句收集和更新统计信息。analyze命令收集的统计信息会保存到系统表pg_class和pg_statistic。

analyze执行时机

1）加载数据后

2）创建索引操作后

3）数据发生明显变更后，如insert/update/delete操作后

4）analyze表上会申请读锁，注意和其他语句不要产生冲突

改进点	说明
analyze部分列	使用analyze...)为选择的列生成统计信息,确保包含用在连接、WHERE子句、SORT子句、GROUP BY子句或者HAVING子句中的列。
analyze部分分区	只在更改过的分区上执行analyze，同时单独执行analyze收集根分区信息。

analyze基表为什么会耗时很长？	对于分区表，会收集所有分区的信息；即使数据没有变化的分区也会重复收集
analyze耗时和列的关系是怎么样的？	每个列都有对应统计信息，列数多导致耗时变长
analyze基表和分别analyze分区表有差别吗？	analyze基表是analyze分区表的合集操作

pg_class表大小信息

列名	说明
relname	table,index,view等名称。
relpages	表占用的页面（32K）数，是查询规划器生成执行计划的输入；通过vacuum和analyze来更新。
reltuples	表的行数，是查询规划器生成执行计划的输入；通过vacuum和analyze来更新。

pg_stats统计信息

列名	说明
schemaname	schema名称
tablename	表名
null_frac	为空的列项所占的比例
attname	表的行数，是查询计划器生成执行计划的输入；通过vacuum和analyze来更新。
avg_width	该列中非null项的平均存储宽度（以字节为单位）
n_distinct	该列中可区分值的数量估计,基于HLL算法进行估算
most_common_vals	该列中最常见值的数组
most_common_freqs	包含most_common_vals数组中值的频率
histogram_bounds	一个值数组，它把列值划分成大约相同尺寸的分组
correlation	相关关系统计信息，Greenplum不计算该信息

2.VACUUM

删除、更新数据记录时，会产生一些空页，在查询的时候扫描这些空页会影响性能，可以使用vacuum来将这些空页标记为删除，只做标记，不会物理删除，不锁表；使用vacuum full会实际删除这些空页释放物理空间。

对于数据库系统的并发控制，PostgreSQL采用MVCC（多版本并发控制）进行处理。这种机制有一个缺点，就是随着时间的推移，数据文件中积累的dead tuples会越来越多。怎么去清理这些dead tuples，这个时候就需要vacuum处理。

PostgreSQL系统的vacuum是一个例行性的维护过程，系统也会在启动服务时启动autovacuum守护进程对此进行维护，当然也有vacuum命令可以让用户进行手动执行vacuum操作。除了清理dead tuples，vacuum还有冻结事务ID的功能，因为现在PostgreSQL的事务ID只支持32位（大概40亿个事务），当事务ID达到最大值后，它会重新从0开始，这时以前的事务都会变成“未来”的事务变得不可见。

下面主要介绍vacuum清理dead tuples的过程。在清理dead tuples时，系统有两种处理方式：vacuum 和 vacuum full。主要区别在如下：

vacuum	vacuum full
只是把表中的dead tuples进行删除标记，并没有真正物理删除；vacuum过程中，可以正常访问数据表	物理删除表中的dead tuples，释放空间给操作系统；vacuum full过程中，表被锁定，不允许访问

Vacuum过程

vacuum的执行过程主要分为以下三步：

1. 清除dead tuples指向的index tuples

该过程中，vacuum会顺序扫描目标表，并构建一个dead tuples组成的list链表，该list链表会存储在maintenance_work_mem缓存中。然后vacuum根据dead tuples list移除dead tuples指向的index。

2. 移除dead tuples，更新VM和FSM

这里的移除dead tuples只是标记为可重用该空间，并没有真正物理删除。所以vacuum清理表后，表的实际空间并没有减小。dead tuples在做移除标记后，vacuum会重新排列剩余的元组以进行碎片化整理。然后，需要更新目标表的VM（可见性映射文件）和FSM（空闲空间映射文件）。

3. 更新统计信息和相关系统表

最后，需要更新vacuum目标表的统计信息（以适应最新的查询优化）和相关系统表。

Vacuum Full过程

Vacuum Full和Vacuum最大的不同就是，Vacuum Full是物理删除dead tuples，并把释放的空间重新交给操作系统，所以在vacuum full后，表的大小会减小为实际的空间大小。其处理过程和vacuum大不相同，处理步骤如下：

1. vacuum full开始执行时，系统会先对目标创建一个AccessExclusiveLock ，不允许外界再进行访问（为后面拷贝做准备），然后创建一个表结构和目标表相同的新表。

2. 扫描目标表，把表中的live tuples 拷贝到新表中。

3. 删除目标表，在新表上，重新创建索引，更新VM， FSM以及统计信息，相关系统表等。

所以，vacuum full的本质是生成一个新的数据文件，然后把原有表的live tuples存放到该数据文件中。对比vacuum， vacuum full缺点就是在执行期间不能对表进行访问，由于需要往新表中导入live tuples数据，其执行效率也会很慢。优点是执行后，表空间只存放live tuples，没有冗余的dead tuples，在执行查询效率上会有所提高。

AutoVacuum守护进程

由于vacuum是数据库系统的一个例行性维护，所以系统启动后，会开启一个autovacuum守护进程专门对此处理。autovacuum清理进程一般用vacuum而避免使用vacuum full。理由是，vacuum尽管可以保持表的最小尺寸，但是如果表还有继续增长的空间，这么做就意义不大了，特别是对于频繁写入的表。而且vacuum在执行效率上也比vacuum full好。

上面所说的autovacuum进程是一个launcher进程，它不进行vacuum操作，它负责启动vacuum worker进程，然后由vacuum worker进程进行相应的vacuum和analyze操作。

autovacuum进程会在每autovacuum_naptime时间间隔内为数据库启动autovacuum worker进程。然后每个worker进程会检查数据库中的每一个表，在需要时执行vacuum或analyze操作。如果有N个数据库，则每 autovacuum_naptime/N秒将启动一个新worker进程，在同一时间只允许最多autovacuum_max_workers 个worker进程运行，如果有超过autovacuum_max_workers 个数据库需要被处理，下一个数据库将在第一个worker结束后马上被处理。