为什么高并发小事务, unlogged table不比logged table快多少? - commit wal log

本文涉及的产品
云原生数据仓库AnalyticDB MySQL版,基础版 8ACU 100GB 1个月
日志服务 SLS,月写入数据量 50GB 1个月
云原生数据库 PolarDB MySQL 版,通用型 2核4GB 50GB
简介: 标签 PostgreSQL , unlogged table , logged table , wal writer 背景 unlogged table,这些表的写操作不记录WAL日志。那么这种表的高并发写入一定比logged table快,快很多吗? 实际上一个事务,在事务结束时,也会记录一笔commit或rollback xlog,所以如果是高并发的小事务,commit xlog的

标签

PostgreSQL , unlogged table , logged table , wal writer


背景

unlogged table,这些表的写操作不记录WAL日志。那么这种表的高并发写入一定比logged table快,快很多吗?

实际上一个事务,在事务结束时,也会记录一笔commit或rollback xlog,所以如果是高并发的小事务,commit xlog的量也非常大,从而导致wal writer瓶颈。

观察方法

pg_waldump -b 000000010000017B0000002F|less  

例子

1、commit xlog

rmgr: Transaction len (rec/tot):     34/    34, tx:  775906906, lsn: 17B/24007F38, prev 17B/24007F10, desc: COMMIT 2019-01-07 09:35:34.554660 CST  
rmgr: Transaction len (rec/tot):     34/    34, tx:  775906908, lsn: 17B/24007F60, prev 17B/24007F38, desc: COMMIT 2019-01-07 09:35:34.554672 CST  
rmgr: Transaction len (rec/tot):     34/    34, tx:  775906907, lsn: 17B/24007F88, prev 17B/24007F60, desc: COMMIT 2019-01-07 09:35:34.554674 CST  
rmgr: Transaction len (rec/tot):     34/    34, tx:  775906904, lsn: 17B/24007FB0, prev 17B/24007F88, desc: COMMIT 2019-01-07 09:35:34.554676 CST  
rmgr: Transaction len (rec/tot):     34/    34, tx:  775906909, lsn: 17B/24007FD8, prev 17B/24007FB0, desc: COMMIT 2019-01-07 09:35:34.554676 CST  
rmgr: Transaction len (rec/tot):     34/    34, tx:  775906910, lsn: 17B/24008018, prev 17B/24007FD8, desc: COMMIT 2019-01-07 09:35:34.554677 CST  
rmgr: Transaction len (rec/tot):     34/    34, tx:  775906911, lsn: 17B/24008040, prev 17B/24008018, desc: COMMIT 2019-01-07 09:35:34.554683 CST  
rmgr: Transaction len (rec/tot):     34/    34, tx:  775906912, lsn: 17B/24008068, prev 17B/24008040, desc: COMMIT 2019-01-07 09:35:34.554686 CST  
rmgr: Transaction len (rec/tot):     34/    34, tx:  775906914, lsn: 17B/24008090, prev 17B/24008068, desc: COMMIT 2019-01-07 09:35:34.554688 CST  
rmgr: Transaction len (rec/tot):     34/    34, tx:  775906913, lsn: 17B/240080B8, prev 17B/24008090, desc: COMMIT 2019-01-07 09:35:34.554689 CST  
rmgr: Transaction len (rec/tot):     34/    34, tx:  775906915, lsn: 17B/240080E0, prev 17B/240080B8, desc: COMMIT 2019-01-07 09:35:34.554693 CST  
rmgr: Transaction len (rec/tot):     34/    34, tx:  775906916, lsn: 17B/24008108, prev 17B/240080E0, desc: COMMIT 2019-01-07 09:35:34.554700 CST  

2、table log 和 commit xlog

rmgr: Heap        len (rec/tot):    167/   167, tx:  777196079, lsn: 17B/2F000040, prev 17B/2EFFFF70, desc: INSERT off 18  
        blkref #0: rel 1663/13806/85962 fork main blk 13586  
rmgr: Heap        len (rec/tot):    167/   167, tx:  777196080, lsn: 17B/2F0000E8, prev 17B/2F000040, desc: INSERT off 32  
        blkref #0: rel 1663/13806/85962 fork main blk 13580  
rmgr: Transaction len (rec/tot):     34/    34, tx:  777196077, lsn: 17B/2F000190, prev 17B/2F0000E8, desc: COMMIT 2019-01-07 09:38:41.062496 CST  
rmgr: Heap        len (rec/tot):    167/   167, tx:  777196081, lsn: 17B/2F0001B8, prev 17B/2F000190, desc: INSERT off 26  
        blkref #0: rel 1663/13806/85962 fork main blk 13569  
rmgr: Heap        len (rec/tot):    167/   167, tx:  777196082, lsn: 17B/2F000260, prev 17B/2F0001B8, desc: INSERT off 7  
        blkref #0: rel 1663/13806/85962 fork main blk 13617  
rmgr: Heap        len (rec/tot):    167/   167, tx:  777196083, lsn: 17B/2F000308, prev 17B/2F000260, desc: INSERT off 14  
        blkref #0: rel 1663/13806/85962 fork main blk 13607  
rmgr: Transaction len (rec/tot):     34/    34, tx:  777196078, lsn: 17B/2F0003B0, prev 17B/2F000308, desc: COMMIT 2019-01-07 09:38:41.062509 CST  
rmgr: Transaction len (rec/tot):     34/    34, tx:  777196079, lsn: 17B/2F0003D8, prev 17B/2F0003B0, desc: COMMIT 2019-01-07 09:38:41.062508 CST  
rmgr: Transaction len (rec/tot):     34/    34, tx:  777196076, lsn: 17B/2F000400, prev 17B/2F0003D8, desc: COMMIT 2019-01-07 09:38:41.062511 CST  
rmgr: Transaction len (rec/tot):     34/    34, tx:  777196080, lsn: 17B/2F000428, prev 17B/2F000400, desc: COMMIT 2019-01-07 09:38:41.062511 CST  
rmgr: Heap        len (rec/tot):    167/   167, tx:  777196084, lsn: 17B/2F000450, prev 17B/2F000428, desc: INSERT off 11  
        blkref #0: rel 1663/13806/85962 fork main blk 13613  
rmgr: Heap        len (rec/tot):    167/   167, tx:  777196085, lsn: 17B/2F0004F8, prev 17B/2F000450, desc: INSERT off 20  
        blkref #0: rel 1663/13806/85962 fork main blk 13598  
rmgr: Heap        len (rec/tot):    167/   167, tx:  777196086, lsn: 17B/2F0005A0, prev 17B/2F0004F8, desc: INSERT off 28  
        blkref #0: rel 1663/13806/85962 fork main blk 13575  
rmgr: Transaction len (rec/tot):     34/    34, tx:  777196081, lsn: 17B/2F000648, prev 17B/2F0005A0, desc: COMMIT 2019-01-07 09:38:41.062516 CST  
rmgr: Transaction len (rec/tot):     34/    34, tx:  777196082, lsn: 17B/2F000670, prev 17B/2F000648, desc: COMMIT 2019-01-07 09:38:41.062518 CST  
rmgr: Transaction len (rec/tot):     34/    34, tx:  777196083, lsn: 17B/2F000698, prev 17B/2F000670, desc: COMMIT 2019-01-07 09:38:41.062515 CST  
rmgr: Transaction len (rec/tot):     34/    34, tx:  777196084, lsn: 17B/2F0006C0, prev 17B/2F000698, desc: COMMIT 2019-01-07 09:38:41.062521 CST  
rmgr: Transaction len (rec/tot):     34/    34, tx:  777196086, lsn: 17B/2F0006E8, prev 17B/2F0006C0, desc: COMMIT 2019-01-07 09:38:41.062525 CST  
rmgr: Heap        len (rec/tot):    167/   167, tx:  777196087, lsn: 17B/2F000710, prev 17B/2F0006E8, desc: INSERT off 20  
        blkref #0: rel 1663/13806/85962 fork main blk 13596  
rmgr: Transaction len (rec/tot):     34/    34, tx:  777196085, lsn: 17B/2F0007B8, prev 17B/2F000710, desc: COMMIT 2019-01-07 09:38:41.062534 CST  
rmgr: Heap        len (rec/tot):    167/   167, tx:  777196088, lsn: 17B/2F0007E0, prev 17B/2F0007B8, desc: INSERT off 22  
        blkref #0: rel 1663/13806/85962 fork main blk 13584  
rmgr: Transaction len (rec/tot):     34/    34, tx:  777196087, lsn: 17B/2F000888, prev 17B/2F0007E0, desc: COMMIT 2019-01-07 09:38:41.062541 CST  
rmgr: Heap        len (rec/tot):    167/   167, tx:  777196089, lsn: 17B/2F0008B0, prev 17B/2F000888, desc: INSERT off 5  
        blkref #0: rel 1663/13806/85962 fork main blk 13614  
rmgr: Transaction len (rec/tot):     34/    34, tx:  777196088, lsn: 17B/2F000958, prev 17B/2F0008B0, desc: COMMIT 2019-01-07 09:38:41.062544 CST  
rmgr: Heap        len (rec/tot):    167/   167, tx:  777196091, lsn: 17B/2F000980, prev 17B/2F000958, desc: INSERT off 21  
        blkref #0: rel 1663/13806/85962 fork main blk 13600  
rmgr: Heap        len (rec/tot):    167/   167, tx:  777196090, lsn: 17B/2F000A28, prev 17B/2F000980, desc: INSERT off 38  
        blkref #0: rel 1663/13806/85962 fork main blk 13565  
rmgr: Transaction len (rec/tot):     34/    34, tx:  777196089, lsn: 17B/2F000AD0, prev 17B/2F000A28, desc: COMMIT 2019-01-07 09:38:41.062551 CST  
rmgr: Transaction len (rec/tot):     34/    34, tx:  777196091, lsn: 17B/2F000AF8, prev 17B/2F000AD0, desc: COMMIT 2019-01-07 09:38:41.062552 CST  
rmgr: Heap        len (rec/tot):    167/   167, tx:  777196092, lsn: 17B/2F000B20, prev 17B/2F000AF8, desc: INSERT off 13  
        blkref #0: rel 1663/13806/85962 fork main blk 13589  
rmgr: Heap        len (rec/tot):    167/   167, tx:  777196094, lsn: 17B/2F000BC8, prev 17B/2F000B20, desc: INSERT off 8  
        blkref #0: rel 1663/13806/85962 fork main blk 13611  

性能差异

1、高并发小事务,logged table和unlogged table性能相差无几。

《HTAP数据库 PostgreSQL 场景与性能测试之 39 - (OLTP+OLAP) 含索引多表单点写入》

《HTAP数据库 PostgreSQL 场景与性能测试之 38 - (OLTP+OLAP) 不含索引多表单点写入》

2、批量写入,TPS不高(所以commit xlog占比不高),因此logged table和unlogged table的性能差异会非常大。

《HTAP数据库 PostgreSQL 场景与性能测试之 43 - (OLTP+OLAP) unlogged table 含索引多表批量写入》

《HTAP数据库 PostgreSQL 场景与性能测试之 42 - (OLTP+OLAP) unlogged table 不含索引多表批量写入》

《HTAP数据库 PostgreSQL 场景与性能测试之 41 - (OLTP+OLAP) 含索引多表批量写入》

《HTAP数据库 PostgreSQL 场景与性能测试之 40 - (OLTP+OLAP) 不含索引多表批量写入》

 

免费领取阿里云RDS PostgreSQL实例、ECS虚拟机

相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
目录
相关文章
|
1月前
|
存储 监控 固态存储
在高并发环境下,如何优化 WAL 的写入性能?
在高并发环境下,如何优化 WAL 的写入性能?
|
1月前
|
存储 缓存 关系型数据库
MySQL事务日志-Redo Log工作原理分析
事务的隔离性和原子性分别通过锁和事务日志实现,而持久性则依赖于事务日志中的`Redo Log`。在MySQL中,`Redo Log`确保已提交事务的数据能持久保存,即使系统崩溃也能通过重做日志恢复数据。其工作原理是记录数据在内存中的更改,待事务提交时写入磁盘。此外,`Redo Log`采用简单的物理日志格式和高效的顺序IO,确保快速提交。通过不同的落盘策略,可在性能和安全性之间做出权衡。
1631 14
|
1月前
|
存储 监控 固态存储
如何监控和优化 WAL 日志文件的存储空间使用?
如何监控和优化 WAL 日志文件的存储空间使用?
|
2月前
|
SQL 安全 数据库
基于SQL Server事务日志的数据库恢复技术及实战代码详解
基于事务日志的数据库恢复技术是SQL Server中一个非常强大的功能,它能够帮助数据库管理员在数据丢失或损坏的情况下,有效地恢复数据。通过定期备份数据库和事务日志,并在需要时按照正确的步骤恢复,可以最大限度地减少数据丢失的风险。需要注意的是,恢复数据是一个需要谨慎操作的过程,建议在执行恢复操作之前,详细了解相关的操作步骤和注意事项,以确保数据的安全和完整。
116 0
|
3月前
|
API C# 开发框架
WPF与Web服务集成大揭秘:手把手教你调用RESTful API,客户端与服务器端优劣对比全解析!
【8月更文挑战第31天】在现代软件开发中,WPF 和 Web 服务各具特色。WPF 以其出色的界面展示能力受到欢迎,而 Web 服务则凭借跨平台和易维护性在互联网应用中占有一席之地。本文探讨了 WPF 如何通过 HttpClient 类调用 RESTful API,并展示了基于 ASP.NET Core 的 Web 服务如何实现同样的功能。通过对比分析,揭示了两者各自的优缺点:WPF 客户端直接处理数据,减轻服务器负担,但需处理网络异常;Web 服务则能利用服务器端功能如缓存和权限验证,但可能增加服务器负载。希望本文能帮助开发者根据具体需求选择合适的技术方案。
159 0
|
3月前
|
C# Windows 监控
WPF应用跨界成长秘籍:深度揭秘如何与Windows服务完美交互,扩展功能无界限!
【8月更文挑战第31天】WPF(Windows Presentation Foundation)是 .NET 框架下的图形界面技术,具有丰富的界面设计和灵活的客户端功能。在某些场景下,WPF 应用需与 Windows 服务交互以实现后台任务处理、系统监控等功能。本文探讨了两者交互的方法,并通过示例代码展示了如何扩展 WPF 应用的功能。首先介绍了 Windows 服务的基础知识,然后阐述了创建 Windows 服务、设计通信接口及 WPF 客户端调用服务的具体步骤。通过合理的交互设计,WPF 应用可获得更强的后台处理能力和系统级操作权限,提升应用的整体性能。
106 0
|
3月前
|
存储 缓存 分布式计算
详解HBase中的“WAL”(Write-Ahead Log)
【8月更文挑战第31天】
142 0
|
3月前
|
存储 关系型数据库 MySQL
深入MySQL:事务日志redo log详解与实践
【8月更文挑战第24天】在MySQL的InnoDB存储引擎中,为确保事务的持久性和数据一致性,采用了redo log(重做日志)机制。redo log记录了所有数据修改,在系统崩溃后可通过它恢复未完成的事务。它由内存中的redo log buffer和磁盘上的redo log file组成。事务修改先写入buffer,再异步刷新至磁盘,最后提交事务。若系统崩溃,InnoDB通过redo log重放已提交事务并利用undo log回滚未提交事务,确保数据完整。理解redo log工作流程有助于优化数据库性能和确保数据安全。
554 0
|
3月前
|
存储 SQL 关系型数据库
MySQL事务日志奥秘:undo log大揭秘,一文让你彻底解锁!
【8月更文挑战第24天】本文深入探讨了MySQL中undo log的关键作用及其在确保事务原子性和一致性方面的机制。MySQL通过记录事务前的数据状态,在需要时能回滚至初始状态。主要介绍InnoDB存储引擎下的undo log实现,包括undo segment和record的结构,而MyISAM则采用redo log保障持久性而非一致性。通过一个简单的SQL回滚示例,展示了undo log如何在实际操作中发挥作用,帮助读者更好地理解并运用MySQL事务管理功能。
333 0
|
3月前
|
存储 监控 固态存储
【性能突破】揭秘!如何让您的数据库在高并发风暴中稳如磐石——一场关于WAL写入性能优化的实战之旅,不容错过的技术盛宴!
【8月更文挑战第21天】在高并发环境下,数据库面临极大挑战,特别是采用Write-Ahead Logging (WAL)的日志机制。本文通过一个在线交易系统的案例,分析了WAL写入性能瓶颈,并提出优化方案:理解WAL流程;分析磁盘I/O瓶颈、缓冲区设置与同步策略;通过增大WAL缓冲区、使用SSD及调整同步策略来优化;最后通过测试验证改进效果,总结出一套综合优化方法。
60 0