digoal
2024-05-10
PostgreSQL , PolarDB , DuckDB , 吐槽 , wal , 并行
1、产品的问题点
PG wal日志 持久化(fsync)是单进程写, 不支持并行.
2、问题点背后涉及的技术原理
简单解释一下wal: wal是预写日志, 在修改数据块时, 先写修改日志再修改数据块, 所以当事务提交时, 只要确保该事务之前的WAL已持久化落盘就能保证数据库崩溃后数据也不会丢失.
PG wal writer进程会不断的将wal buffer中的数据持久化到wal文件.
在数据库出现的时代, 当时都是机械硬盘, 而写数据文件的操作是离散IO (update/delete 记录, insert 写入空闲块, 变更索引, 并行会话操作不同的表等) , 离散IO对于机械硬盘来说性能非常差, 因为要不断移动磁头写不同位置的扇区. 为了解决性能问题, WAL应运而生, WAL是文件追加写的方式.
3、这个问题将影响哪些行业以及业务场景
高并发的写入场景, 例如
- 时序数据入库.
- 业务库定时的大量数据清洗清和定时生成大量数据.
- 数据并行导入场景.
4、会导致什么问题?
当数据库写入量特别大时, 产生的WAL会很大, WAL的持久化可能会成为瓶颈.
5、业务上应该如何避免这个坑
WAL放在低延迟高带宽的SSD磁盘上, 不要使用机械盘或云盘作为WAL的存放地.
或者, 设置较大的wal buffer同时开启异步提交模式: synchronous_commit=off , 这个解决的是高并发小事务性能, 对于大量导入无明显提升.
6、业务上避免这个坑牺牲了什么, 会引入什么新的问题
需要使用昂贵的存储. 或者牺牲数据可靠性(有丢失少量数据的可能性风险).
7、数据库未来产品迭代如何修复这个坑
希望支持wal的并行持久化, 充分利用云存储的带宽优势, 弥补单次IO的高延迟(硬件架构限制, 因为要走网络一来一回).
并行持久化WAL时, 为了保证事务一致性, 判断事务是否持久化 commit|abort lsn <= wal lsn 的持久化位点(wal last lsn)的推进应该取没有gap的最终位置.
