Create 20240510_02.md

Author: digoal

202405/20240510_02.md

@@ -0,0 +1,55 @@
+## DB吐槽大会,第92期 - PG wal 持久化(fsync) 不支持并行   
+        
+### 作者        
+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的最终位置.     
+