进程结构
- master 进程
- 系统日志进程
- 后台写进程:系统更新插入数据会先写到共享内存,然后再由此进程周期写入数据文件,提供IO效率
- 预写式日志写进程:write ahead log 预写日志,是修改数据之前,必须把操作持久化到日志上,由此进程负责,wal日志可以被循环覆盖。
- 归档进程:在wal日志被覆盖前,会先将其备份,由此进程负责。
- 统计进程:统计相关数据。
- 自动清理进程:在执行delete操作之后,不会立即删除数据文件,在update操作之后,数据库不会立即更新数据,而是增加新的版本数据,mvcc,这些数据由此进程整理。
表隐藏字段
- oid:数据库全局唯一对象id
- ctid:标示物理数据位置,由二元数组组成,前面是数据块编号,后面是对应的行号
- xmin和xmax:xmin标示数据插入事务,xmax标示数据删除事务,更新数据时,会增加一行,修改新旧xmin和xmax
- cmin和cmax:为了应对游标遍历的快照,对于cmax大于当前事务的,不可见,控制mvcc
- tmin和tmax:插入和删除的事务版本
- infomask:用整形位操作,标示事务可见性状态,减少访问clog的次数
MVCC实现原理
- 目的:实现读写并发并且保证数据一致性
- Mysql的innodb引擎和oracle写新数据的时候,将旧数据存放在单独的地方,比如回滚段,直接从那里进行读取
- Postgrsql将用cmin和cmax将事务数据区分,每次更新新数据,都插入新的数据行。
- 如何解决旧数据清理:前面提及到的自动清理进程,等到表数据达到一定量后,会自动清理数据。
- 优势:不用考虑是否被回滚端占用,无论进行多少事务都可以回滚
- 劣势:清理旧数据需要更大的查询遍历
空闲数据块管理和服用
- 记录空闲数据块大小
- 实现数据块快速查找(fsm)
index-only scan
- 索引上没有多版本信息,原版本需要到表中再查询一遍
- 后版本通过可见性映射表实现(存储着某数据块数据行是否对全部事务可见,注意是全部事务,部分可见和不可见之类的情况,都需要按照逻辑1去读取)
hot-only tuples
- 若出现索引对应的数据行出现更新,切数据行的更新非索引字段,如何进行优化
- 由于mvcc的缘故,索引的更新都非直接更新原数据行,而是新增一条记录
- hot技术指的是在如果新旧数据行都同一数据块中,则旧数据行会存有指向新数据行的指针,所以更新非索引字段不会引起索引的结构更改。
- 如果在同一数据块中,hot技术无法使用,需要修改参数(fillfactor)填充因子,设置一个更小的值,即数据块预留一定比例的空闲区域,达到一定数量就不再往数据块中插入数据了,保证hot技术的进行。
double cache问题:
- 由于文件系统对文件会存在缓存,同时postgresql在共享内存中也又相关的缓存,容易导致内存利用率不高
- 解决办法:尽量增大或减少shared buffer的使用
vacuum 优化
- 清理旧版本占用的空间
- 更新统计数据,包装计划正确性
- 当事务id更新到最大值后,会从初始值开始递增,需要将旧版本的事务id,更改为一个永远可见的事务id
- vacuum标准方式:与alert不能并发,速度快
- vacuum full:阻塞所有语句,速度慢,回收空间大
- 为了减少回收的性能代价,通过多个配置参数计算代价值,若超过指定阀值,则自动回收,否则休眠
wal日志优化
- wal日志是保存数据库文件修改,用于出现问题进行回滚,修改的脏数据页不会立即刷新到磁盘。
- 事务检查点,每次产生检查点的时候,都会强制将脏数据刷回磁盘,因此我们需要控制检查点的频率