浅谈QianBase TP的“瘦身”

QianBase TP是一个轻量级快速部署、方便易用的集中式数据库，数据库通过保留变更前的记录来实现多版本并发控制（MVCC），从而解决读写冲突以提高数据库高并发场景下的吞吐性能。为实现多版本并发控制，QianBase TP会保留变更前的历史记录在表空间中，但频繁的数据变更极大可能导致旧版本数据空间来不及进行空间回收，从而导致表空间膨胀，因此通过vacuum和vacuum full对空间回收显的尤为必要。

Vacuum和相关的autovacuum进程是控制QianBase TP由于多版本并发控制机制导致膨胀的方法。Vacuum有两种方式：第一种是普通的vacuum，第二种是vacuum full，这两种是完全不同的，不能混淆。

普通的vacuum扫描表，将不再需要的元组标记为可用空间，以便他们被新插入或新更新的数据复写。我们几乎不需要在QianBase TP数据库上直接使用vacuum命令，因为如果正确设置，autovacuum进程会代替我们处理好。

Vacuum full与vacuum不同，会涉及到尚未删除的数据。在QianBase TP 9.0之前的版本上，它将数据移动到文件中较早释放的空间中。一旦在文件末尾创建可用空间则截断文件，以便操作系统知道该空间是可用的，并且可以将其用于其他用途。以这种方式移动使用中的数据会产生不利的副作用，包括沉重的锁，增加io以及增加索引膨胀等。在较旧的系统上，如果需要，有更好的释放空间的方法，还有优化表的更好的方法，因此，基本上不应该在9.x之前的系统上使用vacuum full，这样做可能会产生大量的WAL归档输出和导致流复制上的服务器高负载等。

vacuum操作会重新回“死”元组的磁盘空间，但不会交给操作系统，而是为新的元组留着。如果删除的记录位于表的末端，且没有元组，其所占用的空间将会被物理释放并归还操作系统。

Vacuum full会把空间返回给操作系统，但是会有一些弊端：

1）排他的锁表，会阻断所有操作；

2）会创建一个表的副本，所以会将使用的磁盘空间加倍，最大可能达到两倍，如果磁盘空间不足，不要执行；

许多基于网上的错误建议，定期在他们的表上运行vacuum full。通常不建议这样做，在某些情况下会使数据库变慢。

vacuum full仅在表中大多数都是死行时才需要，即表中的绝大多数内容都已删除。它不应该用于表优化或定期维护，因为它通常会适得其反。在大多数情况下，释放的空间将被迅速重新分配，可能会增加文件系统级别的碎片，文件系统空间的分配比仅重新使用表中的现有可用空间要慢。

在表上运行vacuum full时，该表在操作过程中会被锁定，因此该表将无法正常工作。vacuum full比正常vacuum慢得多，因此该表可能暂时无法使用。

1、autovacuum

如果autovacuum运行频率足够高且足够有效，则表将永远不会由于死行的持续增长而膨胀，因此永远不需要向操作系统返回“死”空间。

如果autovacuum不足以保持表和索引不膨胀，则对其进行调整，不要用手动清理和重建索引。可能需要增加可用空间映射设，调整autovacuum使其更频繁地运行，让autovacuum较主动地清理某些频繁更新的表。

2、vacuum

除非需要将空间返回给操作系统以便其他表或系统的其他部分可以使用该空间，或者试图修复由于autovacuum没有有效工作而持续膨胀的表，否则应使用vacuum而不是vacuum full。

1、死元组

死行的存在会导致表持续膨胀，相应的查询也会变慢，所以需要持续关注表中死元组的状况，以及死元组与正常元组的比率

(1)select relname,n_dead_tup,n_live_tup from qb_stat_user_tables; 

(2)select relname,coalesce(round(n_dead_tup * 100/(case when n_live_tup + n_dead_tup = 0 then null else n_live_tup + n_dead_tup end ),2),0.00) as dead_tup_ratio from qb_stat_user_tables order by dead_tup_ratio desc limit 5;

2、元组的空间

(1)select relname,relpages reltuples as per_tuple_page from qb_class where reltuples!=0;

(2)select relname,reltuples relpages as per_page_tuple from qb_class where reltuples!=0;

1、表的参数

控制autovacuum执行频率的参数有autovacuum_analyze_scale_factor、autovacuum_analyze_threshold、autovacuum_vacuum_scale_factor和autovacuum_vacuum_threshold，当表上发生变化的行数至少达到此值时，才会让autovacuum进程对其进行vacuum。

autovacuum_vacuum_scale_factor同时控制vacuum的执行条件，默认为50，可以在表上单独设置，让不同的表有不同的配置。

autovacuum进程在表上触发vacuum的条件如下，表上发生变化的行数(更新或删除)>=autovacuum_vacuum_scale_factor * reltuples + autovacuum_vacuum_threshold，autovacuum_vacuum_scale_factor默认为0.2，即表膨胀超过20%就触发，threshold=50是防止一些小表被频繁的触发，我们可以针对某些频繁更新或删除的表单独进行设置，

ALTER TABLE t SET (autovacuum_vacuum_scale_factor = 0.1); 

ALTER TABLE t SET (autovacuum_vacuum_threshold = 10000);

analyze也是类似的机制，由autovacuum_analyze_scale_factor和autovacuum_analyze_threshold参数控制，在此不再赘述。

2、基于代价的清理

为了不影响用户使用，QianBase TP引入了基于代价的清理，从而不过多的占用cpu io。

清理进程从磁盘逐个的读取数据页(8k)，这个过程中还会使用到VM文件，判断其中有没有死元组，如果没有那么就不管了；如果有，就将其中的死元组清理掉，然后标记为脏页，最后写出去。这一过程的成本基于下面三个参数来确定，这样我们可以评估autovacuum的代价。

vacuum_cost_page_hit = 1，清理一个在共享缓存中找到的缓冲区的估计代价。它表示锁住缓冲池、查找共享哈希表和扫描页内容的代价。默认值为1；

vacuum_cost_page_miss = 10，清理一个必须从磁盘上读取到缓冲区的代价。它表示锁住缓冲池、查找共享哈希表、从磁盘读取需要的块以及扫描其内容的代价。默认值为10；

vacuum_cost_page_dirty = 20，当清理修改一个之前干净的块时需要花费的估计代价。它表示再次把脏块刷出到磁盘所需要的额外I/O。默认值为20；

基于以上的代价，每次autovacuum执行有一个代价的限制。假设：

(1) autovacuum_vacuum_cost_delay = 20ms

(2) autovacuum_vacuum_cost_limit = 200

默认是200，执行代价总数为200的工作，每次工作完，间歇20ms，那么实际上执行的多少工作？基于20ms的间隔，清理操作能够每秒做50轮；每轮能够做200代价；那么：

(1) 从shared_buffer读page，80MB/s

(2) 从操作系统(可能是磁盘)读page，8MB/s

(3) 4Mb/s的速度写出autovacuum标记的脏页

基于当前的硬件，这些参数都太小了，对于有缓存的raid卡，这个值应该设置成1000左右，对于固态硬盘（ssd），应该设置成10000。很多用户就是因为这个参数设置的太小，因为autovacuum_vacuum_cost_delay这个参数的原因，vacuum_cost_limit太小就会导致频繁的休眠)，导致一些用户旧版本数据没有得到及时清理，同时导致数据库的年龄不断增加。

3、工作进程数

QianBase TP可以启动autovacuum_max_workers个的进程来清理不同的数据库/表；大表小表的代价不同，这样不会因为大表的工作，阻塞了小表；但是上面的cost_limit是被所有的清理工作进程共享的，所以开多个清理工作进程也不一定快。

所以，当清理进程跟不上用户活动时，提高清理工作进程数是不行的，要提高改变的成本参数。这里其实可以在单独的表上设置这两个值：

(1) ALTER TABLE t SET (autovacuum_vacuum_cost_limit = 1000);

(2) ALTER TABLE t SET (autovacuum_vacuum_cost_delay = 10);

这些表的清理工作的成本，不包含在全局中，单独计算。提高了一定的灵活性，但实际生产中，我们几乎不会用这个特性：

(1) 一般需要一个唯一的全局后台清理成本限制；

(2) 使用多清理工作进程，有时被一起限制，有时单独来，很难监控和分析。

1、不要禁用autovacuum；

2、在update、delete频繁的表上单独设置填充因子（fillfactor）参数，比如80%；

3、在update、delete频繁的业务中，减低比例系数（scale factor），这样清理进程可以及时的进行；

4、在好的硬件下，提高限流阀，这样清理进程不会被中断；

5、单独提高autovacuum_max_worker不行，需要和参数一起调整；

6、使用alter table设置参数要慎重，这会让系统变得复杂。