自己做网站如何盈利,2023新闻摘抄10条,朋友圈网站文章怎么做,供求网站建设PGConf.dev#xff08;原名PGCon#xff0c;从2007年至2023年#xff09;首次在风景如画的加拿大温哥华市举办。此次重新定位的会议带来了全新的视角和多项新的内容#xff0c;参会体验再次升级。尽管 PGCon 历来更侧重于开发者#xff0c;吸引来自世界各地的资深开发者、…PGConf.dev原名PGCon从2007年至2023年首次在风景如画的加拿大温哥华市举办。此次重新定位的会议带来了全新的视角和多项新的内容参会体验再次升级。尽管 PGCon 历来更侧重于开发者吸引来自世界各地的资深开发者、贡献者和研究人员来攻克“棘手难题”但 PGConf.dev 扩大了其范围在强调技术讨论的同时也注重社区贡献。 由 Jonathan Katz 和 Melanie Plageman 等主要成员组成的新会议组织委员会的引领下PGConf.dev 2024 在保留其深厚的技术研讨历史的同时也营造一个更加包容和以社区为导向的环境。特别新增了如“PostgreSQL 黑客入门”、“高级补丁反馈会议”和“让 PostgreSQL 黑客行为更具包容性”等会议旨在指导和激励用户和开发者成为 PostgreSQL 社区的积极贡献者。 以下内容集结了各位大咖对 PGPostgreSQL的独到见解与深刻思考由IvorySQL社区精心整理与大家一起分享。欢迎大家积极转发分享点亮“在看”让更多人领略 PG 的魅力与力量 ✅PUSHING BOUNDARIES WITH EXTENSIONS, FOR EXTENSIONS
Yurii Rashkovskii Yurii 是新创公司 Omnigres 的创办人他致力于提供更好的 PostgreSQL 的插件extension开发和使用体验。Yurii 认为Postgres 扩展生态系统在快速发展的同时也会带来一些局限性和问题。 Omni manifest - 依赖解析器。当一个插件依赖一个或多个其它插件时Omni manifest 会试着在已知的插件存储库例如 pgxn下载依赖的插件 Omni resolver - 插件以外的依赖解析器当一个基于 C 语言的插件需要使用 OpenSSL 或是其它 shared library 的函数他会保证所需的版本和当前加载的shared library 一致。如果是 python 语言的插件它会确认 import 的模块的版本一致。如果 shared library 或是 python 模块在系统上被改变了Omni resolver 会更新 pg_proc 所记载的信息判断出它们是否被改变并及时的报错。 Omni migration - 处理插件版本升级产生的差异函数数据类型等 background worker - 如果插件需要启用一个 background worker 可以通过 omni 自动和 PostgreSQL 内核注册。ALTER EXTENSION 时如果 background worker 要重启Omni 也可以处理 atomic switchboard - Omni 避免多个 background worker 同时启动 hooks - 插件通常通过许多不同的钩子hooks来改变 PostgreSQL 内核的工作模式这些钩子目前没有办法被查看或管理。换句话说我们没法查看系统目前现在到底有几个钩子被插件替换掉哪些没被替换掉。这个只有开发者自己知道。Omni 提供了 hooks 的管理告诉用户哪一些hooks 被哪一些插件给替换了。 transaction aware - hooks 的注册可以被 transaction 保护。如果rollback 了hooks会自动被卸载。 cluster scoping - omni 能做到在不重启的情况下对不同的 database 使用不同的 hooks。现在的 PostgreSQL如果要换 hooks需要重启重新加载extension。 共享内存管理 - 插件也可以注册共享内存但是目前没有一个很好的共享内存管理接口来告诉用户目前有多少共享内存被注册以及被谁注册插件还是 PostgreSQL 内核?。Omni 提供接口查看 共享内存的注册信息以及哪些插件注册了多少共享内存。 整体来说Omni 可以让插件的使用更安全和更透明。 Omnigres 处于开源试用状态https://github.com/omnigres/omnigres ✅SHAVING OFF BYTES AT ANY SCALE: SPACE SAVINGS IN VARIOUS SUBSYSTEMS OF POSTGRESQL
Matthias van de Meent Matthias 是 Neon 的资深工程师他在此演讲中介绍 PostgreSQL 内部的子模块内有哪些地方可以节省存储空间 catalogs-pg_node_tree包含太详细但对用户没什么用的信息不容易解析。 catalogs-pg_attributes104 字节的头信息64字节的名字包含pg_type重复数据4 byte flag但用不到那么多 flag 值。这里有许多空间的浪费 table 存储 - 可见性信息 - 如果 tuple 被 frozen 那它总是可见不需要额外可见性信息导致空间浪费。这个信息可以考虑存在别处来避免table 存储上的浪费。数据量大的时候是很可观的。 数据 padding - 这也是很客观的空间浪费。bool 值其实可以用 1 个 字节表示但系统会自动padding 到 4 个字节。 compression - 某些数据很好压缩例如时间但是 PostgreSQL 没有 page-level 的压缩支持mysql 是有的- 包含索引。这里也有许多空间的浪费 WAL - 一个空的 WAL 记录也会占用 24 字节里面的 xid 也没有人使用无端占用了 4 个字节。里面还有2 个字节莫名的 padding Full Page Insert 和 TOAST 表也可以被压缩来节省空间但目前都不支持 TOAST update - 目前很“空间昂贵”有很多数据的拷贝需要几乎两倍的额外空间完成容易造成 TOAST 膨胀能不能搞一个简单的 API 直接 append 数据 ✅ADAPTIVE QUERY OPTIMIZATION IN POSTGRESQL
Alena Rybakina Alena 解释自适应查询优化 (AQO) 的机制它有一个内置的“规划器内存”。规划器的内存通过分析查询执行树并保存实际基数来填充。如果问题情况再次重复相同查询或具有相同查询子树的另一个查询规划器将利用这些知识这可能使其有机会构建正确的计划从而加快查询执行速度 AQO 根据临近节点neighbot nodes预估执行计划最终需要扫描的行数row number AQO 是基于 k nearest neighbors method 来对一个语句进行不断地“学习” AQO 自动优化执行计划并不断地学习 AQO 存储所有已知查询的选择性和节点行数设置。学习、使用和自动调整 AQO。它存储所有已知查询及其哈希值和查询文本和存储有关执行和计划时间的信息。这些信息可以帮助 AQO 做更好的优化 AQO 通过 Analyzer hooks 截获用户的语句 通过 query executor hooks学习语句执行的信息并把结果融合到 planner 选择执行方法的时候选择最优化的执行计划。 AQO 根据学习状态动态改变执行计划来达到最好的执行效果 目前仅限于单进程的执行计划如果planner 选择多进程来执行某个语句 AQO 需要花更多的时间来做学习效果没有单进程来的好。 后续计划实现从replica 节点学习语句实现从temporary table 学习语句从有限数据的语句学习。 AQO 处于开源状态可以在这里找到https://github.com/postgrespro/aqo ✅POSTGRESQL MEETS ART - USING ADAPTIVE RADIX TREE TO SPEED UP VACUUMIN
Masahiko Sawada 自适应基数树 (ART) 最初发表于 Viktor Leis、Alfons Kemper 和 Thomas Neumann 的论文“自适应基数树用于主内存数据库的 ARTful 索引”是一种利用垂直和水平压缩来创建紧凑索引结构的基数树变体。ART 已被众多软件采用并于 2023 年在 PostgreSQL 中提出。该演讲不仅包括 PostgreSQL 的 ART 实现还包括另一个名为 TidStore 的新数据结构该结构可有效存储 TID 并与 VACUUM 集成。 ART 是一个有序列的可以重建 key 值支持不同大小的叶子节点的树状结构。 有小高度大跨度的属性会占用稍微多的空间但减少了查找traversal的频率 支持单值、多值、混合值的键值类型 64 位元键值大小支持共享内存和用户自定义键值类型 Radix Tree 相关的 API 已在 PG17 内引进lib/radixtree.h相关测试在 src/test/module/test_radixtress 内 新引进 tidstore 结构 用来存储大量的 TID 值 内部使用 Radix Tree 结构 目前支持简单的操作tidstore.c 用来提升 vacuum 的效率 以前 vacuum 怎么工作 vacuum 扫描所有死掉的 tuple然后把它们的 TID 放在一个数组里面 然后一个一个扫描找到他们的 index和相应的table做 vacuum vacuum 问题 空间和效率低下 数组有 1GB 大小闲置不管maintainence_work_mem 设置多大 PG17 把这个数组替换成基于 Radix Tree 的 Tidstore 结构让它使用更少量的内存移除了 1GB 闲置并增加vacuum 效率 目前处于新功能状态测试还没有做的很到位需要社区朋友们帮忙测试找出潜在的问题完善regression 测试等等 ✅ANALYZING CACHELINE CONTENTION USING PERF C2C
Andres Freund postgres 中大量的可扩展性问题是由 CPU 缓存行争用cache line contention引起的。一旦知道了有问题的缓存区域通常就不难修复例如通过减少共享、改善访问局部性或复制数据。更难的是识别争用的缓存行。 在本次演讲中Andres 简要介绍缓存一致性、如何使用 perf c2c 查找争用的缓存行以及如何解决一些已发现的问题。 通常在单一 CPU或是单一 CPU 多个 CORE 的环境下缓存行争用这个现象并不常见但是到了多个 CPU 多个 CORE 的硬件环境下缓存行争用就是一个影响读写性能的现象。这个现象可以通过像 perf c2c 这种工具发现 cache line 通常大小为 64 位元 Andres 对 CPU 缓存结构做了简单的解释 L1i指令高速缓存 L1d数据高速缓存 L2快速缓存 L3缓存跨核心共享 当读和写的操作都落在同一个 cache line 上的时候CPU 缓存行争用的现象就会发生导致延迟增加和吞吐量降低。 当 CPU 内核必须等待另一个内核更新缓存行时可能会导致内核停顿从而浪费 CPU 周期并降低整体效率。 CPU 缓存行争用影响多大 高并发性 - 影响最大 多个插槽 - 非常糟糕 一个插槽中有多个芯片组 - 非常糟糕 一个芯片组中有多个内核 - 有点糟糕 怎么优化 将数据分散到更多的缓存行中 - 但会浪费更多内存 分离写入密集型数据和读取密集型数据 从根本上重新设计数据结构 重新设计锁 perf c2c 工具 可以用来调查 CPU 缓存行争用 Load Latency 加载延迟表示加载指令的延迟。高延迟可能表明存在缓存争用。 L1D/L2 Cache Misses L1D/L2 缓存未命中高未命中率可能表明数据经常在内核之间失效和传输。 Cache Line Transfers 缓存行传输显示缓存行在内核之间的传输频率这是争用的直接指标。 通关简单的把 PostgreSQL buffer descriptor 的数据大小强行做 64 位元的对齐可以看到显著的 TPS 性能提升。这个排序强制每一次的查找都是放在独立的 cache line而不会和其它内核共享 ✅IMPLEMENTING ROW PATTERN RECOGNITION
Tatsuo Ishii 自 SQL:2016 以来行模式识别 (Row Pattern Recognition) 就已定义。RPR 是分析复杂数据尤其是一系列数据的强大功能。使用 RPR您可以通过定义搜索条件和正则表达式在一系列行中找到特定趋势 主要目的是通过“正则表达式” 来从数据里面识别特定序列或事件的状况如检测股票价格模式、异常检测等。 支持 pettern 变量关键字例如 START UP DOWN 支持 pattern 查找例如 INITIAL DEFINE PATTERN FIRST, LAST, PREV, NEXT WINDOW MATCH_RECOGNIZE 等等 例子 SELECT *FROM table_nameMATCH_RECOGNIZE ( PARTITION BY partition_column ORDER BY order_column MEASURES measure_definitions ONE ROW PER MATCH | ALL ROWS PER MATCH AFTER MATCH SKIP TO NEXT ROW | PAST LAST ROW | FIRST ROW PATTERN (pattern) DEFINE variable AS condition); RPR 相关测试在 src/test/regress/sql/rpr.sql 预计 PG18 发布 更多的关键字会在后续补丁提供目前不支持的有 SEEK AGGREGATES Subqueries CLASSIFIER ✅MYSQL REPLICATION DEEP DIVE, AND IDEAS FOR POSTGRESQL
Jagdeep Sidhu PostgreSQL 最初支持物理复制在 PostgreSQL 10 中内置了对逻辑复制的支持。而 MySQL 仅支持逻辑复制。在本次演讲中Jagdeep 介绍 MySQL 复制的实现细节 - MySQL 如何写入二进制日志并确保它与存储引擎一致二进制日志如何应用于副本以及各种优化技术。 MySQL 为了实现逻辑复制增加了 binary log 的功能 MySQL 原本就指出 REDO log UNDO log这个 PostgreSQL 不支持因为不需要 MySQL 的更新都是 in-place update所以需要 UNDO log 来往回rollback 如果事务回滚。PostgreSQL 基于 MVCC 所以不需要 UNDO MySQL Binary log 里面记录着逻辑复制的每一行改动也需要 primary key来表征哪一行被删除了 包含原生 SQL 语句 和改动的 行信息 Global Transaction ID 用来追踪拿一些改动已经被复制了拿一些还没有。类似 PostgreSQL 的逻辑复制槽 存在于表和binary log内 全局唯一基于server id 和 transaction UUID 组成 也可用来逻辑复制的自动定位 2 phase commit 每当 MySQL 改动了一行数据这个动作会被记录在 REDO log UNDO log 和 binary log 如何确保全部的文件都被写成功了是个问题 MySQL 使用 2 phase commit 来确保所有的文件都已被写入这个和 PostgreSQL 的 2 phase commit 概念一致 缺点就是写的开销大老是要call fsync Group commit 用来减缓 2 phase commit 的开销 运行批量提交在处理大事务时还是会慢 Parellel Apply MySQL 支持并行处理逻辑复制 重叠时间线上的提交可以并行处理 只对处理顺序没有要求的情况下启用。 PostgreSQL 的 parallel apply 只在处理大事务的情况下才会启用。和 MySQL 的触发点不一样 ✅ONLINE UPGRADE OF REPLICATION CLUSTERS WITHOUT DOWNTIME
Hayato Kuroda 目前流式复制集群需要大量的停机时间才能升级。在 PostgreSQL 中寻找无需停机即可升级复制集群的方法一直是一个讨论点。Hayato 将讨论在不停机的情况下升级复制集群的问题并介绍新引进的工具 pg_subscriber 来减少升级流式复制集群所需的一些手动步骤。 目前的 PostgreSQL 流复制的架构主备节点的版本必须相同流复制才能进行。但如果要升级怎么办呢 可以使用 pg_dump 和 pg_restore但是这个效率不高 也可以使用 pg_upgrade这个比 pg_dump 和 pg_restore 速度快了 7 倍唯一的问题就是服务器必须先关闭。 Hayato 介绍了新的 逻辑复制用法来应对这个需要停机 upgrade 的问题。 使用新工具 pg_createsubscriber 让订阅节点可以重用已经通过物理复制来的数据基础上在做增量的逻辑复制。这个省去了做逻辑复制开始前要做的数据同步的动作。简单来说就是重新运用了物理复制的数据来做逻辑复制。整个升级的步骤可以简化成 pg_createsubscriber 工具基本上可以把物理复制备节点转换成逻辑复制订阅端在不需要重新拷贝数据的情况下。所以在数据量很大的时候有很大的优势。 逻辑复制架构的升级 PG16 和之前的版本做了 pg_upgrade 了以后逻辑复制槽的信息并不会被它需要手动的拷贝和设置逻辑复制才能接续。PG17 以后做的 pg_upgrade时逻辑复制槽会被同步所以升级完毕了以后逻辑复制可以自动接续。整个流程可以被简化成下图 pg_createsubscriber 工具和 logical replication slot 的同步消除了大部分升级造成的停机时间。这些功能已提交到 pg17版本 ✅THE FUTURE OF THE EXTENSION ECOSYSTEM
David E. Wheeler PGXN 可能是最早的 Postgres 扩展注册表但绝非最后一个过去一年包括 database.dev、trunk 等在内的新成员纷纷加入共同表明人们对扩展的兴趣日益浓厚并渴望扩展和改进发现、打包和分发。其他社区也为包管理创建了新的模式和实践包括 JavaScript 的 npm、Go 的 pkg.go.dev 和 Rust 的 crates.io 等。现在是时候重新审视 Postgres 扩展生态系统找出哪些行得通哪些行不通David 也借此演讲介绍 pgxn 2.0 插件很方便可以在不改变和重新编译PG内核的情况下改变pg内核的工作模式。但也引进了许多问题。现在没有一个统一的插件的 repository除了 pgxn 以外还有好几个不同的 repo有些插件要在 github 自己编译有些插件在某个网站上。这些插件的分配生态存在诸多问题例如 无处不在 难以发现 文档较少 难以理解 难以安装 无二进制分发 今年在 Tembo 的赞助下开始了 pgxn v2的开发 更注重在插件的作者 文档和指南 自动化的测试 二进制包的发布 新的 pgxn 插件开发工具 pgxn develop。帮助开发这更有规范的去开发新插件 自动生成插件源代码框架 测试框架 github workflow 框架 github CI 脚本 文档框架 control 文件 meta data makefile 等等
# 创建新插件pgxn develop new --extension --langauge c --vcs github myproject# 升级插件pgxn develop add-upgrade 0.0.2 新的 pgxn 打包工具 自动编译及打包插件 管理所有已安装的插件和版本 升级某个插件 或删除插件 pgxn package buildpgxn package lspgxn package installpgxn upgradepgxn delete ✅TRICKS FROM IN-MEMORY DATABASES
Andrey Borodin 内存数据库具有一些有趣的性能技术。但是其中一些技术在 Postgres 中的用途也有限。将讨论以下主题。 指针调换。主键查找需要经过很长的路从 B 树页面到 IndexTuple再到 tid再到缓冲区再到行指针再到元组再到数据。我们可以试着缩短这个障碍。 更缓存友好的页面布局。二分搜索可以触及更少的缓存行页面可以按列组织 (PAX)。 乐观缓冲区锁定。无需锁定即可读取如果有任何更改则丢弃结果。 为何需要内存数据库用 unlogged table 不就完了- PostgreSQL 用户的一个玩笑话 微秒级的读和写速度in-memory 数据库研发人员的玩笑话 如果数据库真的可以从内存数据库达到微秒及的读写速度那么新一轮的使用场景将会大量的出现 Andrey 基于 UMBRA 的内存数据库论文想要在 PostgreSQL内核里去验证是否会有显著的性能提升。 为了应对广大的用PostgreSQL 需要支持许多不同的数据类型结构等等这导致 PostgreSQL 的内核设计的非常的笼统general。例如 Datum 这个数据类型往往会被当成 SQL 函数的argument但如果直接一点直接用它应该使用的数据类型例如 int这往往会有一些性能提升。 可变尺寸页面 – 如果 buffer manager 可以支持可变大小的 page那么我们完全可以摒弃 TOAST 表进而达到性能提升 当前的 buffer manager 依赖许多 hash 表和3 个buffer 数组来管理一个buffer 数据快这里面有很多查找的动作如果使用一个树结构例如 Radix Tree来管理 buffer manager 的数据块也可以达到性能的提升 但这些性能的提升幅度都很小1% ~2% 左右数据量大的时候超出内存范围时也会有性能降低的问题。 UMBRA 的论文里还提到了不上锁的读这个Andrey 没办法在 PostgreSQL 验证但是它肯定会有性能的提升。但是又会产生数据正不正确的问题因为没上锁 这些都只是 UMBRA 的学术研究提出的观点短时间内还不能对 PostgreSQL 造成实质的改变。 ✅UNCONFERENCE - IMPROVE EXTENSION IN CORE 这个 unconference 主要讨论目前插件架构的可能优化点以及探讨插件的头疼之处 API 稳定性 当 PostgreSQL 有小版本升级例如15.1 到 15.2如果有一些 API 的参数结构发生了变化例如增加了新变量如果插件没有重新编译会导致插件损坏。主要原因插件对某个结构的认知和 PG 内核不同alignment 问题 小版本改动尽量不要改 API 有没有什么工具可以检测插件 API 毁损Omni 的 Yuri 说可能可以在插件的 MAGIC 块里包含小版本信息让后它的 Omni 可以判断有没有版本冲突。 插件开发者应该多用文档描述插件例如它具体用了那些核心 API 新增插件管理后台模块 有人提议在PG 后台新增插件管理器专门来管理插件的版本和兼容性。保证读取插件的顺序解决依赖关系等等。类似 Omni 在做的东西但是做到 PG 内核里。 插件管理器也应当检测插件对共享内存的调用管理钩子函数等等 pgxn 可以在这个插件管理器之上再多增加测试的功能。 显示所有插件信息版本号提供的新SQL函数等等 如果想参与未来的插件优化讨论可以去到 github.com/pgedc 去参与讨论。EDC 是 Extension Development Coalition 的简称 UNCONFERENCE - OBSERVABILIT 这个 unconference 主要讨论能不能把 pg_exporter 的统计信息输出直接做到 PostgreSQL 内核里让pg 的统计信息集成更方便更有效率。 可观察性很重要因为在生产环境没办法直接上 GDB 调试。只能通过 log或是统计信息来找问题 统计信息像是 stack 深度锁的请求使用用时语句处理频率负载率autovacuum 信息等 统计模块也可以做到一定的自我修复还可以更好的和 open-telemetry 和 prometheus 集成 pg_exporter 很好但它毕竟是插件有更多的开销有些系统级别的统计信息它获取不到。如果 PostgreSQL 崩溃pg_exporter 没法得知这些严重事件。只能把此功能做成核心的一部分才能真正的完整的截获这些信息 UNCONFERENCE - TEST ENHANCEMENT这个 unconference 主要讨论能不能把当前 PG 基于 perl 的测试框架升级成 python 的 pytest pytest 可以测试更多复杂的测试比当前的 tap test 架构还更强大。 在做安全功能的 Jacob Champion说他用 pytest 可以动态生成证书做复杂测试还可以仿真黑客在连接上模拟恶意的包测试系统的反应 但用了python 又会有 python 库的依赖问题需要一个 dependency manager 管理或是详细描述python的需求 pytest 还可以输出 pcap capture 文件对安全开发者来说很有帮助。 其它人们对测试的优化包含 能不能不要让 regression test case 依赖前一个测试让每一个测试都独立出来 能否只重新跑失败的regression test而非全部 tap test 的文档描述不清楚很难加新测试 UNCONFERENCE - FUTURE OF BUILD FAR这个 unconference 主要讨论能不能把当前的 CI 架构 github cirrus CI做的更好 有人提议使用 pull request 来做补丁提交然后让 CI 直接泡在一个 pull request 上如果测试通过再 merge 但也有人说你可以自己 fork 一个 PostgreSQL然后自己setup cirrusCI然后自己跑测试通过了以后再把 patch 发出来。cirrusCI 跑在 public repo 是免费的 各有好坏大家都在提自己的观点但大家还是倾向于现有的 CI 架构。 之后可能还是会接着用 cirrusCI且再三强调所有补丁一定要在 CI 上跑成功后才能提交
