看不懂为什么PG14发布之后就开始挤牙膏了
digoal约 6 分钟参考文档点击文末阅读原文打开; 推荐《最好的PostgreSQL学习镜像》;
PostgreSQL 正在挤牙膏? 没看懂
PostgreSQL 正在挤牙膏? 不, 它在云化(适应云)
毫不客气的说: 很多PostgreSQL的最佳实践都是因为PG没有充分发挥块设备的性能, 再不从内核解决这个问题, PostgreSQL就要被云计算时代抛弃了. 例如:
在高并发写的系统中, 频繁更新的表容易膨胀, 建议对频繁更新的系统进行分区. 因为更新是并发的, 而对于单表来说vacuum是单进程的. 在高吞吐写入场景, 建议采用多个表或多个PG实例. 当extendexclusive lock是瓶颈时, 拆表; 当wal 成为瓶颈时拆成多个实例.
所有同步IO或一次一个块的读写, 都非常依赖块设备的IO低延迟. 否则就会导致严重的瓶颈. 例如这篇文章的分析：
《一起学PolarDB - 第23期 - 为什么磁盘RT会严重影响vacuum垃圾回收效率?》
进入云计算时代, 云存储/OSS对象存储成为了存储主流, 主要原因有几个方面:
1、云存储是天然的多副本, 可靠性更高 2、云存储是分布式架构, 弹性更强, 扩缩容更加快捷 3、快照功能. 使得备份、迁移变得更加便利 4、计算和存储分离, 使得多设备可共享云盘, 更利于基于此架构设计存算分离架构应用.
但是云存储块设备都在远程, OSS对象存储也在远程. 这类存储的IO特征与本地nvme盘截然不同. 具体体现为:
云存储的单次RT很高. 云存储标称的IOPS较高, 但是你得加更大的并发才能把这个标称压测出来. (也就是 Queue depth往往要较大.) 云存储标称的吞吐较大, 但是你得加大并发, 或加大单次IO请求数据的大小才能把标称值压测出来. 云存储的顺序IO和离散IO性能几乎无异, 因为底层是分布式块存储.
在使用nvme这种本地低RT、高吞吐、高IOPS的设备时, 前面提到的PG问题并不明显. 但在云计算时代, PostgreSQL上云后问题被放大了, 上云后你的实例最容易遇到的问题可能是:
怎么这么容易膨胀? 不对高频更新表分区的话, 几乎无法避免. 怎么写入速度上不去? (特别是时序类业务, 例如写大量日志.) 开异步wal可以避免这个问题.
幸好PG觉悟了, 正在陆续引入异步IO的底层接口, 上层功能也会陆续支持异步IO. 详见 https://wiki.postgresql.org/wiki/AIO 下面是其中一些功能点的翻译.
底层接口变化
Read stream API
基本缓冲读取流，单对象读取流(relation)— 已在 v17 中提交。 多对象读取流— todo。 场景：recovery过程加速，对 CREATE DATABASE ... STRATEGY=WAL_LOG也有加速效果。
Write stream API
基本缓冲写入流— todo。 驱动 sync_file_range— todo。驱动 WAL 写入频率— todo。 绕过缓冲池，适用于 CREATE INDEX（批量写入）— todo。
已实现
macOS 上的 O_DIRECT
使得 Mac 开发者可以测试io_data_direct=on（工作模式或posix_aio模式）。pg_pwritev()和pg_preadv()
为同步散播/聚集 I/O 提供可移植支持。使用条件变量替换缓冲 I/O 锁
使得除了从内核提取 I/O 的backends外，其他backends也能等待 I/O 完成。对齐的内存分配
用于direct I/O 中使用的缓冲区的要求。直接 I/O GUC
在 16 版本中作为debug_io_direct发布，以避免引起过多关注。修复 Windows 上的
DROP TABLESPACE（带ProcSignalBarrier）
这是 PostgreSQL 在 Windows 上的一个古老 bug，但之前较难复现；在io_method=worker下执行make check每次都会失败，因为进程挂起并持有缓存的文件描述符（fd）。重构relation block extend
允许backend拥有多个处于BM_IO_IN_PROGRESS状态的缓冲区。流式 I/O，向量化 I/O
引入缓冲区流的概念，最初用于更高效的同步 I/O。
使用Read stream的上层功能
在 seq scan中使用流式 I/O— 已在 v17 中实现。在 ANALYZE中使用流式 I/O— 已在 v17 中实现。在 pg_prewarm中使用流式 I/O— 已在 v17 中实现。在 VACUUM中使用流式 I/O— 正在进行中。在 bitmap scan中使用流式 I/O— 正在进行中。与 btree 相关的线程— todo。 与 brin 相关的线程— todo。 与 gist 相关的线程— todo。 与 gin 相关的线程— todo。 CREATE DATABASE STRATEGY=WAL_LOG— todo。recovery database— todo。
使用Write stream的上层功能
写数据的地方不多。
CHECKPOINT— 正在进行中。CREATE INDEX（绕过缓冲池，扩展/替换bulk_write.c功能）— 正在进行中。VACUUM写回操作— 正在进行中。COPY写回操作— 正在进行中。驱逐脏页 写回操作— 正在进行中。
参考
https://wiki.postgresql.org/wiki/AIO
https://anarazel.de/talks/2020-05-28-pgcon-aio/2020-05-28-pgcon-aio.pdf
https://blog.docbert.org/queue-depth-iops-and-latency/
文末彩蛋:国产数据库周边生态
当然一款数据库要流行起来, 除了自己要强大, 还离不开生态. 用好周边生态工具, 管理水平战胜90%老司机!!! 下面简单介绍一下国产数据库周边生态.
1、管控软件
鸣嵩(前阿里云数据库总经理 / 研究员)等大佬们创业创办的云猿生, 核心产品是KubeBlocks. 他们的理念是让管理数据库和搭积木一样简单, 如果你要管理很多套并且种类(OLTP\OLAP\NoSQL\KV\TS\MQ等)很多的数据库产品, 推荐首选.
https://github.com/apecloud/kubeblocks
PG中文社区核心委员唐成老师的公司乘数开源的Clup, 专用管理PostgreSQL和PolarDB的集群管理软件, 如果你要管理很多套数据库, 推荐选择. 并且Clup还提供了企业版、自研的连接池、分布式存储、一体机、备份平台等, 是企业用户推荐之选.
https://www.csudata.com/
若航老司机开源的pigsty, 集成了300多个PG插件的PG集群和PolarDB集群管理软件, 如果你要管理很多套PG或PolarDB数据库, 且对插件有特别多的需求, 推荐选择.
https://pigsty.cc/zh/
2、审计监控诊断优化
翟总(曾经是我背后的男人)到海信聚好看后研发的 DBdoctor, 采用ebpf技术, 在对数据库几乎没有影响的情况下实时监控数据库和服务器的各项指标, 发现和诊断问题根因非常方便.
https://www.dbdoctor.cn/
天舟老哥的核心产品Bytebase 是位于您和数据库之间的中间件。它是数据库 DevOps 的 GitLab/GitHub，专为开发人员、DBA 和平台工程师打造。
https://bytebase.cc/docs/introduction/what-is-bytebase/
PawSQL, SQL优化和诊断产品.
D-Smart, Oracle老前辈白老大出品, 专注企业级市场, 将业界顶级DBA经验的产品化作品, 产品功能包括数据库监控、诊断、优化等.
https://www.modb.pro/db/567140
3、国产数据库IDE
IDE是开发者的必备工具，例如社区有pgAdmin, 国产IDE则可以看看老程序猿达刚老师的DeskUI:
https://www.deskui.com
4、数据同步&迁移&备份恢复
NineData, 老领导出去创业做的产品, 产品涵盖了数据同步、迁移、备份、比对、devops、chatDBA等.
https://www.ninedata.cloud/home
DSG, 非常老牌的数据库同步迁移企业级产品, 支持各种数据库的异构和同构迁移, 用他们的话说, 没有dsg搞不定的迁移, 比goldengate还牛.
https://www.dsgdata.com/
公开课
如果你对PolarDB学习感兴趣可以阅读这个公开课系列:
除了PolarDB还非常值得关注的几款PG栈国产数据库:
HaloDB(基于PG兼容PostgreSQL、Oracle、MySQL. http://www.halodbtech.com/ )、 IvorySQL(基于开源PG兼容PG、Oracle. https://www.ivorysql.org/zh-cn/ )、 ProtonBase(云原生分布式数仓. https://protonbase.com/ )、 成都文武数据库（https://ww-it.cn）
参考文档点击阅读原文获得
感谢关注我的github (https://github.com/digoal/blog) 及视频号: