部署简化：一键安装模式

日志收集：基于Loki实时查阅分析数据库日志

命令行工具：Pigsty CLI，使用Go编写的趁手好用的命令行工具。

Pigsty GUI：提供图形化的配置文件编辑生成功能（Beta）

飞升模式：集成默认PostgreSQL实例，Bootstrap，Datalet

界面改版：适配Grafana 7.5.4新特性，重制若干Dashboard。

易用性优化：一键安装

尽管Pigsty已经在封包，交付流程上进行了大量优化，不少用户仍然反馈安装遇到困难。所以在v0.9中，Pigsty针对安装部署又进行了再次改进。

总而言之，目前只要在装有全新CentOS 7.8的机器上使用root依次执行以下命令，即可完成单节点Pigsty的部署。

# 用免密ssh&sudo的用户执行，标准就是能成功执行: ssh 127.0.0.1 'sudo ls'
/bin/bash -c "$(curl -fsSL https://pigsty.cc/install)" # 下载源码
cd ~/pigsty                                     # 进入源码目录       
make pkg                                        # 下载离线包（可选）
bin/ipconfig   <ip_address>                     # 配置IP地址
make meta                                       # 开始初始化

一键安装可能有些言过其实，但你确实可以把这几行命令粘成一条一键执行……

这里有一个产品思路上的变化，Pigsty将默认的演示环境从4节点改为了单节点。原来的四节点沙箱，能够很好对演示监控系统相关功能，演示集群管理、创建、扩缩容、高可用故障切换等。3个嫌少5个太多4个刚刚好。标准的4节点沙箱至少需要4核6G内存，尽管一台树莓派就够了，但还是有使用门槛：一个是大家的笔记本配置不一定都像我的那么好，不一定能在本机跑起来，再者就是一台虚拟机还是会省事很多。

所以单节点作为Pigsty的默认配置，有助于降低使用试用的门槛。正所谓门槛低一分，用户多十分。最后为了避免跑命令都有人不会，我还特意录了一个教学视频，完整的演示了如何在一台新弄的云虚拟机上部署Pigsty。

B站地址：https://www.bilibili.com/video/BV1nK4y1P7E1

日志收集

监控系统收集的是指标（Metrics），但系统的可观测性还有另一个重要的部分就是日志。日志的重要性无需多提，系统出现问题时，如何最快的看到日志，搜索到关键信息十分重要。

传统上做日志收集分析通常是用ELK全家桶，不巧的是我个人很讨厌Java生态的东西。而且这玩意明显太重了，对于我来说，能以最快的速度在正确的日志上，正确的时间段走grep搜索就足够了。所以我选择了Loki，这个是Grafana官方出品的日志收集组件，它最大的特色就是采用与Promtheus一致的查询语法。

例如在Pigsty v0.9中新增的PG Instance Log Dashboard，就提供了一个简单但无比实用的功能。通过ins选择数据库实例，通过job选择日志类型（postgres|pgbouncer|patroni），然后在搜索框中填入（可选）的关键词。即可完成日志查询。

错误日志会自动按等级区分颜色并高亮搜索关键词。上方的Logs | Error Logs | Search Logs 面板分别显示了指定实例在指定时间段内的（所有，错误，搜索匹配）日志分布直方图。您可以在这里拉选快速定位出现错误（或包含指定关键词）的日志项，在几秒钟精确定位到任意一条错误日志。

此外，我们还可以通过LogQL，采用类似Prometheus的语法定义日志衍生指标。比如每分钟错误日志数就会是一个极其有用的监控报警指标。使用LogQL也可以迅速对日志进行分析，并通过相同的Label与Prometheus中其他的丰富监控指标进行Join。

Loki在设计上就是个大规模并行Grep，尽管没有索引，但是速度还是惊人的快。而且对于日志的压缩比相当高，很省空间。总的来说我相当满意。使用Loki与Promtail收集Postgres相关日志还是比较Tricky的，特别是CSV日志，用正则表达式去解析确实是比较蛋疼的一件事：

^(?P<ts>\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}\.\d{3} \w+),"?(?P<user>[^"]*?)?"?,"?(?P<datname>[^"]*?)?"?,(?P<pid>\d+)?,"?(?P<conn>[^"]+)?"?,(?P<session_id>\w+\.\w+)?,(?P<line_num>\d+)?,"?(?P<cmdtag>[^"]*?)?"?,(?P<session_start>\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2} \w+)?,(?P<vxid>[^"]*?)?,(?P<txid>\d+)?,(?P<level>\w+)?,(?P<code>\w{5})?,.*$

另外值得注意的就是，为了正确收集处理Patroni的日志，Pigsty v0.9针对Patroni的日志时间戳进行了修改，移除了畸形的毫秒时间戳并添加了时区，主要是Python默认的时间戳格式无法被Go标准库正确识别，这是一个我没想到的坑。所以为了收集查阅Patroni日志，Pigsty v0.8之间的用户也许需要重新调整一下Patroni的配置并移除已有Log。

最后 Pigsty v0.9 为了避免系统被垃圾日志淹没，对日志参数进行了精细的优化。特别是把健康检查，监控导致的垃圾信息都消除掉了，真是一件大好事啊。主要是修改了Consul Health Check Method 和 Haproxy的健康检查Method，使用旧版本的同志们重新执行 monitor & service 两个任务即可应用此变更。

命令行工具

Pigsty先前都是通过Ansible Playbook来完成各种部署任务。直接调用Ansible Playbook尽管可以执行非常精细的控制，但也需要对系统有一定的熟悉与了解才行。尽管ansible是个非常简单的傻瓜式部署工具，但它也是有使用门槛的。有没有办法消除这个门槛，让Pigsty用户根本不用知道什么是Ansible？当然也有办法，只要写一个命令行工具，在Ansible的原语外面再包装一层就好了。例如

pigsty infra init            #--> ./infra.yml            # 执行基础设施初始化
pigsty pgsql init -l pg-test #--> ./pgsql.yml -l pg-test # 初始化pg-test集群

当然如果只是一个命令翻译层，就没什么好说的了。Pigsty CLI还提供了很实用的信息查询功能。最后要达到的理想状态就是Pigsty CLI一个二进制往服务器上一丢，然后无论是下载安装，配置ssh sudo，查阅基础设施与数据库集群配置，巡检数据库状态，执行Play，快捷ssh与psql至数据库，SQL发布，备份恢复，所有的东西都做到里面去。

关于Pigsty CLI本身，我一直在犹豫是用Python写还是用Go写。

Python的好处是写起来确实很快，能Hotfix，而且纯文本体积很小，坏处是一堆依赖不太好处理；比如解析yaml需要安装PyYAML，连接PG需要安装psycopg2，跑个webserver还要安装框架，有的包不一定有。

Go的好处是没有任何依赖，但是编译出来十几MB太大了，而且用Go解析YAML真的是一个粪活，Python几十行搞定的功能我要写千把行代码。但没有依赖这个特性确实太香了。我分别写了Go和Python两个版本，但最后还是决定用Go来做这个工具。

说起来Go 1.16有一个很棒的新功能 embed，可以直接把静态资源嵌入到二进制程序中。一个Web程序就是一个清清爽爽的二进制。这也是我使用Go的一个重要原因：开发Pigsty GUI

图形用户界面

Pigsty GUI

Pigsty CLI中还集成了一个Web UI。提供了一个配置文件编辑与跑脚本的API，并嵌入了一个图形界面。只要在Pigsty源码目录中执行 pigsty serve 就会启动它（不过目前还在Beta，且这个GUI开不开源还没定）。就我个人而言，还是比较习惯命令行，但图形界面确实是降低门槛的好东西。比如这个配置编辑的功能就很不错

这个GUI还会调用CLI中封装好的命令，执行各种任务（集群、实例初始化、销毁、扩缩容等），并实时返回日志信息。

也可以查阅先前执行的Job

为了安（tou）全（lan），我把Job做成了Singleton，一次只能通过UI运行一个Job，就是跑一个Playbook。

Pigsty监控系统的UI

此外，Pigsty监控系统的图形界面也有了一些改进。一些Panel改用Grafana新提供的Pie Chart和Time Series重新绘制，一些用户反馈的的Bug也得到了修复。开源版中新增加了非常实用的PG Instance Log Dashboard。同时原有的 PG Service Dashboard 彻底重制，更多的是反映 Haproxy 中对外”暴露“ 的Service以及Proxy的状态，而不再是展现根据人为划分的Role聚合的服务级指标。

新 PG Service Dashboard

原来的Dashboard适配Grafana 7.5.4 后，显示效果有了一些改善。

说句题外话，如果你觉的Demo中监控系统界面太单调，很可能是因为你的实例太少了，Pigsty的UI是针对大规模集群（几百+实例）设计的。如果实例太少，又没什么活动，就会显得空荡荡的。

关于监控系统，等到六月份Grafana 8.0 出来后，可能在界面上会有显著调整。但我现在并不确定这个变更是否应该引入到1.0 GA中。

飞升

默认配置文件中部署在元节点上的数据库集群pg-meta，本来纯粹是一个空的演示数据库。在以前这个数据库实例本身并不属于元节点或基础设施的一部分，纯粹是出于元节点“废物利用”的目的加上的，用来配合pg-test集群测试一些数据库迁移的案例。但是现在我决定让它成为一个必选项而不是可选项，在执行infra初始化的时候一并完成这个pgsql数据库实例的创建。

这样做有两个考量，第一个是正确性验证。作为一个数据库部署方案，如果这套系统可以在元节点上部署基础设施时一并部署一套数据库，那么我们当然对它能在普通数据库节点上成功完成数据库集群部署更有信心。第二个是一个默认可用的PostgreSQL确实可以做非常非常多的事情：例如，自我管理。

CMDB

理想情况下，大规模生产集群应该使用CMDB进行管理。简单的说，就是把 pigsty.yml 文件拆分成一系列的数据库表。然后通过数据库DML来完成配置修改，执行脚本时通过查询来获取最新的配置。

不过这里就是一个先有鸡还是先有蛋的问题。为了使用CMDB管理集群，你先要部署一套DB。而没有CMDB，你就没法（使用基于CMDB的供给方案）部署这套DB。除非说你的CMDB不是Postgres，而是etcd，consul这样的分布式配置存储元数据库。

我确实认真考虑过用Consul或Etcd作为CMDB的可能性，例如，如果后面我想做Kubernetes的Operator，使用ETCD作为CMDB就是很自然的想法，特别是服务注册机制可以实时反馈每个实例每个服务的状态，可以省掉很多开发工作。但从另一方面讲，Pigsty的许多计划中的高级特性又确实需要一个Postgres来承载。所以最后我还是决定使用Postgres本身作为Pigsty的CMDB，即元节点上的那套数据库 pg-meta。这也是为什么我会在 Pigsty v0.9中将 pg-meta 作为基础设施的一部分。

快捷方式make upgrade （实际上是调用bin/upgrade 这个脚本）可以将当前的 pigsty.yml 配置文件解析为meta 数据库中的一系列表。然后将pigsty.yml 本身替换为一个从数据库中查询配置的动态Inventory脚本。这样就完成了一次“飞升”，从配置文件管理升级为CMDB管理。

PostgreSQL非常强大，我编写了一系列存储过程封装了配置文件的增删改查。将Pigsty CMDB功能做成了一个自包含的数据库应用。所以任何后端实现只需要简单的转发这些函数调用即可，甚至有一些现成的应用（PostGraphile，PRest，postgREST）可以直接根据数据库模式生成CRUD API。所以基于数据库的后端CURD实现我就不着急弄了。

这些表将作为Pigsty后续高级特性的基石，它们构成了一个自治应用的核心部分。这个应用也可以作为一个范例，演示一个典型的应用是如何使用Pigsty中的数据库的。

分析

pg-meta的存在不仅仅可以服务于Pigsty自我管理这种简单的应用场景，还可以做的更多。如果梳理一下Pigsty现在的形态就会发现：它现在可以一键拉起一个生产级PostgreSQL实例，同时还有一个Grafana。有了这两个东西，Pigsty变成了什么？它变成了一个开箱即用的数据分析IDE！

分析是数据产业的核心，是数据这种电子石油的炼化厂。SQL基本上是数据分析的事实标准，而PostgreSQL的数据分析功能绝对是所有关系型数据库中最先进的（之一，谦虚一下）。

分析的结果需要呈现，而Grafana提供了快速高效的可视化功能支持。用一个时髦的名词讲，Grafana是一个Low code数据产品开发平台。如果觉得Grafana的可视化功能不够丰富，还可以在Grafana中使用echarts。我之前有一个讲座专门介绍了如何使用这三者配合做出相当实用的数据可视化应用来。

参考视频：使用PostgreSQL Grafana Echarts进行敏捷数据可视化｜ https://www.bilibili.com/video/BV1Gh411o7FG

很多应用（特别是数据分析，内部数据报表展示）其实并不一定需要（数据消费端的）后端 ，Grafana + PostgreSQL可以一条龙式地解决很多此类需求。一个典型的例子就是在Apple时我曾经用两周时间，基于Grafana和PostgreSQL做出了一个与现有Trace系统类似功能的产品，除了界面丑了点，基本覆盖了核心功能，用半个人月实现了几个人年的功能。这背后隐藏的是一种敏捷方法论：抓主要矛盾，找出系统的不可替代点（用数据库写SQL分析，数据库可视化），然后把所有其他杂活全都用现有开源轮子解决掉。

Datalet

Pigsty在某种程度上就是这种方法论的体现，现在你有一个开箱即用的数据库+可视化平台。数据研发人员不需要关心什么前端后端接口，只需要把数据灌入数据库再用SQL查出来，最后在Grafana上画出来。添加一些交互导航，一个五脏俱全的数据应用就出炉了。所以说数据应用的分发是不是就可以浓缩成一个标准化的模式：database schema + grafana dashboards [+ data generator] ？

这里的Story是，也许可以把这种典型数据应用做成一种通用的 “Datalet”，把一个特定的数据功能点做成一个自包含的”数据小应用“，例如手机号身份证查询，漫游轨迹查询，行政区划查询，旅游照片打卡，实时疫情数据等等。而Pigsty则成为这种Datalet的标准Runtime。

上面那些应用其实我都做过，当然Talk is cheap，所以这里特别准备了一个典型Non-Trivial的例子：ISD数据分析案例，便是基于Pigsty开发的。这个应用拉取美国NOAA官方的全球地面气象站观测数据。便是采用的这种结构。任何用户完全可以在Pigsty环境中几分钟完这个应用的部署。

https://github.com/Vonng/isd

另外从某种意义上来说，Pigsty的监控系统也是这样一个典型的数据应用，只不过它的主要数据源是Prometheus而不是Postgres罢了。数据库实例越多，活动越丰富，情况越复杂，数据也就越丰富，就越能展现出Pigsty监控系统的能力来。

绕的太远了，让我重新总结一下，这里的这个功能点之所以叫做”飞升“，就是它 Enable 了一种可能性，让Pigsty不再是一个监控系统，一个管控软件，而且还是一个开箱即用的数据分析集成开发部署环境。尽管目前只有一个自我管理的应用，和一个演示用的气象站查询应用，但这里的Potential是无穷的。

展望未来

Pigsty 1.0 版本大致将于今年6～7月份释出。主要计划的更新包括：

Pigsty CLI 与 GUI 的完善，提供对数据库动态 Inventory的支持
进一步简化安装流程，最好能集成到 Pigsty CLI中。
修改pg_exporter，提供单实例多DB的 DB内对象监控支持，支持PG14（如果需要）。
彻底消除监控系统中的role 与 svc 标签，涉及到不少监控面板的重制，报警规则调整等。
如果可能，基于Grafana 8.0 重新调整监控系统的界面。
以ISD为例，做出几个基于Pigsty的典型 “Datalet”

尽管Pigsty仍然处于早期阶段，但我相信它具有极大的Potential，能成为一个Gaming Changing的东西。因此也需要好好规划思考一下后续的打法。Pigsty以后的发展，大致有三个方向：

做最顶尖最专业的开源PostgreSQL 监控系统
做门槛最低最好用的开源PostgreSQL 供给方案
做开箱即用的数据分析一条龙解决方案

当然我自己精力也有限，怎么加点还是需要审慎考虑的，毕竟一个人运营一个开源项目还是蛮吃力的。

Pigsty从最开始的 Idea （https://github.com/Vonng/pg/tree/master/test）到现在已经快两年了。经过了近两年时间的打磨润色，已经基本成为了成熟的产品。但我一般喜欢做完了再说，所以1.0GA之前不会大张旗鼓的去宣传。但令人欣喜的是，已经有不少用户使用了起来。其中还有一些很给力的用户：互联网公司，部队，银行消费金融……，管理的PostgreSQL集群规模放在全国也绝对是排得上号的。可以说正是正是这些用户们的支持，才让我相信这是 the right thing，真正有动力继续去把这个事情推下去。

Pigsty现已加入阿里云PgSQL七天训练营课程体系

阿里云PgSQL7日训练营，现已提供Pigsty教程。

著： 冯若航（@Vonng） | 2021-01-09

监控系统是智能化管理与自动化运维的基石，可以为资源规划，故障排查，性能优化提供至关重要的数据支持。本课程将以开源PostgreSQL监控解决方案Pigsty为基础，介绍生产级监控系统的部署实施落地详情，以及如何在实际场景中利用监控数据进行系统水位评估，定位系统故障，优化查询性能，做到数据驱动。

PDF下载：《PostgreSQL监控实战——使用Pigsty解决实际问题》

PG Conf China 2020

《生产级PostgreSQL监控系统——Pigsty》@ 2020 PostgreSQL中国技术大会（2021/01/16 广州）

著： 冯若航（@Vonng） | 2021-01-08

在2020 PostgreSQL中国技术大会（2021/01/16 广州），专场七：数据库内核及新特性（下），Pigsty作者冯若航将进行题为《生产级PostgreSQL监控系统—pigsty》的分享。欢迎各位朋友光临

分享内容

PDF下载：《生产级PostgreSQL监控系统——Pigsty》

大会议程

紧急通知

各位赞助商、各位嘉宾、各位伙伴、亲爱的PGer：前天接到南京政府方面的通知，南京《2020 PostgreSQL中国技术大会》活动将会被取消（因为疫情防控）。此次变故肯定会对您的计划产生影响！我们也非常难过和紧张。在这里，深表歉意！！！

经过昨天1天的场地寻找，大会会务组正式决定，大会将继续，只是把大会搬到广州，时间不变（还是1月15号，16号），新的地址是：广州万富希尔顿酒店（广州市白云区云城东路515、517号），由此给您带来的损失，我们愿意协商解决，承担责任。更多详细信息，请联络我们的工作人员。真心希望大家能够继续支持本次大会。

2020数据库嘉年华分享

在2020年数据库嘉年华上，Pigsty作者冯若航分享了如何基于开源组件构建针对大规模生产数据库集群的监控系统。

著： 冯若航（@Vonng） | 2020-11-20

监控系统是管理运维改进的基础，这次分享将介绍自研开源PostgreSQL监控全方位解决方案 —— pigsty。千类指标，几十种面板，覆盖PostgreSQL及其附属组件的方方面面；在不同层次上提供性能洞察：关系、数据库、实例、服务、集群、分片、全局汇总等等。以及如何在实践中使用这套系统。

分享内容

PDF下载：《PostgreSQL监控系统——Pigsty》 PDF下载

PG Conf China 2019

《FDW原理与应用》 2019 PostgreSQL中国技术大会

著： 冯若航（@Vonng） | 2019-11-05

在2019 PostgreSQL中国技术大会（2019/11/16 北京）进行了关于题为《FDW原理与应用》的分享

分享内容

PDF下载：《FDW原理与应用》

Pigsty在线直播：开源PG全家桶上手指南

开源PG全家桶上手指南

PostgreSQL中文社区又开始在线直播啦！本周日（5月23日晚7:30），由我带给大家来一段单口相声 —— 《开源PG全家桶上手指南》。

Pigsty是开源的PostgreSQL一条龙解决方案，主要有以下三个目标：

做最顶尖最专业的开源PostgreSQL 监控系统
做门槛最低最好用的开源PostgreSQL 管控方案
做开箱即用的数据分析可视化集成环境

谁会感兴趣？

PostgreSQL DBA，运维，DevOps：Pigsty提供了一体化的生产级监控系统与部署方案，可以极大提高数据库的管理&使用水平下限。肯定比自己yum install & systemctl start 强大到不知道哪里去了。其监控系统指标覆盖率完爆市面上所有同类产品。

PostgreSQL用户，后端开发者，数据研发工程师，内核研发：Pigsty提供了与生产环境完全一致的本地沙箱，其中包含单节点的默认沙箱与4节点的集群沙箱。用户可以方便地在本地进行开发测试，并通过监控系统获得即时反馈。

对数据分析，数据可视化感兴趣的人：Pigsty提供了本地、单机即可运行，开箱即用的集成数据分析环境：包括分析功能强大的PostgreSQL（内嵌PostGIS，TimeScale地理空间时序数据等扩展），敏捷的数据库可视化平台Grafana，以及内建的Echarts可视化支持。

学生，新手程序员，以及任何有兴趣尝试PostgreSQL数据库的用户。Pigsty上手门槛极低：您只需要有一台虚拟机，或者一台笔记本即可运行。三行命令，一键安装，10分钟搞定。

需要准备什么？

·什么都不需要准备，但如果你想同步来一个实机部署，可以准备好一台CentOS 7.8的新虚拟机。最简单的方式当然是找个云厂商花几块钱买个几天啦。

版本

v0.9.0 发布注记

v0.9极大简化了安装流程，进行了大量日志相关改进，开发了命令行工具（Beta），并修复了一系列问题。

著： 冯若航（@Vonng） | 2021-05-01

新功能

一键安装模式：

/bin/bash -c "$(curl -fsSL https://pigsty.cc/install)"

开发命令行工具 pigsty-cli封装常用Ansible命令，目前pigsty-cli处于Beta状态
使用Loki与Promtail收集日志：
- 默认收集Postgres，Pgbouncer，Patroni日志
- 新增部署脚本infra-loki.yml 与 pgsql-promtail.yml
- 定义基于日志的监控指标
- 使用Grafana制作日志相关可视化面板。
监控组件可以使用二进制安装，使用files/get_bin.sh下载监控二进制组件。
飞升模式：

当集群元节点初始化完成后，可以使用bin/upgrade升级为动态Inventory

使用pg-meta上的数据库代替YAML配置文件。

问题修复

集中修复日志相关问题：
- 修复了HAProxy健康检查造成PG日志中大量 connection reset by peer的问题。
- 修复了HAProxy健康检查造成Patroni日志中大量出现Connect Reset Exception的问题
- 修复了Patroni日志时间戳格式，去除毫秒时间戳，附加完整时区信息。
- 为dbuser_monitor配置1秒的log_min_duration_statement，避免监控查询出现在日志中。
重构Grafana角色
- 在保持API不变的前提下重构Grafana角色。
- 使用CDN下载预打包的Grafana插件，加速插件下载
其他问题修复
- 修复了pgbouncer-create-user 未能正确处理 md5 密码的问题。
- 完善了数据库与用户创建SQL模版中参数空置检查。
- 修复了 NODE DNS配置时如果手工中断执行，DNS配置可能出错的问题。
- 重构了Makefile快捷方式 Makefile 中的错别字

参数变更

node_disable_swap 默认为 False，默认不会关闭SWAP。
node_sysctl_params 不再有默认修改的系统参数。
grafana_plugin 的默认值install 现在意味着当插件缓存不存在时，从CDN下载。
repo_url_packages 现在从 Pigsty CDN 下载额外的RPM包，解决墙内无法访问的问题。
proxy_env.no_proxy现在将Pigsty CDN加入到NOPROXY列表中。
grafana_customize 现在默认为false，启用意味着安装Pigsty Pro版UI（默认不开源所以不要启用）
node_admin_pk_current，新增选项，启用后会将当前用户的~/.ssh/id_rsa.pub添加至管理员的Key中
loki_clean：新增选项，安装Loki时是否清除现有数据
loki_data_dir：新增选项，指明安装Loki时的数据目录
promtail_enabled 是否启用Promtail日志收集服务？
promtail_clean 是否在安装promtail时移除已有状态信息？
promtail_port promtail使用的默认端口，默认为9080
promtail_status_file 保存Promtail状态信息的文件位置
promtail_send_url 用于接收日志的loki服务endpoint

v0.8.0 发布注记

v0.8 重做了服务供给部分，提供了集成外部负载均衡器的扩展接口。

著： 冯若航（@Vonng） | 2021-03-16

v0.8 针对**服务（Service）**接入部分进行了彻底的重做。现在除了默认的primary, replica服务外，用户可以自行定义新的服务。服务的接口可以支持多种不同的实现，例如L4 DPKG VIP可作为Haproxy的替代品与Pigsty集成。同时，针对用户反馈的一些问题进行了集中处理与改进。

改动内容

v0.8是供给方案定稿版本，此后供给系统的API将保持稳定。

API变更

原有vip与haproxy角色的所有配置项，现在迁移至service角色中。

#------------------------------------------------------------------------------
# SERVICE PROVISION
#------------------------------------------------------------------------------
pg_weight: 100              # default load balance weight (instance level)

# - service - #
pg_services:                                  # how to expose postgres service in cluster?
  # primary service will route {ip|name}:5433 to primary pgbouncer (5433->6432 rw)
  - name: primary           # service name {{ pg_cluster }}_primary
    src_ip: "*"
    src_port: 5433
    dst_port: pgbouncer     # 5433 route to pgbouncer
    check_url: /primary     # primary health check, success when instance is primary
    selector: "[]"          # select all instance as primary service candidate

  # replica service will route {ip|name}:5434 to replica pgbouncer (5434->6432 ro)
  - name: replica           # service name {{ pg_cluster }}_replica
    src_ip: "*"
    src_port: 5434
    dst_port: pgbouncer
    check_url: /read-only   # read-only health check. (including primary)
    selector: "[]"          # select all instance as replica service candidate
    selector_backup: "[? pg_role == `primary`]"   # primary are used as backup server in replica service

  # default service will route {ip|name}:5436 to primary postgres (5436->5432 primary)
  - name: default           # service's actual name is {{ pg_cluster }}-{{ service.name }}
    src_ip: "*"             # service bind ip address, * for all, vip for cluster virtual ip address
    src_port: 5436          # bind port, mandatory
    dst_port: postgres      # target port: postgres|pgbouncer|port_number , pgbouncer(6432) by default
    check_method: http      # health check method: only http is available for now
    check_port: patroni     # health check port:  patroni|pg_exporter|port_number , patroni by default
    check_url: /primary     # health check url path, / as default
    check_code: 200         # health check http code, 200 as default
    selector: "[]"          # instance selector
    haproxy:                # haproxy specific fields
      maxconn: 3000         # default front-end connection
      balance: roundrobin   # load balance algorithm (roundrobin by default)
      default_server_options: 'inter 3s fastinter 1s downinter 5s rise 3 fall 3 on-marked-down shutdown-sessions slowstart 30s maxconn 3000 maxqueue 128 weight 100'

  # offline service will route {ip|name}:5438 to offline postgres (5438->5432 offline)
  - name: offline           # service name {{ pg_cluster }}_replica
    src_ip: "*"
    src_port: 5438
    dst_port: postgres
    check_url: /replica     # offline MUST be a replica
    selector: "[? pg_role == `offline` || pg_offline_query ]"         # instances with pg_role == 'offline' or instance marked with 'pg_offline_query == true'
    selector_backup: "[? pg_role == `replica` && !pg_offline_query]"  # replica are used as backup server in offline service

pg_services_extra: []        # extra services to be added

# - haproxy - #
haproxy_enabled: true                         # enable haproxy among every cluster members
haproxy_reload: true                          # reload haproxy after config
haproxy_policy: roundrobin                    # roundrobin, leastconn
haproxy_admin_auth_enabled: false             # enable authentication for haproxy admin?
haproxy_admin_username: admin                 # default haproxy admin username
haproxy_admin_password: admin                 # default haproxy admin password
haproxy_exporter_port: 9101                   # default admin/exporter port
haproxy_client_timeout: 3h                    # client side connection timeout
haproxy_server_timeout: 3h                    # server side connection timeout

# - vip - #
vip_mode: none                                # none | l2 | l4
vip_reload: true                              # whether reload service after config
# vip_address: 127.0.0.1                      # virtual ip address ip (l2 or l4)
# vip_cidrmask: 24                            # virtual ip address cidr mask (l2 only)
# vip_interface: eth0                         # virtual ip network interface (l2 only)

新增选项

# - localization - #
pg_encoding: UTF8                             # default to UTF8
pg_locale: C                                  # default to C
pg_lc_collate: C                              # default to C
pg_lc_ctype: en_US.UTF8                       # default to en_US.UTF8

pg_reload: true                               # reload postgres after hba changes
vip_mode: none                                # none | l2 | l4
vip_reload: true                              # whether reload service after config

移除选项

haproxy_check_port                            # Haproxy相关参数已经被Service定义覆盖
haproxy_primary_port
haproxy_replica_port
haproxy_backend_port
haproxy_weight
haproxy_weight_fallback
vip_enabled                                   # vip_enabled参数被vip_mode覆盖

服务管理

pg_services 与 pg_services_extra 定义了集群中的服务，每一个服务的定义结构如下例所示：

一个服务必须指定以下内容：

名称：服务的完整名称以数据库集群名为前缀，以service.name为后缀，通过-连接。例如在pg-test集群中name=primary的服务，其完整服务名称为pg-test-primary。
端口：在Pigsty中，服务默认采用NodePort的形式对外暴露，因此暴露端口为必选项。但如果使用外部负载均衡服务接入方案，您也可以通过其他的方式区分服务。
选择器：选择器指定了服务的成员，采用JMESPath的形式，从所有集群实例成员中筛选变量。默认的[]选择器会选取所有的集群成员。

此外selector_backup会选择或标记用于backup的实例列表（当集群中所有其他成员失效时方才接管服务）

  # default service will route {ip|name}:5436 to primary postgres (5436->5432 primary)
  - name: default           # service's actual name is {{ pg_cluster }}-{{ service.name }}
    src_ip: "*"             # service bind ip address, * for all, vip for cluster virtual ip address
    src_port: 5436          # bind port, mandatory
    dst_port: postgres      # target port: postgres|pgbouncer|port_number , pgbouncer(6432) by default
    check_method: http      # health check method: only http is available for now
    check_port: patroni     # health check port:  patroni|pg_exporter|port_number , patroni by default
    check_url: /primary     # health check url path, / as default
    check_code: 200         # health check http code, 200 as default
    selector: "[]"          # instance selector
    haproxy:                # haproxy specific fields
      maxconn: 3000         # default front-end connection
      balance: roundrobin   # load balance algorithm (roundrobin by default)
      default_server_options: 'inter 3s fastinter 1s downinter 5s rise 3 fall 3 on-marked-down shutdown-sessions slowstart 30s maxconn 3000 maxqueue 128 weight 100'

数据库管理

数据库现在可以对locale的细分选项：lc_ctype与lc_collate分别进行指定。支持这一功能的主要原因是PG的扩展插件pg_trgm需要在lc_ctype!=C的环境中才能正常支持中文。

旧接口定义

pg_databases:
  - name: meta                      # name is the only required field for a database
    owner: postgres                 # optional, database owner
    template: template1             # optional, template1 by default
    encoding: UTF8                  # optional, UTF8 by default
    locale: C                       # optional, C by default
    allowconn: true                 # optional, true by default, false disable connect at all
    revokeconn: false               # optional, false by default, true revoke connect from public # (only default user and owner have connect privilege on database)
    tablespace: pg_default          # optional, 'pg_default' is the default tablespace
    connlimit: -1                   # optional, connection limit, -1 or none disable limit (default)
    extensions:                     # optional, extension name and where to create
      - {name: postgis, schema: public}
    parameters:                     # optional, extra parameters with ALTER DATABASE
      enable_partitionwise_join: true
    pgbouncer: true                 # optional, add this database to pgbouncer list? true by default
    comment: pigsty meta database   # optional, comment string for database

新的接口定义

pg_databases:
  - name: meta                      # name is the only required field for a database
    # owner: postgres                 # optional, database owner
    # template: template1             # optional, template1 by default
    # encoding: UTF8                # optional, UTF8 by default , must same as template database, leave blank to set to db default
    # locale: C                     # optional, C by default , must same as template database, leave blank to set to db default
    # lc_collate: C                 # optional, C by default , must same as template database, leave blank to set to db default
    # lc_ctype: C                   # optional, C by default , must same as template database, leave blank to set to db default
    allowconn: true                 # optional, true by default, false disable connect at all
    revokeconn: false               # optional, false by default, true revoke connect from public # (only default user and owner have connect privilege on database)
    # tablespace: pg_default          # optional, 'pg_default' is the default tablespace
    connlimit: -1                   # optional, connection limit, -1 or none disable limit (default)
    extensions:                     # optional, extension name and where to create
      - {name: postgis, schema: public}
    parameters:                     # optional, extra parameters with ALTER DATABASE
      enable_partitionwise_join: true
    pgbouncer: true                 # optional, add this database to pgbouncer list? true by default
    comment: pigsty meta database   # optional, comment string for database

v0.7.0 发布注记

v0.7 新增了仅监控部署模式，改进了数据库与用户的供给接口。

著： 冯若航（@Vonng） | 2021-03-01

v0.7 针对接入已有数据库实例进行了改进，现在用户可以采用 仅监控部署（Monly Deployment） 模式使用Pigsty。同时新增了专用于管理数据库与用户、以及单独部署监控的剧本，并对数据库与用户的定义进行改进。

改动内容

Features

Bug Fix

API变更

新增选项

prometheus_sd_target: batch                   # batch|single    监控目标定义文件采用单体还是每个实例一个
exporter_install: none                        # none|yum|binary 监控Exporter的安装模式
exporter_repo_url: ''                         # 如果设置，这里的REPO连接会加入目标的Yum源中
node_exporter_options: '--no-collector.softnet --collector.systemd --collector.ntp --collector.tcpstat --collector.processes'                          # Node Exporter默认的命令行选项
pg_exporter_url: ''                           # 可选，PG Exporter监控对象的URL
pgbouncer_exporter_url: ''                    # 可选，PGBOUNCER EXPORTER监控对象的URL

移除选项

exporter_binary_install: false                 # 功能被 exporter_install 覆盖

定义结构变更

pg_default_roles                               # 变化细节参考 用户管理。
pg_users                                       # 变化细节参考 用户管理。
pg_databases                                   # 变化细节参考 数据库管理。

重命名选项

pg_default_privilegs -> pg_default_privileges # 很明显这是一个错别字

仅监控模式

有时用户不希望使用Pigsty供给方案，只希望使用Pigsty监控系统管理现有PostgreSQL实例。

Pigsty提供了 仅监控部署（monly, monitor-only） 模式，剥离供给方案部分，可用于监控现有PostgreSQL集群。

仅监控模式的部署流程与标准模式大体上保持一致，但省略了很多步骤

在元节点上完成基础设施初始化的部分与标准流程保持一致，仍然通过./infra.yml完成。
不需要在数据库节点上完成 基础设施初始化。
不需要在数据库节点上执行数据库初始化的绝大多数任务，而是通过专用的./pgsql-monitor.yml 完成仅监控系统部署。
实际使用的配置项大大减少，只保留基础设施相关变量，与监控系统相关的少量变量。

数据库管理

Database provisioning interface enhancement #33

旧接口定义

pg_databases:                       # create a business database 'meta'
  - name: meta
    schemas: [meta]                 # create extra schema named 'meta'
    extensions: [{name: postgis}]   # create extra extension postgis
    parameters:                     # overwrite database meta's default search_path
      search_path: public, monitor

新的接口定义

pg_databases:
  - name: meta                      # name is the only required field for a database
    owner: postgres                 # optional, database owner
    template: template1             # optional, template1 by default
    encoding: UTF8                  # optional, UTF8 by default
    locale: C                       # optional, C by default
    allowconn: true                 # optional, true by default, false disable connect at all
    revokeconn: false               # optional, false by default, true revoke connect from public # (only default user and owner have connect privilege on database)
    tablespace: pg_default          # optional, 'pg_default' is the default tablespace
    connlimit: -1                   # optional, connection limit, -1 or none disable limit (default)
    extensions:                     # optional, extension name and where to create
      - {name: postgis, schema: public}
    parameters:                     # optional, extra parameters with ALTER DATABASE
      enable_partitionwise_join: true
    pgbouncer: true                 # optional, add this database to pgbouncer list? true by default
    comment: pigsty meta database   # optional, comment string for database

接口变更

Add new options: template , encoding, locale, allowconn, tablespace, connlimit
Add new option revokeconn, which revoke connect privileges from public for this database
Add comment field for database

数据库变更

在运行中集群中创建新数据库可以使用pgsql-createdb.yml剧本，在配置中定义完新数据库后，执行以下剧本。

./pgsql-createdb.yml -e pg_database=<your_new_database_name>

通过-e pg_datbase=告知需要创建的数据库名称，则该数据库即会被创建（或修改）。具体执行的命令参见集群主库/pg/tmp/pg-db-{{ database.name}}.sql文件。

用户管理

User provisioning interface enhancement #34

旧接口定义

pg_users:
  - username: test                  # example production user have read-write access
    password: test                  # example user's password
    options: LOGIN                  # extra options
    groups: [ dbrole_readwrite ]    # dborole_admin|dbrole_readwrite|dbrole_readonly
    comment: default test user for production usage
    pgbouncer: true                 # add to pgbouncer

新接口定义

pg_users:
  # complete example of user/role definition for production user
  - name: dbuser_meta               # example production user have read-write access
    password: DBUser.Meta           # example user's password, can be encrypted
    login: true                     # can login, true by default (should be false for role)
    superuser: false                # is superuser? false by default
    createdb: false                 # can create database? false by default
    createrole: false               # can create role? false by default
    inherit: true                   # can this role use inherited privileges?
    replication: false              # can this role do replication? false by default
    bypassrls: false                # can this role bypass row level security? false by default
    connlimit: -1                   # connection limit, -1 disable limit
    expire_at: '2030-12-31'         # 'timestamp' when this role is expired
    expire_in: 365                  # now + n days when this role is expired (OVERWRITE expire_at)
    roles: [dbrole_readwrite]       # dborole_admin|dbrole_readwrite|dbrole_readonly
    pgbouncer: true                 # add this user to pgbouncer? false by default (true for production user)
    parameters:                     # user's default search path
      search_path: public
    comment: test user

接口变更

username field rename to name
groups field rename to roles
options now split into separated configration entries:

login, superuser, createdb, createrole, inherit, replication,bypassrls,connlimit
expire_at and expire_in options
pgbouncer option for user is now false by default

用户管理

在运行中集群中创建新数据库可以使用pgsql-createuser.yml剧本，在配置中定义完新数据库后，执行以下剧本。

./pgsql-createuser.yml -e pg_user=<your_new_user_name>

通过-e pg_user=告知需要创建的数据库名称，则该数据库即会被创建（或修改）。具体执行的命令参见集群主库/pg/tmp/pg-user-{{ user.name}}.sql文件。

v0.6.0 发布注记

v0.6 对数据库供给方案进行了大量改进

著： 冯若航（@Vonng） | 2021-02-19

v0.6 对数据库供给方案进行了修改与调整，根据用户的反馈添加了一系列实用功能与修正。针对监控系统的移植性进行优化，便于与其他外部数据库供给方案对接，例如阿里云MyBase。

BUG修复

修复了新版本Patroni重启后会重置PG HBA的问题
修复了PG Overview Dashboard标题中的别字
修复了沙箱集群pg-test的默认主库，原来为pg-test-2，应当为pg-test-1
修复了过时代码注释

功能改进

改造Prometheus与监控供给方式
- 允许在无基础设施的情况下对已有PG集群进行监控部署，便于监控系统与其他供给方案集成。#11
- 基于Inventory渲染所有监控对象的静态列表，用于静态服务发现。#11
- Prometheus添加了静态对象模式，用于替代动态服务发现，集中进行身份管理#11
- 监控Exporter现在添加了service_registry选项，Consul服务注册变为可选项 #13
- Exporter现在可以通过拷贝二进制的方式直接安装：exporter_binary_install，#14
- Exporter现在具有xxx_enabled选项，控制是否启用该组件。
Haproxy供给重构与改进 #8
- 新增了全局HAProxy管理界面导航，默认域名h.pigsty
- 允许将主库加入只读服务集中，当集群中所有从库宕机时自动承接读流量。 #8
- 允许位Haproxy实例管理界面启用认证 haproxy_admin_auth_enabled
- 允许通过配置项调整每个服务对应后端的流量权重. #10
访问控制模型改进。#7
- 添加了默认角色dbrole_offline，用于慢查询，ETL，交互式查询场景。
- 修改默认HBA规则，允许dbrole_offline分组的用户访问pg_role == 'offline'及pg_offline_query == true的实例。
软件更新 Release v0.6
- PostgreSQL 13.2
- Prometheus 2.25
- PG Exporter 0.3.2
- Node Exporter 1.1
- Consul 1.9.3
- 更新默认PG源：PostgreSQL现在默认使用浙江大学的镜像，加速下载安装

接口变更

新增选项

service_registry: consul                      # 服务注册机制：none | consul | etcd | both
prometheus_options: '--storage.tsdb.retention=30d'  # prometheus命令行选项
prometheus_sd_method: consul                  # Prometheus使用的服务发现机制：static|consul
prometheus_sd_interval: 2s                    # Prometheus服务发现刷新间隔
pg_offline_query: false                       # 设置后将允许dbrole_offline角色连接与查询该实例
node_exporter_enabled: true                   # 设置后将安装配置Node Exporter
pg_exporter_enabled: true                     # 设置后将安装配置PG Exporter
pgbouncer_exporter_enabled: true              # 设置后将安装配置Pgbouncer Exporter
dcs_disable_purge: false                      # 双保险，强制 dcs_exists_action = abort 避免误删除DCS实例
pg_disable_purge: false                       # 双保险，强制 pg_exists_action = abort 避免误删除数据库实例
haproxy_weight: 100                           # 配置实例的相对负载均衡权重
haproxy_weight_fallback: 1                    # 配置集群主库在只读服务中的相对权重

移除选项

prometheus_metrics_path                       # 与 exporter_metrics_path 重复
prometheus_retention                          # 功能被 prometheus_options 覆盖

v0.5.0 发布注记

v0.5.0对数据库内部的定制模板进行了大幅改进。

著： 冯若航（@Vonng） | 2020-12-26

大纲

Pigsty官方文档站正式上线！
添加了数据库模板的定制支持，用户可以通过配置文件定制所需的数据库内部对象。
对默认访问控制模型进行了改进
重构了HBA管理的逻辑，现在将由Pigsty替代Patroni直接负责生成HBA
将Grafana监控系统的供给方案从sqlite改为JSON文件静态Provision
将pg-cluster-replication面板加入Pigsty开源免费套餐。
最新的经过测试的离线安装包：pkg.tgz (v0.5)

定制数据库

您是否烦恼过单实例多租户的问题？比如总有研发拿着PostgreSQL当MySQL使，明明是一个Schema就能解决的问题，非要创建一个新的数据库出来，在一个实例中创建出几十个不同的DB。不要忧伤，不要心急。Pigsty已经提供数据库内部对象的Provision方案，您可以轻松地在配置文件中指定所需的数据库内对象，包括：

角色
- 用户/角色名
- 密码
- 用户属性
- 用户备注
- 用户所属的权限组
数据库
- 属主
- 额外的模式
- 额外的扩展插件
- 数据库级的自定义配置参数
数据库
- 属主
- 额外的模式
- 额外的扩展插件
- 数据库级的自定义配置参数
默认权限
- 默认情况下这里配置的权限会应用至所有由超级用户和管理员用户创建的对象上。
默认扩展
- 所有新创建的业务数据库都会安装有这些默认扩展
默认模式
- 所有新创建的业务数据库都会创建有这些默认的模式

配置样例

# 通常是每个DB集群配置的变量
pg_users:
  - username: test
    password: test
    comment: default test user
    groups: [ dbrole_readwrite ]    # dborole_admin|dbrole_readwrite|dbrole_readonly
pg_databases:                       # create a business database 'test'
  - name: test
    extensions: [{name: postgis}]   # create extra extension postgis
    parameters:                     # overwrite database meta's default search_path
      search_path: public,monitor

# 通常是整个环境统一配置的全局变量
# - system roles - #
pg_replication_username: replicator           # system replication user
pg_replication_password: DBUser.Replicator    # system replication password
pg_monitor_username: dbuser_monitor           # system monitor user
pg_monitor_password: DBUser.Monitor           # system monitor password
pg_admin_username: dbuser_admin               # system admin user
pg_admin_password: DBUser.Admin               # system admin password

# - default roles - #
pg_default_roles:
  - username: dbrole_readonly                 # sample user:
    options: NOLOGIN                          # role can not login
    comment: role for readonly access         # comment string

  - username: dbrole_readwrite                # sample user: one object for each user
    options: NOLOGIN
    comment: role for read-write access
    groups: [ dbrole_readonly ]               # read-write includes read-only access

  - username: dbrole_admin                    # sample user: one object for each user
    options: NOLOGIN BYPASSRLS                # admin can bypass row level security
    comment: role for object creation
    groups: [dbrole_readwrite,pg_monitor,pg_signal_backend]

  # NOTE: replicator, monitor, admin password are overwritten by separated config entry
  - username: postgres                        # reset dbsu password to NULL (if dbsu is not postgres)
    options: SUPERUSER LOGIN
    comment: system superuser

  - username: replicator
    options: REPLICATION LOGIN
    groups: [pg_monitor, dbrole_readonly]
    comment: system replicator

  - username: dbuser_monitor
    options: LOGIN CONNECTION LIMIT 10
    comment: system monitor user
    groups: [pg_monitor, dbrole_readonly]

  - username: dbuser_admin
    options: LOGIN BYPASSRLS
    comment: system admin user
    groups: [dbrole_admin]

  - username: dbuser_stats
    password: DBUser.Stats
    options: LOGIN
    comment: business read-only user for statistics
    groups: [dbrole_readonly]


# object created by dbsu and admin will have their privileges properly set
pg_default_privilegs:
  - GRANT USAGE                         ON SCHEMAS   TO dbrole_readonly
  - GRANT SELECT                        ON TABLES    TO dbrole_readonly
  - GRANT SELECT                        ON SEQUENCES TO dbrole_readonly
  - GRANT EXECUTE                       ON FUNCTIONS TO dbrole_readonly
  - GRANT INSERT, UPDATE, DELETE        ON TABLES    TO dbrole_readwrite
  - GRANT USAGE,  UPDATE                ON SEQUENCES TO dbrole_readwrite
  - GRANT TRUNCATE, REFERENCES, TRIGGER ON TABLES    TO dbrole_admin
  - GRANT CREATE                        ON SCHEMAS   TO dbrole_admin
  - GRANT USAGE                         ON TYPES     TO dbrole_admin

# schemas
pg_default_schemas: [monitor]

# extension
pg_default_extensions:
  - { name: 'pg_stat_statements',  schema: 'monitor' }
  - { name: 'pgstattuple',         schema: 'monitor' }
  - { name: 'pg_qualstats',        schema: 'monitor' }
  - { name: 'pg_buffercache',      schema: 'monitor' }
  - { name: 'pageinspect',         schema: 'monitor' }
  - { name: 'pg_prewarm',          schema: 'monitor' }
  - { name: 'pg_visibility',       schema: 'monitor' }
  - { name: 'pg_freespacemap',     schema: 'monitor' }
  - { name: 'pg_repack',           schema: 'monitor' }
  - name: postgres_fdw
  - name: file_fdw
  - name: btree_gist
  - name: btree_gin
  - name: pg_trgm
  - name: intagg
  - name: intarray

# postgres host-based authentication rules
pg_hba_rules:
  - title: allow meta node password access
    role: common
    rules:
      - host    all     all                         10.10.10.10/32      md5

  - title: allow intranet admin password access
    role: common
    rules:
      - host    all     +dbrole_admin               10.0.0.0/8          md5
      - host    all     +dbrole_admin               172.16.0.0/12       md5
      - host    all     +dbrole_admin               192.168.0.0/16      md5

  - title: allow intranet password access
    role: common
    rules:
      - host    all             all                 10.0.0.0/8          md5
      - host    all             all                 172.16.0.0/12       md5
      - host    all             all                 192.168.0.0/16      md5

  - title: allow local read-write access (local production user via pgbouncer)
    role: common
    rules:
      - local   all     +dbrole_readwrite                               md5
      - host    all     +dbrole_readwrite           127.0.0.1/32        md5

  - title: allow read-only user (stats, personal) password directly access
    role: replica
    rules:
      - local   all     +dbrole_readonly                               md5
      - host    all     +dbrole_readonly           127.0.0.1/32        md5
pg_hba_rules_extra: []

# pgbouncer host-based authentication rules
pgbouncer_hba_rules:
  - title: local password access
    role: common
    rules:
      - local  all          all                                     md5
      - host   all          all                     127.0.0.1/32    md5

  - title: intranet password access
    role: common
    rules:
      - host   all          all                     10.0.0.0/8      md5
      - host   all          all                     172.16.0.0/12   md5
      - host   all          all                     192.168.0.0/16  md5
pgbouncer_hba_rules_extra: []

数据库模板

pg-init-template.sql 用于初始化template1数据的脚本模板
pg-init-business.sql 用于初始化其他业务数据库的脚本模板

权限模型

v0.5 改善了默认的权限模型，主要是针对单实例多租户的场景进行优化，并收紧权限控制。

撤回了普通业务用户对非所属数据库的默认CONNECT权限
撤回了非管理员用户对所属数据库的默认CREATE权限
撤回了所有用户在public模式下的默认创建权限。

供给方式

原先Pigsty采用直接拷贝Grafana自带的grafana.db的方式完成监控系统的初始化。这种方式虽然简单粗暴管用，但不适合进行精细化的版本控制管理。在v0.5中，Pigsty采用了Grafana API完成了监控系统面板供给的工作。您所需的就是在grafana_url中填入带有用户名密码的Grafana URL。因此，监控系统可以背方便地添加至已有的Grafana中。

v0.4.0 发布注记

第二个公开测试版v0.4现已正式发行

著： 冯若航（@Vonng） | 2020-12-14

第二个公开测试版v0.4现已正式发行

Pigsty v0.4对监控系统进行了整体升级改造，精心挑选了10个面板作为标准的Pigsty开源内容。同时，针对Grafana 7.3的不兼容升级进行了大量适配改造工作。使用升级的pg_exporter v0.3.1作为默认指标导出器，调整了监控报警规则的监控面板连接。

Pigsty开源版

Pigsty开源版选定了以下10个Dashboard作为开源内容。其他Dashboard作为可选的商业支持内容提供。

PG Overview
PG Cluster
PG Service
PG Instance
PG Database
PG Query
PG Table
PG Table Catalog
PG Table Detail
Node

尽管进行了少量阉割，这10个监控面板所涵盖的内容仍然可以吊打所有同类软件。

软件升级

Pigsty v0.4进行了大量软件适配工作，包括：

Upgrade to PostgreSQL 13.1, Patroni 2.0.1-4, add citus to repo.
Upgrade to pg_exporter 0.3.1
Upgrade to Grafana 7.3, Ton’s of compatibility work
Upgrade to prometheus 2.23, with new UI as default
Upgrade to consul 1.9

其他改进

Update prometheus alert rules
Fix alertmanager info links
Fix bugs and typos.
add a simple backup script

离线安装包

v0.4的离线安装包（CentOS 7.8）已经可以从Github下载：pkg.tgz

v0.3.0 发布注记

v0.3.0 第一个公开的试用版本现已释出！

著： 冯若航（@Vonng） | 2020-10-24

首个Pigsty公开测试版本现在已经释出！

监控系统

Pigsty v0.3 包含以下8个监控面板作为开源内容：

PG Overview
PG Cluster
PG Service
PG Instance
PG Database
PG Table Overview
PG Table Catalog
Node

离线安装包

v0.3 离线安装包（CentOS 7.8）已经可以从Github下载：pkg.tgz

文章

关于PostgreSQL的文章

开箱即用的PG发行版：Pigsty

昨天在PostgreSQL中文社区做了一个直播分享，介绍了开源的PostgreSQL全家桶解决方案 —— Pigsty。

著： 冯若航（@Vonng） | 2021-05-24

什么是Pigsty

Pigsty是开箱即用的生产级开源PostgreSQL发行版。

所谓发行版（Distribution），指的是由数据库内核及其一组软件包组成的数据库整体解决方案。例如，Linux是一个操作系统内核，而RedHat，Debian，SUSE则是基于此内核的操作系统发行版。PostgreSQL是一个数据库内核，而Pigsty，BigSQL，Percona，各种云RDS，换皮数据库则是基于此内核的数据库发行版。

Pigsty区别于其他数据库发行版的五个核心特性为：

全面专业的监控系统
稳定可靠的部署方案
简单省心的用户界面
灵活开放的扩展机制
免费友好的开源协议

这五个特性，使得Pigsty真正成为开箱即用的PostgreSQL发行版。

谁会感兴趣？

Pigsty面向的用户群体包括：DBA，架构师，OPS，软件厂商、云厂商、业务研发、内核研发、数据研发；对数据分析与数据可视化感兴趣的人；学生，新手程序员，有兴趣尝试数据库的用户。

对于DBA，架构师等专业用户，Pigsty提供了独一无二的专业级PostgreSQL监控系统，为数据库管理提供不可替代的价值点。与此同时，Pigsty还带有一个稳定可靠，久经考验的生产级PostgreSQL部署方案，可在生产环境中自动部署带有监控报警，日志采集，服务发现，连接池，负载均衡，VIP，以及高可用的PostgreSQL数据库集群。

对于研发人员（业务研发、内核研发、数据研发），学生，新手程序员，有兴趣尝试数据库的用户，Pigsty提供了门槛极低，一键拉起，一键安装的本地沙箱。本地沙箱除机器规格外与生产环境完全一致，包含完整的功能：带有开箱即用的数据库实例与监控系统。可用于学习，开发，测试，数据分析等场景。

此外，Pigsty提供了一种称为“Datalet”的灵活扩展机制。对数据分析与数据可视化感兴趣的人可能会惊讶地发现，Pigsty还可以作为数据分析与可视化的集成开发环境。Pigsty集成了PostgreSQL与常用的数据分析插件，并带有Grafana和内嵌的Echarts支持，允许用户编写，测试，分发数据小应用（Datalet）。如：“Pigsty监控系统的额外扩展面板包”，“Redis监控系统”，“PG日志分析系统”，“应用监控”，“数据目录浏览器”等。

最后，Pigsty采用了免费友好的Apache License 2.0，可以免费用于商业目的。只要遵守Apache 2 License的显著声明条款，也欢迎云厂商与软件厂商集成与二次研发商用。

全面专业的监控系统

You can’t manage what you don’t measure.

— Peter F.Drucker

Pigsty提供专业级监控系统，面向专业用户提供不可替代的价值点。

以医疗器械类比，普通监控系统类似于心率计、血氧计，普通人无需学习也可以上手。它可以给出患者生命体征核心指标：起码用户可以知道人是不是要死了，但对于看病治病无能为力。例如，各种云厂商软件厂商提供的监控系统大抵属于此类：十几个核心指标，告诉你数据库是不是还活着，让人大致有个数，仅此而已。

专业级监控系统则类似于CT，核磁共振仪，可以检测出对象内部的全部细节，专业的医师可以根据CT/MRI报告快速定位疾病与隐患：有病治病，没病健体。Pigsty可以深入审视每一个数据库中的每一张表，每一个索引，每一个查询，提供巨细无遗的全面指标（1155类），并通过几千个仪表盘将其转换为洞察：将故障扼杀在萌芽状态，并为性能优化提供实时反馈。

Pigsty监控系统基于业内最佳实践，采用Prometheus、Grafana作为监控基础设施。开源开放，定制便利，可复用，可移植，没有厂商锁定。可与各类已有数据库实例集成。

稳定可靠的部署方案

A complex system that works is invariably found to have evolved from a simple system that works.

—John Gall, Systemantics (1975)

数据库是管理数据的软件，管控系统是管理数据库的软件。

Pigsty内置了一套以Ansible为核心的数据库管控方案。并基于此封装了命令行工具与图形界面。它集成了数据库管理中的核心功能：包括数据库集群的创建，销毁，扩缩容；用户、数据库、服务的创建等。Pigsty采纳“Infra as Code”的设计哲学使用了声明式配置，通过大量可选的配置选项对数据库与运行环境进行描述与定制，并通过幂等的预置剧本自动创建所需的数据库集群，提供近似私有云般的使用体验。

Pigsty创建的数据库集群是分布式、高可用的数据库集群。Pigsty创建的数据库基于DCS、Patroni、Haproxy实现了高可用。数据库集群中的每个数据库实例在使用上都是幂等的，任意实例都可以通过内建负载均衡组件提供完整的读写服务，提供分布式数据库的使用体验。数据库集群可以自动进行故障检测与主从切换，普通故障能在几秒到几十秒内自愈，且期间只读流量不受影响。故障时。集群中只要有任意实例存活，就可以对外提供完整的服务。

Pigsty的架构方案经过审慎的设计与评估，着眼于以最小复杂度实现所需功能。该方案经过长时间，大规模的生产环境验证，已经被互联网/B/G/M/F多个行业内的组织所使用。

简单省心的用户界面

Pigsty旨在降低PostgreSQL的使用门槛，因此在易用性上做了大量工作。

安装部署

Someone told me that each equation I included in the book would halve the sales.

— Stephen Hawking

Pigsty的部署分为三步：下载源码，配置环境，执行安装，均可通过一行命令完成。遵循经典的软件安装模式，并提供了配置向导。您需要准备的只是一台CentOS7.8机器及其root权限。管理新节点时，Pigsty基于Ansible通过ssh发起管理，无需安装Agent，即使是新手也可以轻松完成部署。

Pigsty既可以在生产环境中管理成百上千个高规格的生产节点，也可以独立运行于本地1核1GB虚拟机中，作为开箱即用的数据库实例使用。在本地计算机上使用时，Pigsty提供基于Vagrant与Virtualbox的沙箱。可以一键拉起与生产环境一致的数据库环境，用于学习，开发，测试数据分析，数据可视化等场景。

用户接口

Clearly, we must break away from the sequential and not limit the computers. We must state definitions and provide for priorities and descriptions of data. We must state relation‐ ships, not procedures.

—Grace Murray Hopper, Management and the Computer of the Future (1962)

Pigsty吸纳了Kubernetes架构设计中的精髓，采用声明式的配置方式与幂等的操作剧本。用户只需要描述“自己想要什么样的数据库”，而无需关心Pigsty如何去创建它，修改它。Pigsty会根据用户的配置文件清单，在几分钟内从裸机节点上创造出所需的数据库集群。

在管理与使用上，Pigsty提供了不同层次的用户界面，以满足不同用户的需求。新手用户可以使用一键拉起的本地沙箱与图形用户界面，而开发者则可以选择使用pigsty-cli命令行工具与配置文件的方式进行管理。经验丰富的DBA、运维与架构师则可以直接通过Ansible原语对执行的任务进行精细控制。

灵活开放的扩展机制

PostgreSQL的 可扩展性（Extensible） 一直为人所称道，各种各样的扩展插件让PostgreSQL成为了最先进的开源关系型数据库。Pigsty亦尊重这一价值，提供了一种名为“Datalet”的扩展机制，允许用户和开发者对Pigsty进行进一步的定制，将其用到“意想不到”的地方，例如：数据分析与可视化。

当我们拥有监控系统与管控方案后，也就拥有了开箱即用的可视化平台Grafana与功能强大的数据库PostgreSQL。这样的组合拥有强大的威力 —— 特别是对于数据密集型应用而言。用户可以在无需编写前后端代码的情况下，进行数据分析与数据可视化，制作带有丰富交互的数据应用原型，甚至应用本身。

Pigsty集成了Echarts，以及常用地图底图等，可以方便地实现高级可视化需求。比起Julia，Matlab，R这样的传统科学计算语言/绘图库而言，PG + Grafana + Echarts的组合允许您以极低的成本制作出可分享，可交付，标准化的数据应用或可视化作品。

Pigsty监控系统本身就是Datalet的典范：所有Pigsty高级专题监控面板都会以Datalet的方式发布。Pigsty也自带了一些有趣的Datalet案例：Redis监控系统，新冠疫情数据分析，七普人口数据分析，PG日志挖掘等。后续还会添加更多的开箱即用的Datalet，不断扩充Pigsty的功能与应用场景。

免费友好的开源协议

Once open source gets good enough, competing with it would be insane.

Larry Ellison —— Oracle CEO

在软件行业，开源是一种大趋势，互联网的历史就是开源软件的历史，IT行业之所以有今天的繁荣，人们能享受到如此多的免费信息服务，核心原因之一就是开源软件。开源是一种真正成功的，由开发者构成的communism（译成社区主义会更贴切）：软件这种IT业的核心生产资料变为全世界开发者公有，人人为我，我为人人。

一个开源程序员工作时，其劳动背后其实可能蕴含有数以万计的顶尖开发者的智慧结晶。通过开源，所有社区开发者形成合力，极大降低了重复造轮子的内耗。使得整个行业的技术水平以匪夷所思的速度向前迈进。开源的势头就像滚雪球，时至今日已经势不可挡。除了一些特殊场景和路径依赖，软件开发中闭门造车搞自力更生已经成了一个大笑话。

依托开源，回馈开源。Pigsty采用了友好的Apache License 2.0，可以免费用于商业目的。只要遵守Apache 2 License的显著声明条款，也欢迎云厂商与软件厂商集成与二次研发商用。

关于Pigsty

A system cannot be successful if it is too strongly influenced by a single person. Once the initial design is complete and fairly robust, the real test begins as people with many different viewpoints undertake their own experiments. — Donald Knuth

Pigsty围绕开源数据库PostgreSQL而构建，PostgreSQL是世界上最先进的开源关系型数据库，而Pigsty的目标就是：做最好用的开源PostgreSQL发行版。

在最开始时，Pigsty并没有这么宏大的目标。因为在市面上找不到任何满足我自己需求的监控系统，因此我只好自己动手，丰衣足食，给自己做了一个监控系统。没有想到它的效果出乎意料的好，有不少外部组织PG用户希望能用上。紧接着，监控系统的部署与交付成了一个问题，于是又将数据库部署管控的部分加了进去；在生产环境应用后，研发希望能在本地也有用于测试的沙箱环境，于是又有了本地沙箱；有用户反馈ansible不太好用，于是就有了封装命令的pigsty-cli命令行工具；有用户希望可以通过UI编辑配置文件，于是就有了Pigsty GUI。就这样，需求越来越多，功能也越来越丰富，Pigsty也在长时间的打磨中变得更加完善，已经远远超出了最初的预期。

做这件事本身也是一种挑战，做一个发行版有点类似于做一个RedHat，做一个SUSE，做一个“RDS产品”。通常只有一定规模的专业公司与团队才会去尝试。但我就是想试试，一个人可不可以？实际上除了慢一点，也没什么不可以。一个人在产品经理、开发者，终端用户的角色之间转换是很有趣的体验，而“Eat dog food”最大的好处就是，你自己既是开发者也是用户，你了解自己需要什么，也不会在自己的需求上偷懒。

不过，正如高德纳所说：“带有太强个人色彩的系统无法成功”。要想让Pigsty成为一个具有旺盛生命力的项目，就必须开源，让更多的人用起来。“当最初的设计完成并足够稳定后，各式各样的用户以自己的方式去使用它时，真正的挑战才刚刚开始”。

Pigsty很好的解决了我自己的问题与需求，现在我希望它可以帮助到更多的人，并让PostgreSQL的生态更加繁荣，更加多彩。

为什么PostgreSQL前途无量？

PG好处都有啥，我要给它夸一夸，为什么PG是世界上最先进的开源关系型数据库

著： 冯若航（@Vonng） | 2021-05-08

最近做的事儿都围绕着PostgreSQL生态，因为我一直觉得这是一个前途无量的方向。

为什么这么说？因为数据库是信息系统的核心组件，关系型数据库是数据库中的绝对主力，而PostgreSQL是世界上最先进的开源关系型数据库。占据天时地利，何愁大业不成？

做一件事最重要的就是认清形势，时来天地皆同力，运去英雄不自由。

天下大势

今天下三分，然Oracle ｜ MySQL ｜ SQL Server 疲敝，日薄西山。PostgreSQL紧随其后，如日中天。前四的数据库中，前三者都在走下坡路，唯有PG增长势头不减，此消彼长，前途无量。

数据库流行度趋势：https://db-engines.com/en/ranking_trend

（注意这是对数坐标系）

在唯二两个头部开源关系型数据库 MySQL & PgSQL 中，MySQL (2nd) 虽占上风，但其生态位却在逐渐被PostgreSQL (4th) 和非关系型的文档数据库MongoDB (5th) 抢占。按照现在的势头，几年后PostgreSQL的流行度即将跻身前三，与Oracle、MySQL分庭抗礼。

竞争关系

关系型数据库的生态位高度重叠，其关系可以视作零和博弈。与PostgreSQL形成直接竞争关系的，就是Oracle与MySQL。

Oracle流行度位居第一，是老牌商业数据库，有着深厚的历史技术积淀，功能丰富，支持完善。稳坐数据库头把交椅，广受不差钱的企业组织喜爱。但Oracle费用昂贵，且以讼棍行径成为知名的业界毒瘤。排名第三的SQL Server属于相对独立的微软生态，性质上与Oracle类似，都属于商业数据库。商业数据库整体受开源数据库冲击，流行度处于缓慢衰减的状态。

MySQL流行度位居第二，但树大招风，处于前有狼后有虎，上有野爹下有逆子的不利境地：在严谨的事务处理和数据分析上，MySQL被同为开源关系型数据库的PgSQL甩开几条街；而在糙猛快的敏捷方法论上，MySQL又不如新兴NoSQL。同时，MySQL上有养父Oracle的压制，中有MariaDB分家，下有诸如TiDB，OB之类的兼容性新数据库分羹，因而也止步不前。

唯有PostgreSQL迎头赶上，保持着近乎指数增长的势头。如果说几年前PG的势还是Potential，那么现在Potential已经开始兑现为Impact，开始对竞品构成强力挑战。

而在这场你死我活的斗争中，PostgreSQL占据了三个“势”：

开源软件普及发展，蚕食商业软件市场

在去IOE与开源浪潮的大背景下，凭借开源生态对商业软件（Oracle）形成压制。
满足用户日益增长的数据处理功能需求

凭借地理空间数据的事实标准PostGIS处理立于不败之地，凭借对标Oracle的极为丰富的功能，对MySQL形成技术压制。
市场份额均值回归的势

国内PG市场份额因历史原因，远低于世界平均水平，本身蕴含着巨大势能。

Oracle作为老牌商业软件，才毋庸质疑，同时作为业界毒瘤，“德”也不必多说，故曰：“有才无德”。MySQL有开源之功德，但它一来采用了GPL协议，比起使用无私宽松BSD协议的PgSQL还是差不少意思，二来认贼作父，被Oracle收购，三来才疏学浅，功能简陋，故曰“才浅德薄”。

德不配位，必有灾殃。唯有PostgreSQL，既占据了开源崛起之天时，又把握住功能强劲之地利，还有着宽松BSD协议之人和。正所谓：藏器于身，因时而动。不鸣则已，一鸣惊人。德才兼备，攻守之势易矣！

德才兼备

PostgreSQL的德

PG的“德”在于开源。什么叫“德”，合乎于“道”的表现就是德。而这条“道”就是开源。

PG本身就是祖师爷级开源软件，是开源世界中的一颗明珠，是全世界开发者群策群力的成功典范。而且更重要的是它采用无私的BSD协议：除了打着PG的名号招摇撞骗外，基本可以说是百无禁忌：比如换皮改造为国产数据库出售。PG可谓无数数据库厂商们的衣食父母。子孙满堂，活人无数，功德无量。

数据库谱系图，若列出所有PgSQL衍生版，估计可以撑爆这张图

PostgreSQL的才

PG的“才”在于一专多长。PostgreSQL是一专多长的全栈数据库，天生就是HTAP，超融合数据库，一个打十个。基本单一组件便足以覆盖中小型企业绝大多数的数据库需求：OLTP，OLAP，时序数据库，空间GIS，全文检索，JSON/XML，图数据库，缓存，等等等等。

PostgreSQL在一个很可观的规模内都可以独立扮演多面手的角色，一个组件当多种组件使。而单一数据组件选型可以极大地削减项目额外复杂度，这意味着能节省很多成本。它让十个人才能搞定的事，变成一个人就能搞定的事。 如果真有那么一样技术可以满足你所有的需求，那么使用该技术就是最佳选择，而不是试图用多个组件来重新实现它。

参考阅读：PG好处都有啥

开源之德

开源是有大功德的。互联网的历史就是开源软件的历史，IT行业之所以有今天的繁荣，人们能享受到如此多的免费信息服务，核心原因之一就是开源软件。开源是一种真正成功的，由开发者构成的communism（译成社区主义会更贴切）：软件这种IT业的核心生产资料变为全世界开发者公有，人人为我，我为人人。

一个开源程序员干活时，其劳动背后其实可能蕴含有数以万计的顶尖开发者的智慧结晶。互联网程序员贵，因为从效果上来讲，其实程序员不是一个工人，而是一个指挥软件和机器来干活的包工头。程序员自己就是核心生产资料，服务器很容易取得（相比其他行业的科研设备与实验环境），软件来自公有社区，一个或几个高级的软件工程师可以很轻松的利用开源生态快速解决领域问题。

通过开源，所有社区开发者形成合力，极大降低了重复造轮子的内耗。使得整个行业的技术水平以匪夷所思的速度向前迈进。开源的势头就像滚雪球，时至今日已经势不可挡。基本上除了一些特殊场景和路径依赖，软件开发中闭门造车搞自力更生几乎成了一个大笑话。

所以说，搞数据库也好，做软件也罢，要搞技术就要搞开源的技术，闭源的东西生命力太弱，没意思。开源之德，也是PgSQL与MySQL对Oracle的最大底气所在。

生态之争

开源的核心就在于生态（ECO），每一个开源技术都有自己的小生态。所谓生态就是各种主体及其环境通过密集相互作用构成的一个系统，而开源软件的生态模式大致可以描述为由以下三个步骤组成的正反馈循环：

开源软件开发者给开源软件做贡献
开源软件本身免费，吸引更多用户
用户使用开源软件，产生需求，创造更多开源软件相关岗位

开源生态的繁荣有赖于这个闭环，而生态系统的规模（用户/开发者数量）与复杂度（用户/开发者质量）直接决定了这个软件的生命力，所以每一个开源软件都有天命去扩大自己的规模。而软件的规模通常取决于软件所占据的生态位，如果不同的软件的生态位重叠，就会发生竞争。在开源关系型数据库的生态位中，PgSQL与MySQL就是最直接的竞争者。

流行 vs 先进

MySQL的口号是“世界上最流行的开源关系型数据库”，而PostgreSQL的Slogan则是“世界上最先进的开源关系型数据库”，一看这就是一对老冤家了。这两个口号很好的反映出了两种产品的特质：PostgreSQL是功能丰富，一致性优先，高大上的严谨的学院派数据库；MySQL是功能粗陋，可用性优先，糙猛快的“工程派”数据库。

MySQL的主要用户群体集中在互联网公司，互联网公司的典型特点是什么？追逐潮流糙猛快，糙说的是互联网公司业务场景简单（CRUD居多）；数据重要性不高，不像传统行业（例如银行）那样在意数据的一致性（正确性）；可用性优先（相比停服务更能容忍数据丢乱错，而一些传统行业宁可停止服务也不能让账目出错）。猛说的则是互联网行业数据量大，它们需要的就是水泥槽罐车，而不是高铁和载人飞船。快说的则是互联网行业需求变化多端，出活周期短，要求响应时间快，大量需求的就是开箱即用的软件全家桶（如LAMP）和简单培训一下就能干活的CRUD Boy。于是糙猛快的互联网公司和糙猛快的MySQL一拍即合。

而PgSQL的用户则更偏向于传统行业，传统行业之所以称为传统行业，就是因为它们已经走过了野蛮生长的阶段，有着成熟的业务模型与深厚的底蕴积淀。它们需要的是正确的结果，稳定的表现，丰富的功能，对数据进行分析加工提炼的能力。所以在传统行业中，往往是Oracle、SQL Server、PostgreSQL的天下。特别是在地理相关的场景中更是有着不可替代的地位。与此同时，不少互联网公司的业务也开始成熟沉淀，已经一只脚迈入“传统行业”了，越来越多的互联网公司脱离了糙猛快的低级循环，将目光投向PostgreSQL 。

谁更正确？

最了解一个人的的往往是他的竞争对手，PostgreSQL与MySQL的口号都很精准地戳中了对手的痛点。PgSQL“最先进”的潜台词就是MySQL太落后，而MySQL”最流行“就是说PgSQL不流行。用户少但先进，用户多但落后。哪一个更”好“？这种价值判断的问题不好回答。

但我认为时间站在先进技术的一边：因为先进与落后是技术的核心度量，是因，而流行与否则是果；流行不流行是内因（技术是否先进）和外因（历史路径依赖）共同对时间积分的结果。当下的因会反映为未来的果：流行的东西因为落后而过气，而先进的东西会因为先进变得流行。

虽然很多流行的东西都是垃圾，但流行并不一定代表着落后。如果只是缺少一些功能，MySQL还不至于被称为“落后”。问题在于MySQL已经糙到连事务这种关系型数据库的基本功能都有缺陷，那就不是落后不落后能概括的问题，而是合格不合格的问题了。

ACID

一些作者声称，支持通用的两阶段提交代价太大，会带来性能与可用性的问题。让程序员来处理过度使用事务导致的性能问题，总比缺少事务编程好得多。

——James Corbett等，Spanner：Google的全球分布式数据库（2012）

在我看来， MySQL的哲学可以称之为：“好死不如赖活着”，以及，“我死后哪管洪水滔天”。其“可用性”体现在各种“容错”上，例如允许呆瓜程序员写出的错误的SQL查询也能跑起来。最离谱的例子就是MySQL竟然允许部分成功的事务提交，这就违背了关系型数据库的基本约束：原子性与数据一致性。

图：MySQL竟然允许部分成功的事务提交

这里在一个事务中插入了两条记录，第一条成功，第二条因为约束失败。根据事务的原子性，整个事务要么整个成功，要么整个失败（最终一条都没有插入）。结果MySQL的默认表现竟然是允许部分成功的事务提交，也就是事务没有原子性，没有原子性就没有一致性，如果这个事务是一笔转账（先扣再加），因为某些原因失败，那这里的帐就做不平了。这种数据库如果用来记账恐怕是一笔糊涂账，所以说什么“金融级MySQL”恐怕就是一个笑话。

当然，滑稽的是还有一些MySQL用户将其称为“特性”，说这体现了MySQL的容错性。实际上，此类“特殊容错”需求在SQL标准中完全可以通过SAVEPOINT机制实现。PgSQL对此的实现就堪称典范，psql客户端允许通过ON_ERROR_ROLLBACK选项，隐式地在每条语句后创建SAVEPOINT，并在语句失败后自动ROLLBACK TO SAVEPOINT，以标准SQL的方式，以客户端可选项的形式，在不破坏事物ACID的情况下，同样实现这种看上去便利实则苟且的功能。相比之下，MySQL的这种所谓“特性”是以直接在服务端默认牺牲事务ACID为代价的（这意味着用户使用JDBC，psycopg等应用驱动也照样受此影响）。

如果是互联网业务，注册个新用户丢个头像、丢个评论可能不是什么大事。数据那么多，丢几条，错几条又算个什么？别说是数据，业务本身很可能都处于朝不保夕的状态，所以糙又如何？万一成功了，前人拉的屎反正也是后人来擦。所以一些互联网公司通常并不在乎这些。

PostgreSQL所谓“严格的约束与语法“可能对新人来说“不近人情”，例如，一批数据中如果有几条脏数据，MySQL可能会照单全收，而PG则会严格拒绝。尽管苟且妥协看上去很省事，但在其他地方卖下了雷：因为逻辑炸弹深夜加班排查擦屁股的工程师，和不得不天天清洗脏数据的数据分析师肯定对此有很大怨念。从长期看，要想成功，做正确的事最重要。

一个成功的技术，现实的优先级必须高于公关，你可以糊弄别人，但糊弄不了自然规律。

——罗杰斯委员会报告（1986）

MySQL的流行度并没有和PgSQL相差太远，然而其功能比起PostgreSQL和Oracle却是差距不小。Oracle与PostgreSQL算诞生于同一时期，再怎么斗，立场与阵营不同，也有点惺惺相惜的老对手的意思：都是扎实修炼了半个世纪内功，厚积薄发的老法师。而MySQL就像心浮气躁耍刀弄枪的二十来岁毛头小伙子，凭着一把蛮力，借着互联网野蛮生长的黄金二十年趁势而起，占山为王。

时代所赋予的红利，也会随时代过去而退潮。在这个变革的时代中，没有先进的功能打底，“流行”也恐怕也难以长久。

发展前景

从个人职业发展前景的角度看，很多数程序员学习一门技术的原因都是为了提高自己的技术竞争力（从而更好占坑赚钱）。PostgreSQL是各种关系型数据库中性价比最高的选择：它不仅可以用来做传统的CRUD OLTP业务，数据分析更是它的拿手好戏。各种特色功能更是提供了切入多种行业以的契机：基于PostGIS的地理时空数据处理分析，基于Timescale的时序金融物联网数据处理分析，基于Pipeline存储过程触发器的流式处理，基于倒排索引全文检索的搜索引擎，FDW对接统一各式各样的外部数据源。可以说，它是真正一专多长的全栈数据库，用它可以实现的功能要比单纯的OLTP数据库要丰富得多，更是为CRUD码农提供了转型和深入的进阶道路。

从企业用户的角度来看，PostgreSQL在一个很可观的规模内都可以独立扮演多面手的角色，一个组件当多种组件使。而单一数据组件选型可以极大地削减项目额外复杂度，这意味着能节省很多成本。它让十个人才能搞定的事，变成一个人就能搞定的事。 当然这不是说PG要一个打十个把其他数据库的饭碗都掀翻，专业组件在专业领域的实力是毋庸置疑的。但切莫忘记，为了不需要的规模而设计是白费功夫，实际上这属于过早优化的一种形式。如果真有那么一样技术可以满足你所有的需求，那么使用该技术就是最佳选择，而不是试图用多个组件来重新实现它。

以探探为例，在250WTPS与200TB数据的量级下，单一PostgreSQL选型依然能稳如狗地支撑业务。能在很可观的规模内做到一专多长，除了本职的OLTP，Pg还在相当长的时间里兼任了缓存，OLAP，批处理，甚至消息队列的角色。当然神龟虽寿，犹有竟时。最终这些兼职功能还是要逐渐分拆出去由专用组件负责，但那已经是近千万日活时的事了。

从商业生态的角度看，PostgreSQL也有巨大的优势。一来PG技术先进，可称为 “开源版Oracle”。原生的PG基本可以对Oracle的功能做到八九成兼容，EDB更是有96% Oracle兼容的专业PG发行版。因此在抢占去O腾退出的市场中，PostgreSQL及其衍生版本的技术优势是压倒性的。二来PG协议友善，采用了宽松的BSD协议。因此各种数据库厂商，云厂商出品的“自研数据库”，以及很多“云数据库”大体都是基于PgSQL改造的。例如最近HW基于PostgreSQL搞openGaussDB就是一个很明智的选择。不要误会，PG的协议确实允许这样做，而且这样做也确实让PostgreSQL的生态更加繁荣壮大。卖PostgreSQL衍生版是一个很成熟的市场：传统企业不差钱且愿意为此付费买单。开源天才之火有商业利益之油浇灌，因而源源不断地释放出旺盛的生命力。

vs MySQL

作为老对手，MySQL的处境就有些尴尬了。

从个人职业发展上来看，学MySQL主要就是干CRUD。学好增删改查成为一个合格的码农是没问题的，然而谁又愿意一直“数据矿工”的活呢？数据分析才是数据产业链上的暴利肥差。以MySQL孱弱的分析能力，很难支持CURD程序员升级转型发展。此外，PostgreSQL的市场需求摆在那里，但现在却面临供不应求的状况（以至于现在大量良莠不齐的PG培训机构如雨后春笋般冒了出来），MySQL的人确实比PgSQL的人好招，这是不假的。但反过来说MySQL界的内卷程度也要大的多，供不应求方才体现稀缺性，人太多了技能也就贬值了。

从企业用户的角度来看，MySQL就是专用于OLTP的单一功能组件，往往需要ES, Redis, Mongo等其他等等一起配合才能满足完整的数据存储需求，而PG基本就不会有这个问题。此外，MySQL和PgSQL都是开源数据库，都“免费”。免费的Oracle和免费的MySQL用户会选择哪个呢？

从商业生态来看，MySQL面临的最大问题是 叫好不叫座。叫好当然是因为越流行则声音越大，尤其主要的用户互联网企业本身就占据话语权高地。不叫座当然也是因为互联网公司本身对于这类软件付费的意愿是极弱的：怎么算都是养几个MySQL DBA直接用开源的更合算。此外，因为MySQL的GPL协议要求衍生软件也要开源，软件厂商基于MySQL研发的动机也不强，基本都是采用兼容“MySQL” 协议来分MySQL的市场蛋糕，而不是基于MySQL的代码进行开发与回馈，让人对其生态健康程度产生怀疑。

当然MySQL最大的问题就在于：它的生态位越来越狭窄。论严谨的事务处理与数据分析，PostgreSQL甩开它几条街；论糙猛快，快速出原型，NoSQL全家桶又要比MySQL方便太多。论商业发财，上面有Oracle干爹压着；论开源生态，又不断出现MySQL兼容的新生代产品来尝试替代主体。可以说MySQL处在一种吃老本的位置上，只是凭籍历史积分存量维持着现状的地位。时间是否会站在MySQL这一边，我们拭目以待。

vs NewSQL

最近市场上当然也有一些很亮眼的NewSQL产品，例如TiDB，Cockroachdb，Yugabytedb等等。何如？我认为它们都是很好的产品，有一些不错的技术亮点，都是对开源技术的贡献。但是它们可能同样面临叫好不叫座的困局。

NewSQL的大体特征是：主打“分布式”的概念，通过“分布式”解决水平扩展性与容灾高可用两个问题，并因分布式的内在局限性会牺牲许多功能，只能提供较为简单有限的查询支持。分布式数据库在高可用容灾方面与传统主从复制并没有质的区别，因此其特征主要可以概括为“以量换质”。

然而对很多企业而言，牺牲功能换取扩展性很可能是一个伪需求或弱需求。在我接触过的为数不少的用户中，绝大多数场景下的的数据量和负载水平完全落在单机Postgres的处理范围内（目前弄过的记录是单库15TB，单集群40万TPS）。从数据量上来讲，绝大多数企业终其生命周期的数据量也超不过这个瓶颈；至于性能就更不重要了，过早优化是万恶之源，很多企业的DB性能余量足够让他们把所有业务逻辑用存储过程编写然后高高兴兴的跑在数据库里。

NewSQL的祖师爷Google Spanner就是为了解决海量数据扩展性的问题，但又有多少企业能有Google的业务数据量？恐怕还是只有典型的互联网公司，或者某些大企业的部分业务会有这种量级的数据存储需求。所以和MySQL一样，NewSQL的问题就回到了谁来买单这个根本问题上。恐怕到最后只能还是由投资人和国资委来买吧。

但最起码，NewSQL的这种尝试始终是值得赞扬的。

vs 云数据库

“我想直率地说：多年来，我们就像个傻子一样，他们拿着我们开发的东西大赚了一笔”。

—— Ofer Bengal ， Redis Labs 首席执行官

另一个值得关注的“竞争者”是所谓云数据库，包括两种，一种是放在云上托管的开源数据库。例如 RDS for PostgreSQL，另一种是自研的新一代云数据库。

针对前者，主要的问题是“云厂商吸血”。如果云厂商售卖开源软件，实际上会导致就会导致开源软件的相关岗位和利润向云厂商集中，而云厂商是否允许自己的程序员给开源项目做贡献，做多少贡献，其实是很难说的。负责人的大厂通常是会回馈社区，回馈生态的，但这取决于它们的自觉。开源软件还是应当将命运握在自己手中，防止云厂商过分做大形成垄断。相比少量垄断巨头，多数分散的小团体能提供更高的生态多样性，更有利于生态健康发展。

Gartner称2022年75%的数据库将部署至云平台，这个牛逼吹的太大了。（但也有圆的办法，毕竟用一台机器就可以轻松创建几亿个sqlite文件数据库，这算不算？）。因为云计算解决不了一个根本性的问题 —— 信任。实际上在商业活动中，技术牛逼不牛逼是很次要的因素，Trust才是最关键的。数据是很多企业的生命线，云厂商又不是真正的中立第三方，谁能保证数据不会被其偷窥，盗窃，泄漏，甚至直接被卡脖子关停（如各路云厂商锤Parler）？TDE之类的透明加密解决方案也属于鸡肋，充分的恶心了自己，但也防不住真正的有心人。也许要等真正实用的高效全同态加密技术成熟才能解决信任与安全这个问题吧。

另一个根本性的问题在于成本：就目前云厂商的定价策略，云数据库只有在小微规模下有优势。例如一台D740 64核|400G内存|3TB PCI-E SSD的高配机型四年综合成本撑死了十几万块。然而我能找到最大的规格RDS（比这差很多，32核|128GB）一年的价格就这个数了。只要数据量节点数稍微上那么点规模，雇个DBA自建就合算太多了。

云数据库的主要优势还是在于管控，说白了就是用起来方便，点点鼠标。日常运维功能已经覆盖的比较全面，也有一些基础的监控支持。总之下限是摆在那里，如果找不到靠谱的数据库人才，用云数据库起码不至于出太多幺蛾子。不过这些管控软件虽好，基本都是闭源的，而且与供应商深度绑定。

如果你想找一个开源的PostgreSQL监控管控一条龙解决方案，不妨试试Pigsty。

后一种云数据库以AWS Aurora为代表，也包括一系列类似产品如阿里云PolarDB，腾讯云CynosDB。基本都是采用PostgreSQL与MySQL作为Base和协议层，基于云基础设施（共享存储，S3，RDMA）进行定制化，对扩容速度与性能进行了优化。这类产品在技术上肯定是有新颖性和创造性的。但灵魂问题就是，这类产品相比直接使用原生PostgreSQL的收益到底在哪里呢？能看到立竿见影的好处就是集群扩容会快很多（从几小时级到5分钟），不过相比高昂的费用与供应商锁定的问题，实在是挠不到痛点和痒点。

总的来说，云数据库对原生PostgreSQL 构成的威胁是有限的。也不用太担心云厂商的问题，云厂商总的来说还开源软件生态的一份子，对社区和生态是有贡献的。赚钱嘛，不磕碜，大家都有钱赚了，才有余力去搞公益，对不对？

弃暗投明？

通常来说，Oracle的程序员转PostgreSQL不会有什么包袱，因为两者功能类似，大多数经验都是通用的。实际上，很多PostgreSQL生态的成员都是从Oracle阵营转投PG的。例如国内著名的Oracle服务商云和恩墨（由中国第一位Oracle ACE总监盖国强创办），去年就公开宣布“躬身入局”，拥抱PostgreSQL。

也有不少MySQL阵营转投PgSQL的，其实这类用户对两者的区别感受才是最深的：基本上都是一副相见恨晚，弃暗投明的样子。实际上我自己最开始也是先用MySQL😆，能自己选型后就拥抱了PgSQL。不过有些老程序员已经和MySQL形成了深度利益绑定，嚷嚷着MySQL多好多好，还要不忘来碰瓷喷一喷PgSQL（特指某人）。这个其实是可以理解的，触动利益比触动灵魂还难，看到自己擅长的技术日落西山那肯定是愤懑不平😠。毕竟一把年纪投在MySQL上，PostgreSQL🐘再好，让我抛弃我心爱的小海豚🐬，做不到啊。

不过，刚入行的年轻人还是有机会去选择一条更光明的道路的。时间是最公平的裁判，而新生代的选择则是最有代表性的标杆。据我个人观察，在新兴的极有活力的Golang开发者群体中，PostgreSQL的流行程度要显著高于MySQL，不少创业型、创新型的公司现在都选择Go+Pg作为自己的技术栈，例如Instagram，TanTan，Apple都是Go+PG。

我认为这一现象的主要原因就是新生代开发者的崛起，Go之于Java，就像PgSQL之于MySQL。长江后浪推前浪，这其实就是演化的核心机制 —— 新陈代谢。Go和PgSQL慢慢拍扁Java和MySQL，但Go和PgSQL当然也有可能在以后被诸如Rust和某些真正革命性的NewSQL数据库拍扁。但说到底，搞技术还是要搞那些前景光明的，不要去搞那些日暮西山的。（当然下海太早当烈士也不合适）。要去看新生代开发者在用什么，有活力的创业公司、新项目、新团队在用什么，弄这些是没有错的。

PG的问题

当然PgSQL有没有自己的问题？当然也有 —— 流行度。

流行度关乎着着用户规模，信任水平，成熟案例数量，有效需求反馈量，开发者数量等等。尽管按目前的流行度发展趋势，PG将在几年后超过MySQL，所以从长期来看，我觉得这并不是问题。但作为PostgreSQL社区的一员，我觉得很有必要去进一步做一些事情，Secure this success，并加快这一进度。而要想让一样技术更加流行，效果最好的方式就是：降低门槛。

所以，我做了一个开源软件Pigsty，要把PostgreSQL部署、监控、管理、使用的门槛从天花板砸到地板，它有三个核心目标：

做最顶尖最专业的开源PostgreSQL 监控系统（类tidashboard）
做门槛最低最好用的开源PostgreSQL管控方案（类tiup）
做开箱即用的与数据分析&可视化集成开发环境（类minikube）

当然这里细节限于篇幅就不展开了，详情留待下篇分说。

容器化数据库是个好主意吗？

把数据库放入Docker是一个好主意吗？当然是个馊主意！

著： 冯若航（@Vonng） | 2019-01-13

对于无状态的应用服务而言，容器是一个相当完美的开发运维解决方案。然而对于带持久状态的服务 —— 数据库来说，事情就没有那么简单了。生产环境的数据库是否应当放入容器中，仍然是一个充满争议的问题。

站在开发者的角度上，我非常喜欢Docker，并始终相信Docker是未来软件开发部署运维的标准方式，而Kubernetes则是事实上的下一代“操作系统”。但站在DBA的立场上，我认为就目前而言，将生产环境数据库放入Docker中仍然是一个馊主意。

Docker解决什么问题？

让我们先来看一看Docker对自己的描述。

docker-dev

docker-ops

Docker用于形容自己的词汇包括：轻量，标准化，可移植，节约成本，提高效率，自动，集成，高效运维。这些说法并没有问题，Docker在整体意义上确实让开发和运维都变得更容易了。因而可以看到很多公司都热切地希望将自己的软件与服务容器化。但有时候这种热情会走向另一个极端：将一切软件服务都容器化，甚至是生产环境的数据库。

容器最初是针对无状态的应用而设计的，在逻辑上，容器内应用产生的临时数据也属于该容器的一部分。用容器创建起一个服务，用完之后销毁它。这些应用本身没有状态，状态通常保存在容器外部的数据库里，这是经典的架构与用法，也是容器的设计哲学。

但当用户想把数据库本身也放到容器中时，事情就变得不一样了：数据库是有状态的，为了维持这个状态不随容器停止而销毁，数据库容器需要在容器上打一个洞，与底层操作系统上的数据卷相联通。这样的容器，不再是一个能够随意创建，销毁，搬运，转移的对象，而是与底层环境相绑定的对象。因此，传统应用使用容器的诸多优势，对于数据库容器来说都不复存在。

可靠性

让软件跑起来，和让软件可靠地运行是两回事。数据库是信息系统的核心，在绝大多数场景下属于**关键（Critical）**应用，Critical Application可按字面解释，就是出了问题会要命的应用。这与我们的日常经验相符：Word/Excel/PPT这些办公软件如果崩了强制重启即可，没什么大不了的；但正在编辑的文档如果丢了、脏了、乱了，那才是真的灾难。数据库亦然，对于不少公司，特别是互联网公司来说，如果数据库被删了又没有可用备份，基本上可以宣告关门大吉了。

可靠性（Reliability）是数据库最重要的属性。可靠性是系统在困境（adversity）（硬件故障、软件故障、人为错误）中仍可正常工作（正确完成功能，并能达到期望的性能水准）的能力。可靠性意味着容错（fault-tolerant）与韧性（resilient），它是一种安全属性，并不像性能与可维护性那样的活性属性直观可衡量。它只能通过长时间的正常运行来证明，或者某一次故障来否证。很多人往往会在平时忽视安全属性，而在生病后，车祸后，被抢劫后才追悔莫及。安全生产重于泰山，数据库被删，被搅乱，被脱库后再捶胸顿足是没有意义的。

回头再看一看Docker对自己的特性描述中，并没有包含“可靠”这个对于数据库至关重要的属性。

可靠性证明与社区知识

如前所述，可靠性并没有一个很好的衡量方式。只有通过长时间的正确运行，我们才能对一个系统的可靠性逐渐建立信心。在裸机上部署数据库可谓自古以来的实践，通过几十年的持续工作，它很好的证明了自己的可靠性。Docker虽为DevOps带来一场革命，但仅仅五年的历史对于可靠性证明而言仍然是图样图森破。对关乎身家性命的生产数据库而言还远远不够：因为还没有足够的小白鼠去趟雷。

想要提高可靠性，最重要的就是从故障中吸取经验。故障是宝贵的经验财富：它将未知问题变为已知问题，是运维知识的表现形式。社区的故障经验绝大多都基于裸机部署的假设，各式各样的故障在几十年里都已经被人们踩了个遍。如果你遇到一些问题，大概率是别人已经踩过的坑，可以比较方便地处理与解决。同样的故障如果加上一个“Docker”关键字，能找到的有用信息就要少的多。这也意味着当疑难杂症出现时，成功抢救恢复数据的概率要更低，处理紧急故障所需的时间会更长。

微妙的现实是，如果没有特殊理由，企业与个人通常并不愿意分享故障方面的经验。故障有损企业的声誉：可能暴露一些敏感信息，或者是企业与团队的垃圾程度。另一方面，故障经验几乎都是真金白银的损失与学费换来的，是运维人员的核心价值所在，因此有关故障方面的公开资料并不多。

额外失效点

开发关心Feature，而运维关注Bug。相比裸机部署而言，将数据库放入Docker中并不能降低硬件故障，软件错误，人为失误的发生概率。用裸机会有的硬件故障，用Docker一个也不会少。软件缺陷主要是应用Bug，也不会因为采用容器与否而降低，人为失误同理。相反，引入Docker会因为引入了额外的组件，额外的复杂度，额外的失效点，导致系统整体可靠性下降。

举个最简单的例子，dockerd守护进程崩了怎么办，数据库进程就直接歇菜了。尽管这种事情发生的概率并不高，但它们在裸机上压根不会发生。

此外，一个额外组件引入的失效点可能并不止一个：Docker产生的问题并不仅仅是Docker本身的问题。当故障发生时，可能是单纯Docker的问题，或者是Docker与数据库相互作用产生的问题，还可能是Docker与操作系统，编排系统，虚拟机，网络，磁盘相互作用产生的问题。可以参见官方PostgreSQL Docker镜像的Issue列表：https://github.com/docker-library/postgres/issues?q=。

此外，彼之蜜糖，吾之砒霜。某些Docker的Feature，在特定的环境下也可能会变为Bug。

隔离性

Docker提供了进程级别的隔离性，通常来说隔离性对应用来说是个好属性。应用看不见别的进程，自然也不会有很多相互作用导致的问题，进而提高了系统的可靠性。但隔离性对于数据库而言不一定完全是好事。

一个微妙的真实案例是在同一个数据目录上启动两个PostgreSQL实例，或者在宿主机和容器内同时启动了两个数据库实例。在裸机上第二次启动尝试会失败，因为PostgreSQL能意识到另一个实例的存在而拒绝启动；但在使用Docker的情况下因其隔离性，第二个实例无法意识到宿主机或其他数据库容器中的另一个实例。如果没有配置合理的Fencing机制（例如通过宿主机端口互斥，pid文件互斥），两个运行在同一数据目录上的数据库进程能把数据文件搅成一团浆糊。

数据库需不需要隔离性？当然需要，但不是这种隔离性。数据库的性能很重要，因此往往是独占物理机部署。除了数据库进程和必要的工具，不会有其他应用。即使放在容器中，也往往采用独占绑定物理机的模式运行。因此Docker提供的隔离性对于这种数据库部署方案而言并没有什么意义；不过对云数据库厂商来说，这倒真是一个实用的Feature，用来搞多租户超卖妙用无穷。

工具

数据库需要工具来维护，包括各式各样的运维脚本，部署，备份，归档，故障切换，大小版本升级，插件安装，连接池，性能分析，监控，调优，巡检，修复。这些工具，也大多针对裸机部署而设计。这些工具与数据库一样，都需要精心而充分的测试。让一个东西跑起来，与确信这个东西能持久稳定正确的运行，是完全不同的可靠性水准。

一个简单的例子是插件，PostgreSQL提供了很多实用的插件，譬如PostGIS。假如想为数据库安装该插件，在裸机上只要yum install然后create extension postgis两条命令就可以。但如果是在Docker里，按照Docker的实践原则，用户需要在镜像层次进行这个变更，否则下次容器重启时这个扩展就没了。因而需要修改Dockerfile，重新构建新镜像并推送到服务器上，最后重启数据库容器，毫无疑问，要麻烦的多。

再比如说监控，在传统的裸机部署模式下，机器的各项指标是数据库指标的重要组成部分。容器中的监控与裸机上的监控有很多微妙的区别。不注意可能会掉到坑里。例如，CPU各种模式的时长之和，在裸机上始终会是100%，但这样的假设在容器中就不一定总是成立了。再比方说依赖/proc文件系统的监控程序可能在容器中获得与裸机上涵义完全不同的指标。虽然这类问题最终都是可解的（例如把Proc文件系统挂载到容器内），但相比简洁明了的方案，没人喜欢复杂丑陋的work around。

类似的问题包括一些故障检测工具与系统常用命令，虽然理论上可以直接在宿主机上执行，但谁能保证容器里的结果和裸机上的结果有着相同的涵义？更为棘手的是紧急故障处理时，一些需要临时安装使用的工具在容器里没有，外网不通，如果再走Dockerfile→Image→重启这种路径毫无疑问会让人抓狂。

把Docker当成虚拟机来用的话，很多工具大抵上还是可以正常工作的，不过这样就丧失了使用的Docker的大部分意义，不过是把它当成了另一个包管理器用而已。有人觉得Docker通过标准化的部署方式增加了系统的可靠性，因为环境更为标准化更为可控。这一点不能否认。私以为，标准化的部署方式虽然很不错，但如果运维管理数据库的人本身了解如何配置数据库环境，将环境初始化命令写在Shell脚本里和写在Dockerfile里并没有本质上的区别。

可维护性

软件的大部分开销并不在最初的开发阶段，而是在持续的维护阶段，包括修复漏洞、保持系统正常运行、处理故障、版本升级，偿还技术债、添加新的功能等等。可维护性对于运维人员的工作生活质量非常重要。应该说可维护性是Docker最讨喜的地方：Infrastructure as code。可以认为Docker的最大价值就在于它能够把软件的运维经验沉淀成可复用的代码，以一种简便的方式积累起来，而不再是散落在各个角落的install/setup文档。在这一点上Docker做的相当出色，尤其是对于逻辑经常变化的无状态应用而言。Docker和K8s能让用户轻松部署，完成扩容，缩容，发布，滚动升级等工作，让Dev也能干Ops的活，让Ops也能干DBA的活（迫真）。

环境配置

如果说Docker最大的优点是什么，那也许就是环境配置的标准化了。标准化的环境有助于交付变更，交流问题，复现Bug。使用二进制镜像（本质是物化了的Dockerfile安装脚本）相比执行安装脚本而言更为快捷，管理更方便。一些编译复杂，依赖如山的扩展也不用每次都重新构建了，这些都是很爽的特性。

不幸的是，数据库并不像通常的业务应用一样来来去去更新频繁，创建新实例或者交付环境本身是一个极低频的操作。同时DBA们通常都会积累下各种安装配置维护脚本，一键配置环境也并不会比Docker慢多少。因此在环境配置上Docker的优势就没有那么显著了，只能说是Nice to have。当然，在没有专职DBA时，使用Docker镜像可能还是要比自己瞎折腾要好一些，因为起码镜像中多少沉淀了一些运维经验。

通常来说，数据库初始化之后连续运行几个月几年也并不稀奇。占据数据库管理工作主要内容的并不是创建新实例与交付环境，主要还是日常运维的部分。不幸的是在这一点上Docker并没有什么优势，反而会产生一些麻烦。

日常运维

Docker确实能极大地简化来无状态应用的日常维护工作，诸如创建销毁，版本升级，扩容等，但同样的结论能延伸到数据库上吗？

数据库容器不可能像应用容器一样随意销毁创建，重启迁移。因而Docker并不能对数据库的日常运维的体验有什么提升，真正有帮助的倒是诸如ansible之类的工具。而对于日常运维而言，很多操作都需要通过docker exec的方式将脚本透传至容器内执行。底下跑的还是一样的脚本，只不过用docker-exec来执行又额外多了一层包装，这就有点脱裤子放屁的意味了。

此外，很多命令行工具在和Docker配合使用时都相当尴尬。譬如docker exec会将stderr和stdout混在一起，让很多依赖管道的命令无法正常工作。以PostgreSQL为例，在裸机部署模式下，某些日常ETL任务可以用一行bash轻松搞定：

psql <src-url> -c 'COPY tbl TO STDOUT' |\
psql <dst-url> -c 'COPY tdb FROM STDIN'

但如果宿主机上没有合适的客户端二进制程序，那就只能这样用Docker容器中的二进制：

docker exec -it srcpg gosu postgres bash -c "psql -c \"COPY tbl TO STDOUT\" 2>/dev/null" |\ docker exec -i dstpg gosu postgres psql -c 'COPY tbl FROM STDIN;'

当用户想为容器里的数据库做一个物理备份时，原本很简单的一条命令现在需要很多额外的包装：docker套gosu套bash套pg_basebackup：

docker exec -i postgres_pg_1 gosu postgres bash -c 'pg_basebackup -Xf -Ft -c fast -D - 2>/dev/null' | tar -xC /tmp/backup/basebackup

如果说客户端应用psql|pg_basebackup|pg_dump还可以通过在宿主机上安装对应版本的客户端工具来绕开这个问题，那么服务端的应用就真的无解了。总不能在不断升级容器内数据库软件的版本时每次都一并把宿主机上的服务器端二进制版本升级了吧？

另一个Docker喜欢讲的例子是软件版本升级：例如用Docker升级数据库小版本，只要简单地修改Dockerfile里的版本号，重新构建镜像然后重启数据库容器就可以了。没错，至少对于无状态的应用来说这是成立的。但当需要进行数据库原地大版本升级时问题就来了，用户还需要同时修改数据库状态。在裸机上一行bash命令就可以解决的问题，在Docker下可能就会变成这样的东西：https://github.com/tianon/docker-postgres-upgrade。

如果数据库容器不能像AppServer一样随意地调度，快速地扩展，也无法在初始配置，日常运维，以及紧急故障处理时相比普通脚本的方式带来更多便利性，我们又为什么要把生产环境的数据库塞进容器里呢？

Docker和K8s一个很讨喜的地方是很容易进行扩容，至少对于无状态的应用而言是这样：一键拉起起几个新容器，随意调度到哪个节点都无所谓。但数据库不一样，作为一个有状态的应用，数据库并不能像普通AppServer一样随意创建，销毁，水平扩展。譬如，用户创建一个新从库，即使使用容器，也得从主库上重新拉取基础备份。生产环境中动辄几TB的数据库，用万兆网卡也需要个把钟头才能完成，也很可能还是需要人工介入与检查。相比之下，在同样的操作系统初始环境下，运行现成的拉从库脚本与跑docker run在本质上又能有什么区别？毕竟时间都花在拖从库上了。

使用Docker承放生产数据库的一个尴尬之处就在于，数据库是有状态的，而且为了建立这个状态需要额外的工序。通常来说设置一个新PostgreSQL从库的流程是，先通过pg_baseback建立本地的数据目录副本，然后再在本地数据目录上启动postmaster进程。然而容器是和进程绑定的，一旦进程退出容器也随之停止。因此为了在Docker中扩容一个新从库：要么需要先后启动pg_baseback容器拉取数据目录，再在同一个数据卷上启动postgres两个容器；要么需要在创建容器的过程中就指定好复制目标并等待几个小时的复制完成；要么在postgres容器中再使用pg_basebackup偷天换日替换数据目录。无论哪一种方案都是既不优雅也不简洁。因为容器的这种进程隔离抽象，对于数据库这种充满状态的多进程，多任务，多实例协作的应用存在抽象泄漏，它很难优雅地覆盖这些场景。当然有很多折衷的办法可以打补丁来解决这类问题，然而其代价就是大量非本征复杂度，最终受伤的还是系统的可维护性。

总的来说，不可否认Docker对于提高系统整体的可维护性是有帮助的，只不过针对数据库来说这种优势并不显著：容器化的数据库能简化并加速创建新实例或扩容的速度，但也会在日常运维中引入一些麻烦和问题。不过，我相信随着Docker与K8s的进步，这些问题最终都是可以解决克服的。

性能

性能也是人们经常关注的一个维度。从性能的角度来看，数据库的基本部署原则当然是离硬件越近越好，额外的隔离与抽象不利于数据库的性能：越多的隔离意味着越多的开销，即使只是内核栈中的额外拷贝。对于追求性能的场景，一些数据库选择绕开操作系统的页面管理机制直接操作磁盘，而一些数据库甚至会使用FPGA甚至GPU加速查询处理。

实事求是地讲，Docker作为一种轻量化的容器，性能上的折损并不大，这也是Docker相比虚拟机的优势所在。但毫无疑问的是，将数据库放入Docker只会让性能变得更差而不是更好。

总结

容器技术与编排技术对于运维而言是非常有价值的东西，它实际上弥补了从软件到服务之间的空白，其愿景是将运维的经验与能力代码化模块化。容器技术将成为未来的包管理方式，而编排技术将进一步发展为“数据中心分布式集群操作系统”，成为一切软件的底层基础设施Runtime。当越来越多的坑被踩完后，人们可以放心大胆的把一切应用，有状态的还是无状态的都放到容器中去运行。但现在，起码对于数据库而言，还只是一个美好的愿景。

最后需要再次强调的是，以上讨论仅限于生产环境数据库。换句话说，对于开发环境而言，我其实是很支持将数据库放入Docker中的，毕竟不是所有的开发人员都知道怎么配置本地测试数据库环境，使用Docker交付环境显然要比一堆手册简单明了的多。对于生产环境的无状态应用，甚至一些带有衍生状态的不甚重要衍生数据系统（譬如Redis缓存），Docker也是一个不错的选择。但对于生产环境的核心关系型数据库而言，如果里面的数据真的很重要，使用Docker前还望三思：我愿意当小白鼠吗？出了疑难杂症我能Hold住吗？真搞砸了这锅我背的动吗？

任何技术决策都是一个利弊权衡的过程，譬如这里使用Docker的核心权衡可能就是牺牲可靠性换取可维护性。确实有一些场景，数据可靠性并不是那么重要，或者说有其他的考量：譬如对于云计算厂商来说，把数据库放到容器里混部超卖就是一件很好的事情：容器的隔离性，高资源利用率，以及管理上的便利性都与该场景十分契合。这种情况下将数据库放入Docker中也许就是利大于弊的。但对于多数的场景而言，可靠性往往都是优先级最高的的属性，牺牲可靠性换取可维护性通常并不是一个可取的选择。更何况实际很难说运维管理数据库的工作会因为用了Docker而轻松多少：为了安装部署一次性的便利而牺牲长久的日常运维可维护性，并不是一个很好的生意。

综上所述，我认为就目前对于普通用户而言，将生产环境的数据库放入容器中恐怕并不是一个明智的选择。

理解时间:时间时区那些事

著： 冯若航（@Vonng） | 2018-12-11

时间是个很玄妙的东西，看不见也摸不着。我们都能意识到时间的存在，但要给它下个定义，很多人也说不上来。本文当然不是为了探讨哲学问题，但对时间的正确理解，对正确处理工作生活中的时间问题很有帮助（例如，计算机中的时间表示与时间处理，数据库，编程语言中对于时间的处理）。

0x01 秒与计时

时间的单位是秒，但秒的定义并不是一成不变的。它有一个天文学定义，也有一个物理学定义。

世界时（UT1）

在最开始，秒的定义来源于日。秒被定义为平均太阳日的1/86400。而太阳日，则是由天文学现象定义的：两次连续正午时分的间隔被定义为一个太阳日；一天有86400秒，一秒等于86400分之一天，Perfect！以这一标准形成的时间标准，就称为世界时（Univeral Time, UT1），或不严谨的说，格林威治标准时（Greenwich Mean Time, GMT），下面就用GMT来指代它了。这个定义很直观，但有一个问题：它是基于天文学现象的，即地球与太阳的周期性运动。不论是用地球的公转还是自转来定义秒，都有一个很尴尬的地方：虽然地球自转与公转的变化速度很慢，但并不是恒常的，譬如：地球的自转越来越慢，而地月位置也导致了每天的时长其实都不完全相同。这意味着作为物理基本单位的秒，其时长竟然是变化的。在衡量时间段的长短上就比较尴尬，几十年的一秒可能和今天的一秒长度已经不是一回事了。

原子时（TAI）

为了解决这个问题，在1967年之后，秒的定义变成了：铯133原子基态的两个超精细能级间跃迁对应辐射的9,192,631,770个周期的持续时间。秒的定义从天文学定义升级成为了物理学定义，其描述由相对易变的天文现象升级到了更稳定的宇宙中的基本物理事实。现在我们有了真正精准的秒啦：一亿年的偏差也不超过一秒。当然，这么精确的秒除了用来衡量时间间隔，也可以用来计时。从1958-01-01 00:00:00开始作为公共时间原点，国际原子钟开始了计数，每计数9,192,631,770这么多个原子能级跃迁周期就+1s，这个钟走的非常准，每一秒都很均匀。使用这定义的时间称为国际原子时（International Atomic Time, TAI），下文简称TAI。

冲突

在最开始，这两种秒是等价的：一天是86400天文秒，也等于86400物理秒，毕竟物理学这个定义就是特意去凑天文学的定义嘛。所以相应的，GMT也与国际原子时TAI也保持着同步。然而正如前面所说，天文学现象影响因素太多了，并不是真正的“天行有常”。随着地球自转公转速度变化，天文定义的秒要比物理定义的秒稍微长了那么一点点，这也就意味着GMT要比TAI稍微落后一点点。那么哪种定义说了算，世界时还是原子时？如果理论与生活实践经验相违背，绝大多数人都不会选择反直觉的方案：假设一种极端场景，两个钟之间的差异日积月累，到最后出现了几分钟甚至几小时的差值：明明日当午，按GMT应当是12:00:00，但GMT走慢了，TAI显示的时间已经是晚上六点了，这就违背了直觉。在表示时刻这一点上，还是由天文定义说了算，即以GMT为准。当然，就算是天文定义说了算，也要尊重物理规律，毕竟原子钟走的这么准不是？实际上世界时与原子时之间的差值也就在几秒的量级。那么我们会自然而然地想到，使用国际原子时TAI作为基准，但加上一些闰秒（leap second）修正到GMT不就行了？既有高精度，又符合常识。于是就有了新的协调世界时（Coordinated Universal Time, UTC）。

协调世界时（UTC）

UTC是调和GMT与TAI的产物：

UTC使用精确的国际原子时TAI作为计时基础
UTC使用国际时GMT作为修正目标
UTC使用闰秒作为修正手段，

我们通常所说的时间，通常就是指世界协调时间UTC，它与世界时GMT的差值在0.9秒内，在要求不严格的实践中，可以近似认为UTC时间与GMT时间是相同的，很多人也把它与GMT混为一谈。

但问题紧接着就来了，按照传统，一天24小时，一小时60分钟，一分钟60秒，日和秒之间有86400的换算关系。以前用日来定义秒，现在秒成了基本单位，就要用秒去定义日。但现在一天不等于86400秒了。无论用哪头定义哪头，都会顾此失彼。唯一的办法，就是打破这种传统：一分钟不一定只有60秒了，它在需要的时候可以有61秒！这就是闰秒机制，UTC以TAI为基准，因此走的也比GMT快。假设UTC和GMT的差异不断变大，在即将超过一秒时，让UTC中的某一分钟变为61秒，续的这一秒就像UTC在等GMT一样，然后误差就追回来了。每次续一秒时，UTC时间都会落后TAI多一秒，截止至今，UTC已经落后TAI三十多秒了。最近的一次闰秒调整是在2016年跨年：

国际标准时间UTC将在格林尼治时间2016年12月31日23时59分59秒（北京时间2017年1月1日7时59分59秒）之后，在原子时钟实施一个正闰秒，即增加1秒，然后才会跨入新的一年。

所以说，GMT和UTC还是有区别的，UTC里你能看到2016-12-31 23:59:60的时间，但GMT里就不会。

0x02 本地时间与时区

刚才讨论的时间都默认了一个前提：位于本初子午线（0度经线）上的时间。我们还需要考虑地球上的其他地方：毕竟美帝艳阳高照时，中国还在午夜呢。本地时间，顾名思义就是以当地的太阳来计算的时间：正午就是12:00。太阳东升西落，东经120度上的本地时间比起本初子午线上就早了120° / (360°/24) = 8个小时。这意味着在北京当地时间12点整时，UTC时间其实是12-8=4，早晨4:00。大家统一用UTC时间好不好呢？可以当然可以，毕竟中国横跨三个时区，也只用了一个北京时间。只要大家习惯就行。但大家都已经习惯了本地正午算12点了，强迫全世界人民用统一的时间其实违背了历史习惯。时区的设置使得长途旅行者能够简单地知道当地人的作息时间：反正差不多都是朝九晚五上班。这就降低了沟通成本。于是就有了时区的概念。当然像新疆这种硬要用北京时间的结果就是，游客乍一看当地人11点12点才上班可能会有些懵。

但在大一统的国家内部，使用统一的时间也有助于降低沟通成本。假如一个新疆人和一个黑龙江人打电话，一个用的乌鲁木齐时间，一个用的北京时间，那就会鸡同鸭讲。都约着12点，结果实际差了两个小时。时区的选用并不完全是按照地理经度而来的，也有很多的其他因素考量（例如行政区划）。这就引出了时区的概念：时区是地球上使用同一个本地时间定义的区域。时区实际上可以视作从地理区域到时间偏移量的单射。但其实有没有那个地理区域都不重要，关键在于时间偏移量的概念。UTC/GMT时间本身的偏移量为0，时区的偏移量都是相对于UTC时间而言的。这里，本地时间，UTC时间与时区的关系是：

本地时间 = UTC时间 + 本地时区偏移量。

比如UTC、GMT的时区都是+0，意味着没有偏移量。中国所处的东八区偏移量就是+8。意味着计算当地时间时，要在UTC时间的基础上增加8个小时。

夏令时（Daylight Saving Time, DST），可以视为一种特殊的时区偏移修正。指的是在夏天天亮的较早的时候把时间调快一个小时（实际上不一定是一个小时），从而节省能源（灯火）。我国在86年到92年之间曾短暂使用过夏令时。欧盟从1996年开始使用夏令时，不过欧盟最近的民调显示，84%的民众希望取消夏令时。对程序员而言，夏令时也是一个额外的麻烦事，希望它能尽快被扫入历史的垃圾桶。

0x03 时间的表示

那么，时间又如何表示呢？使用TAI的秒数来表示时间当然不会有歧义，但使用不便。习惯上我们将时间分为三个部分：日期，时间，时区，而每个部分都有多种表示方法。对于时间的表示，世界诸国人民各有各的习惯，例如，2006年1月2日，美国人就可能喜欢使用诸如January 2, 1999，1/2/1999这样的日期表示形式，而中国人也许会用诸如“2006年1月2日”，“2006/01/02”这样的表示形式。发送邮件时，首部中的时间则采用RFC2822中规定的Sat, 24 Nov 2035 11:45:15 −0500格式。此外，还有一系列的RFC与标准，用于指定日期与时间的表示格式。

ANSIC       = "Mon Jan _2 15:04:05 2006"
UnixDate    = "Mon Jan _2 15:04:05 MST 2006"
RubyDate    = "Mon Jan 02 15:04:05 -0700 2006"
RFC822      = "02 Jan 06 15:04 MST"
RFC822Z     = "02 Jan 06 15:04 -0700" // RFC822 with numeric zone
RFC850      = "Monday, 02-Jan-06 15:04:05 MST"
RFC1123     = "Mon, 02 Jan 2006 15:04:05 MST"
RFC1123Z    = "Mon, 02 Jan 2006 15:04:05 -0700" // RFC1123 with numeric zone
RFC3339     = "2006-01-02T15:04:05Z07:00"
RFC3339Nano = "2006-01-02T15:04:05.999999999Z07:00"

不过在这里，我们只关注计算机中的日期表示形式与存储方式。而计算机中，时间最经典的表示形式，就是Unix时间戳。

Unix时间戳

比起UTC/GMT，对于程序员来说，更为熟悉的可能是另一种时间：Unix时间戳。UNIX时间戳是从1970年1月1日（UTC/GMT的午夜，在1972年之前没有闰秒）开始所经过的秒数，注意这里的秒其实是GMT中的秒，也就是不计闰秒，毕竟一天等于86400秒已经写死到无数程序的逻辑里去了，想改是不可能改的。使用GMT秒数的好处是，计算日期的时候根本不用考虑闰秒的问题。毕竟闰年已经很讨厌了，再来一个没有规律的闰秒，绝对会让程序员抓狂。当然这不代表就不需要考虑闰秒的问题了，诸如ntp等时间服务还是需要考虑闰秒的问题的，应用程序有可能会受到影响：比如遇到‘时光倒流’拿到两次59秒，或者获取到秒数为60的时间值，一些实现简陋的程序可能就直接崩了。当然，也有一种将闰秒均摊到某一天全天的顺滑手段。 Unix时间戳背后的思想很简单，建立一条时间轴，以某一个纪元点（Epoch）作为原点，将时间表示为距离原点的秒数。Unix时间戳的纪元为GMT时间的1970-01-01 00:00:00，32位系统上的时间戳实际上是一个有符号四字节整型，以秒为单位。这意味它能表示的时间范围为：2^32 / 86400 / 365 = 68年，差不多从1901年到2038年。当然，时间戳并不是只有这一种表示方法，但通常这是最为传统稳妥可靠的做法。毕竟不是所有的程序员都能处理好许多和时区、闰秒相关的微妙错误。使用Unix时间戳的好处就是时区已经固定死了是GMT了，存储空间与某些计算处理（比如排序）也相对容易。在*nix命令行中使用date +%s可以获取Unix时间戳。而date -r @1500000000则可以反向将Unix时间戳转换为其他时间格式，例如转换为2017-07-14 10:40:00可以使用：

date -d @1500000000 '+%Y-%m-%d %H:%M:%S'	# Linux
date -r 1500000000 '+%Y-%m-%d %H:%M:%S'		# MacOS, BSD

在很久以前，当主板上的电池没电之后，系统的时钟就会自动重置成0；还有很多软件的Bug也会导致导致时间戳为0，也就是1970-01-01；以至于这个纪元时间很多非程序员都知道了。

数据库中的时间存储

通常情况下，Unix时间戳是传递/存储时间的最佳方式，它通常在计算机内部以整型的形式存在，内容为距离某个特定纪元的秒数。它极为简单，无歧义，存储占用更紧实，便于比较大小，且在程序员之间存在广泛共识。不过，Epoch+整数偏移量的方式适合在机器上进行存储与交换，但它并不是一种人类可读的格式（也许有些程序员可读）。

PostgreSQL提供了丰富的日期时间数据类型与相关函数，它能以高度灵活的方式自动适配各种格式的时间输入输出，并在内部以高效的整型表示进行存储与计算。在PostgreSQL中，变量CURRENT_TIMESTAMP或函数now()会返回当前事务开始时的本地时间戳，返回的类型是TIMESTAMP WITH TIME ZONE，这是一个PostgreSQL扩展，会在时间戳上带有额外的时区信息。SQL标准所规定的类型为TIMESTAMP，在PostgreSQL中使用8字节的长整型实现。可以使用SQL语法AT TIME ZONE zone或内置函数timezone(zone,ts)将带有时区的TIMESTAMP转换为不带时区的标准版本。

通常（我认为的）最佳实践是，只要应用稍具规模或涉及到任何国际化的功能，存储时间就应当使用TIMESTAMP类型并存储GMT时间，当然，PostgreSQL Wiki中推荐的方式是使用PostgreSQL自己的TimestampTZ扩展类型，带时区的时间戳是12字节，而不带时区的则为8字节，在固定使用GMT时区的情况下，个人还是更倾向于使用不带时区的TIMESTAMP类型。

-- 获取本地事务开始时的时间戳
vonng=# SELECT now(), CURRENT_TIMESTAMP;
              now              |       current_timestamp
-------------------------------+-------------------------------
 2018-12-11 21:50:15.317141+08 | 2018-12-11 21:50:15.317141+08

-- now()/CURRENT_TIMESTAMP返回的是带有时区信息的时间戳
 vonng=# SELECT pg_typeof(now()),pg_typeof(CURRENT_TIMESTAMP);
        pg_typeof         |        pg_typeof
--------------------------+--------------------------
 timestamp with time zone | timestamp with time zone
 

-- 将本地时区+8时间转换为UTC时间，转化得到的是TIMESTAMP
-- 注意不要使用从TIMESTAMPTZ到TIMESTAMP的强制类型转换，会直接截断时区信息。
 vonng=# SELECT now() AT TIME ZONE 'UTC';
          timezone
----------------------------
 2018-12-11 13:50:25.790108

-- 再将UTC时间转换为太平洋时间
vonng=# SELECT (now() AT TIME ZONE 'UTC') AT TIME ZONE 'PST';
           timezone
-------------------------------
 2018-12-12 05:50:37.770066+08
 
 -- 查看PG自带的时区数据表
 vonng=# TABLE pg_timezone_names LIMIT 4;
       name       | abbrev | utc_offset | is_dst
------------------+--------+------------+--------
 Indian/Mauritius | +04    | 04:00:00   | f
 Indian/Chagos    | +06    | 06:00:00   | f
 Indian/Mayotte   | EAT    | 03:00:00   | f
 Indian/Christmas | +07    | 07:00:00   | f
...

-- 查看PG自带的时区缩写
vonng=# TABLE pg_timezone_abbrevs  LIMIT 4;
 abbrev | utc_offset | is_dst
--------+------------+--------
 ACDT   | 10:30:00   | t
 ACSST  | 10:30:00   | t
 ACST   | 09:30:00   | f
 ACT    | -05:00:00  | f
 ...

一个经常让人困惑的问题就是TIMESTAMP与TIMESTAMPTZ之间的相互转化问题。

-- 使用::TIMESTAMP将TIMESTAMPTZ强制转换为TIMESTAMP，直接截断时区部分内容
-- 时间的其余"内容"保持不变
vonng=# SELECT now(), now()::TIMESTAMP;
             now               |           now
-------------------------------+--------------------------
 2018-12-12 05:50:37.770066+08 |  2018-12-12 05:50:37.770066+08

-- 对有时区版TIMESTAMPTZ使用AT TIME ZONE语法
-- 会将其转换为无时区版的TIMESTAMP，返回给定时区下的时间
vonng=# SELECT now(), now() AT TIME ZONE 'UTC';
              now              |          timezone
-------------------------------+----------------------------
 2019-05-23 16:58:47.071135+08 | 2019-05-23 08:58:47.071135
 
 
 -- 对无时区版TIMESTAMP使用AT TIME ZONE语法
-- 会将其转换为带时区版的TIMESTAMPTZ，即在给定时区下解释该无时区时间戳。
vonng=# SELECT now()::TIMESTAMP, now()::TIMESTAMP AT TIME ZONE 'UTC';
            now             |           timezone
----------------------------+-------------------------------
 2019-05-23 17:03:00.872533 | 2019-05-24 01:03:00.872533+08
 
 -- 这里的意思是，UTC时间的 2019-05-23 17:03:00

微信公众号原文

PostgreSQL开发规约

没有规矩，不成方圆。

著： 冯若航（@Vonng） | 2018-06-20

0x00背景

没有规矩，不成方圆。

PostgreSQL的功能非常强大，但是要把PostgreSQL用好，需要后端、运维、DBA的协力配合。

本文针对PostgreSQL数据库原理与特性，整理了一份开发规范，希望可以减少大家在使用PostgreSQL数据库过程中遇到的困惑。你好我也好，大家都好。

0x01 命名规范

无名，万物之始，有名，万物之母。

【强制】 通用命名规则

本规则适用于所有对象名，包括：库名、表名、表名、列名、函数名、视图名、序列号名、别名等。
对象名务必只使用小写字母，下划线，数字，但首字母必须为小写字母，常规表禁止以_打头。
对象名长度不超过63个字符，命名统一采用snake_case。
禁止使用SQL保留字，使用select pg_get_keywords(); 获取保留关键字列表。
禁止出现美元符号，禁止使用中文，不要以pg开头。
提高用词品味，做到信达雅；不要使用拼音，不要使用生僻冷词，不要使用小众缩写。

【强制】 库命名规则

库名最好与应用或服务保持一致，必须为具有高区分度的英文单词。
命名必须以<biz>-开头，<biz>为具体业务线名称，如果是分片库必须以-shard结尾。
多个部分使用-连接。例如：<biz>-chat-shard，<biz>-payment等，总共不超过三段。

【强制】 角色命名规范

数据库su有且仅有一个：postgres，用于流复制的用户命名为replication。
生产用户命名使用<biz>-作为前缀，具体功能作为后缀。
所有数据库默认有三个基础角色： <biz>-read，<biz>-write，<biz>-usage，分别拥有所有表的只读，只写，函数的执行权限。
生产用户，ETL用户，个人用户通过继承相应的基础角色获取权限。
更为精细的权限控制使用独立的角色与用户，依业务而异。

【强制】 模式命名规则

业务统一使用<*>作为模式名，<*>为业务定义的名称，必须设置为search_path首位元素。
dba，monitor，trash为保留模式名。
分片模式命名规则采用：rel_<partition_total_num>_<partition_index>。
无特殊理由不应在其他模式中创建对象。

【推荐】 关系命名规则

关系命名以表意清晰为第一要义，不要使用含混的缩写，也不应过分冗长，遵循通用命名规则。
表名应当使用复数名词，与历史惯例保持一致，但应尽量避免带有不规则复数形式的单词。
视图以v_作为命名前缀，物化视图使用mv_作为命名前缀，临时表以tmp_作为命名前缀。
继承或分区表应当以父表表名作为前缀，并以子表特性（规则，分片范围等）作为后缀。

【推荐】 索引命名规则

创建索引时如有条件应当指定索引名称，并与PostgreSQL默认命名规则保持一致，避免重复执行时建立重复索引。
用于主键的索引以_pkey结尾，唯一索引以_key结尾，用于EXCLUDED约束的索引以_excl结尾，普通索引以_idx结尾。

【推荐】 函数命名规则

以select,insert,delete,update,upsert打头，表示动作类型。
重要参数可以通过_by_ids, _by_user_ids的后缀在函数名中体现。
避免函数重载，同名函数尽量只保留一个。
禁止通过BIGINT/INTEGER/SMALLINT等整型进行重载，调用时可能产生歧义。

【推荐】 字段命名规则

不得使用系统列保留字段名：oid, xmin, xmax,cmin, cmax, ctid等。
主键列通常命名为id，或以id作为后缀。
创建时间通常命名为created_time，修改时间通常命名为updated_time
布尔型字段建议使用is_，has_等作为前缀。
其余各字段名需与已有表命名惯例保持一致。

【推荐】 变量命名规则

存储过程与函数中的变量使用命名参数，而非位置参数。
如果参数名与对象名出现冲突，在参数后添加_，例如user_id_。

【推荐】 注释规范

尽量为对象提供注释（COMMENT），注释使用英文，言简意赅，一行为宜。
对象的模式或内容语义发生变更时，务必一并更新注释，与实际情况保持同步。

0x02 设计规范

Suum cuique

【强制】 字符编码必须为UTF8

禁止使用其他任何字符编码。

【强制】 容量规划

单表记录过亿，或超过10GB的量级，可以考虑开始进行分表。
单表容量超过1T，单库容量超过2T。需要考虑分片。

【强制】 不要滥用存储过程

存储过程适用于封装事务，减少并发冲突，减少网络往返，减少返回数据量，执行少量自定义逻辑。
存储过程不适合进行复杂计算，不适合进行平凡/频繁的类型转换与包装。

【强制】 存储计算分离

移除数据库中不必要的计算密集型逻辑，例如在数据库中使用SQL进行WGS84到其他坐标系的换算。
例外：与数据获取、筛选密切关联的计算逻辑允许在数据库中进行，如PostGIS中的几何关系判断。

【强制】 主键与身份列

每个表都必须有身份列，原则上必须有主键，最低要求为拥有非空唯一约束。
身份列用于唯一标识表中的任一元组，逻辑复制与诸多三方工具有赖于此。

【强制】外键

不建议使用外键，建议在应用层解决。使用外键时，引用必须设置相应的动作：SET NULL, SET DEFAULT, CASCADE，慎用级联操作。

【强制】 慎用宽表

字段数目超过15个的表视作宽表，宽表应当考虑进行纵向拆分，通过相同的主键与主表相互引用。
因为MVCC机制，宽表的写放大现象比较明显，尽量减少对宽表的频繁更新。

【强制】 配置合适的默认值

有默认值的列必须添加DEFAULT子句指定默认值。
可以在默认值中使用函数，动态生成默认值（例如主键发号器）。

【强制】 合理应对空值

字段语义上没有零值与空值区分的，不允许空值存在，须为列配置NOT NULL约束。

【强制】 唯一约束通过数据库强制。

唯一约束须由数据库保证，任何唯一列须有唯一约束。
EXCLUDE约束是泛化的唯一约束，可以在低频更新场景下用于保证数据完整性。

【强制】 注意整数溢出风险

注意SQL标准不提供无符号整型，超过INTMAX但没超过UINTMAX的值需要升格存储。
不要存储超过INT64MAX的值到BIGINT列中，会溢出为负数。

【强制】 统一时区

使用TIMESTAMP存储时间，采用utc时区。
统一使用ISO-8601格式输入输出时间类型：2006-01-02 15:04:05，避免DMY与MDY问题。
使用TIMESTAMPTZ时，采用GMT/UTC时间，0时区标准时。

【强制】 及时清理过时函数

不再使用的，被替换的函数应当及时下线，避免与未来的函数发生冲突。

【推荐】 主键类型

主键通常使用整型，建议使用BIGINT，允许使用不超过64字节的字符串。
主键允许使用Serial自动生成，建议使用Default next_id()发号器函数。

【推荐】 选择合适的类型

能使用专有类型的，不使用字符串。（数值，枚举，网络地址，货币，JSON，UUID等）
使用正确的数据类型，能显著提高数据存储，查询，索引，计算的效率，并提高可维护性。

【推荐】 使用枚举类型

较稳定的，取值空间较小（十几个内）的字段应当使用枚举类型，不要使用整型与字符串表示。
使用枚举类型有性能、存储、可维护性上的优势。

【推荐】 选择合适的文本类型

PostgreSQL的文本类型包括 char(n), varchar(n), text。
通常建议使用varchar或text，带有(n)修饰符的类型会检查字符串长度，会导致微小的额外开销，对字符串长度有限制时应当使用varchar(n)，避免插入过长的脏数据。
避免使用char(n)，为了与SQL标准兼容，该类型存在不合直觉的行为表现（补齐空格与截断），且并没有存储和性能优势。

【推荐】 选择合适的数值类型

常规数值字段使用INTEGER。主键、容量拿不准的数值列使用BIGINT。
无特殊理由不要用SMALLINT，性能与存储提升很小，会有很多额外的问题。
REAL表示4字节浮点数，FLOAT表示8字节浮点数
浮点数仅可用于末尾精度无所谓的场景，例如地理坐标，不要对浮点数使用等值判断。
精确数值类型使用NUMERIC，注意精度和小数位数设置。
货币数值类型使用MONEY。

【推荐】 使用统一的函数创建语法

签名单独占用一行（函数名与参数），返回值单启一行，语言为第一个标签。
一定要标注函数易变性等级：IMMUTABLE, STABLE, VOLATILE。
添加确定的属性标签，如：RETURNS NULL ON NULL INPUT,PARALLEL SAFE,ROWS 1，注意版本兼容性。

CREATE OR REPLACE FUNCTION
  nspname.myfunc(arg1_ TEXT, arg2_ INTEGER)
  RETURNS VOID
LANGUAGE SQL
STABLE
PARALLEL SAFE
ROWS 1
RETURNS NULL ON NULL INPUT
AS $function$
SELECT 1;
$function$;

【推荐】 针对可演化性而设计

在设计表时，应当充分考虑未来的扩展需求，可以在建表时适当添加1~3个保留字段。
对于多变的非关键字段可以使用JSON类型。

【推荐】 选择合理的规范化等级

允许适当降低规范化等级，减少多表连接以提高性能。

【推荐】 使用新版本

新版本有无成本的性能提升，稳定性提升，有更多新功能。
充分利用新特性，降低设计复杂度。

【推荐】 慎用触发器

触发器会提高系统的复杂度与维护成本，不鼓励使用。

0x03 索引规范

Wer Ordnung hält, ist nur zu faul zum Suchen.

【强制】 在线查询必须有配套索引

所有在线查询必须针对其访问模式设计相应索引，除极个别小表外不允许全表扫描。
索引有代价，不允许创建不使用的索引。

【强制】 禁止在大字段上建立索引

被索引字段大小无法超过2KB（1/3的页容量），原则上禁止超过64个字符。
如有大字段索引需求，可以考虑对大字段取哈希，并建立函数索引。或使用其他类型的索引（GIN）。

【强制】 明确空值排序规则

如在可空列上有排序需求，需要在查询与索引中明确指定NULLS FIRST还是NULLS LAST。
注意，DESC排序的默认规则是NULLS FIRST，即空值会出现在排序的最前面，通常这不是期望行为。
索引的排序条件必须与查询匹配，如：create index on tbl (id desc nulls last);

【强制】 利用GiST索引应对近邻查询问题

传统B树索引无法提供对KNN问题的良好支持，应当使用GiST索引。

【推荐】 利用函数索引

任何可以由同一行其他字段推断得出的冗余字段，可以使用函数索引替代。
对于经常使用表达式作为查询条件的语句，可以使用表达式或函数索引加速查询。
典型场景：建立大字段上的哈希函数索引，为需要左模糊查询的文本列建立reverse函数索引。

【推荐】 利用部分索引

查询中查询条件固定的部分，可以使用部分索引，减小索引大小并提升查询效率。
查询中某待索引字段若只有有限几种取值，也可以建立几个相应的部分索引。

【推荐】 利用范围索引

对于值与堆表的存储顺序线性相关的数据，如果通常的查询为范围查询，建议使用BRIN索引。
最典型场景如仅追加写入的时序数据，BRIN索引更为高效。

【推荐】 关注联合索引的区分度

区分度高的列放在前面

0x04 查询规范

The limits of my language mean the limits of my world.

—Ludwig Wittgenstein

【强制】 读写分离

原则上写请求走主库，读请求走从库。
例外：需要读己之写的一致性保证，且检测到显著的复制延迟。

【强制】 快慢分离

生产中1毫秒以内的查询称为快查询，生产中超过1秒的查询称为慢查询。
慢查询必须走离线从库，必须设置相应的超时。
生产中的在线普通查询执行时长，原则上应当控制在1ms内。
生产中的在线普通查询执行时长，超过10ms需修改技术方案，优化达标后再上线。
在线查询应当配置10ms数量级或更快的超时，避免堆积造成雪崩。
Master与Slave角色不允许大批量拉取数据，数仓ETL程序应当从Offline从库拉取数据

【强制】 主动超时

为所有的语句配置主动超时，超时后主动取消请求，避免雪崩。
周期性执行的语句，必须配置小于执行周期的超时。

【强制】 关注复制延迟

应用必须意识到主从之间的同步延迟，并妥善处理好复制延迟超出合理范围的情况
平时在0.1ms的延迟，在极端情况下可能达到十几分钟甚至小时量级。应用可以选择从主库读取，稍后再度，或报错。

【强制】 使用连接池

应用必须通过连接池访问数据库，连接6432端口的pgbouncer而不是5432的postgres。
注意使用连接池与直连数据库的区别，一些功能可能无法使用（比如Notify/Listen），也可能存在连接污染的问题。

【强制】 禁止修改连接状态

使用公共连接池时禁止修改连接状态，包括修改连接参数，修改搜索路径，更换角色，更换数据库。
万不得已修改后必须彻底销毁连接，将状态变更后的连接放回连接池会导致污染扩散。

【强制】 重试失败的事务

查询可能因为并发争用，管理员命令等原因被杀死，应用需要意识到这一点并在必要时重试。
应用在数据库大量报错时可以触发断路器熔断，避免雪崩。但要注意区分错误的类型与性质。

【强制】 掉线重连

连接可能因为各种原因被中止，应用必须有掉线重连机制。
可以使用SELECT 1作为心跳包查询，检测连接的有消息，并定期保活。

【强制】 在线服务应用代码禁止执行DDL

不要在应用代码里搞大新闻。

【强制】 显式指定列名

避免使用SELECT *，或在RETURNING子句中使用*。请使用具体的字段列表，不要返回用不到的字段。当表结构发生变动时（例如，新值列），使用列通配符的查询很可能会发生列数不匹配的错误。
例外：当存储过程返回具体的表行类型时，允许使用通配符。

【强制】 禁止在线查询全表扫描

例外情况：常量极小表，极低频操作，表/返回结果集很小（百条记录/百KB内）。
在首层过滤条件上使用诸如!=, <>的否定式操作符会导致全表扫描，必须避免。

【强制】 禁止在事务中长时间等待

开启事务后必须尽快提交或回滚，超过10分钟的IDEL IN Transaction将被强制杀死。
应用应当开启AutoCommit，避免BEGIN之后没有配对的ROLLBACK或COMMIT。
尽量使用标准库提供的事务基础设施，不到万不得已不要手动控制事务。

【强制】 使用游标后必须及时关闭

【强制】 科学计数

count(*)是统计行数的标准语法，与空值无关。
count(col)统计的是col列中的非空记录数。该列中的NULL值不会被计入。
count(distinct col) 对col列除重计数，同样忽视空值，即只统计非空不同值的个数。
count((col1, col2))对多列计数，即使待计数的列全为空也会被计数，(NULL,NULL)有效。
a(distinct (col1, col2))对多列除重计数，即使待计数列全为空也会被计数，(NULL,NULL)有效。

【强制】 注意聚合函数的空值问题

除了count之外的所有聚合函数都会忽略空值输入，因此当输入值全部为空时，结果是NULL。但count(col)在这种情况下会返回0，是一个例外。
如果聚集函数返回空并不是期望的结果，使用coalesce来设置缺省值。

【强制】谨慎处理空值

明确区分零值与空值，空值使用IS NULL进行等值判断，零值使用常规的=运算符进行等值判断。
空值作为函数输入参数时应当带有类型修饰符，否则对于有重载的函数将无法识别使用何者。
注意空值比较逻辑：任何涉及到空值比较运算结果都是unknown，需要注意unknown参与布尔运算的逻辑：
- and：TRUE or UNKNOWN会因为逻辑短路返回TRUE。
- or：FALSE and UNKNOWN会因为逻辑短路返回FALSE
- 其他情况只要运算对象出现UNKNOWN，结果都是UNKNOWN
空值与任何值的逻辑判断，其结果都为空值，例如NULL=NULL返回结果是NULL而不是TRUE/FALSE。
涉及空值与非空值的等值比较，请使用``IS DISTINCT FROM 进行比较，保证比较结果非空。
空值与聚合函数：聚合函数当输入值全部为NULL时，返回结果为NULL。

【强制】 注意序列号空缺

当使用Serial类型时，INSERT，UPSERT等操作都会消耗序列号，该消耗不会随事务失败而回滚。
当使用整型作为主键，且表存在频繁插入冲突时，需要关注整型溢出的问题。

【推荐】 重复查询使用准备语句

重复的查询应当使用准备语句（Prepared Statement），消除数据库硬解析的CPU开销。
准备语句会修改连接状态，请注意连接池对于准备语句的影响。

【推荐】 选择合适的事务隔离等级

默认隔离等级为读已提交，适合大多数简单读写事务，普通事务选择满足需求的最低隔离等级。
需要事务级一致性快照的写事务，请使用可重复读隔离等级。
对正确性有严格要求的写入事务请使用可序列化隔离等级。
在RR与SR隔离等级出现并发冲突时，应当视错误类型进行积极的重试。

【推荐】 判断结果存在性不要使用count

使用SELECT 1 FROM tbl WHERE xxx LIMIT 1判断是否存满足条件的列，要比Count快。
可以使用select exists(select * FROM app.sjqq where xxx limit 1)将存在性结果转换为布尔值。

【推荐】 使用RETURNING子句

如果用户需要在插入数据和，删除数据前，或者修改数据后马上拿到插入或被删除或修改后的数据，建议使用RETURNING子句，减少数据库交互次数。

【推荐】 使用UPSERT简化逻辑

当业务出现插入-失败-更新的操作序列时，考虑使用UPSERT替代。

【推荐】 利用咨询锁应对热点并发。

针对单行记录的极高频并发写入（秒杀），应当使用咨询锁对记录ID进行锁定。
如果能在应用层次解决高并发争用，就不要放在数据库层面进行。

【推荐】优化IN操作符

使用EXISTS子句代替IN操作符，效果更佳。
使用=ANY(ARRAY[1,2,3,4])代替IN (1,2,3,4)，效果更佳。

【推荐】 不建议使用左模糊搜索

左模糊搜索WHERE col LIKE '%xxx'无法充分利用B树索引，如有需要，可用reverse表达式函数索引。

【推荐】 使用数组代替临时表

考虑使用数组替代临时表，例如在获取一系列ID的对应记录时。=ANY(ARRAY[1,2,3])要比临时表JOIN好。

0x05 发布规范

【强制】 发布形式

目前以邮件形式提交发布，发送邮件至dba@p1.com 归档并安排提交。
标题清晰：xx项目需在xx库执行xx动作。
目标明确：每个步骤需要在哪些实例上执行哪些操作，结果如何校验。
回滚方案：任何变更都需要提供回滚方案，新建也需要提供清理脚本。

【强制】发布评估

线上数据库发布需要经过研发自测，主管审核，（可选QA审核），DBA审核几个评估阶段。
自测阶段应当确保变更在开发、预发环境执行正确无误。
- 如果是新建表，应当给出记录数量级，数据日增量预估值，读写量级预估。
- 如果是新建函数，应当给出压测报告，至少需要给出平均执行时间。
- 如果是模式迁移，必须梳理清楚所有上下游依赖。
Team Leader需要对变更进行评估与审核，对变更内容负责。
DBA对发布的形式与影响进行评估与审核。

【强制】 发布窗口

19:00 后不允许数据库发布，紧急发布请TL做特殊说明，抄送CTO。
16:00点后确认的需求将顺延至第二天执行。（以TL确认时间为准）

0x06 管理规范

【强制】 关注备份

每日全量备份，段文件持续归档

【强制】 关注年龄

关注数据库与表的年龄，避免事物ID回卷。

【强制】 关注老化与膨胀

关注表与索引的膨胀率，避免性能劣化。

【强制】 关注复制延迟

监控复制延迟，使用复制槽时更必须十分留意。

【强制】 遵循最小权限原则

【强制】并发地创建与删除索引

对于生产表，必须使用CREATE INDEX CONCURRENTLY并发创建索引。

【强制】 新从库数据预热

使用pg_prewarm，或逐渐接入流量。

【强制】 审慎地进行模式变更

添加新列时必须使用不带默认值的语法，避免全表重写
变更类型时，必要时应当重建所有依赖该类型的函数。

【推荐】 切分大批量操作

大批量写入操作应当切分为小批量进行，避免一次产生大量WAL。

【推荐】 加速数据加载

关闭autovacuum，使用COPY加载数据。
事后建立约束与索引。
调大maintenance_work_mem，增大max_wal_size。
完成后执行vacuum verbose analyze table。

微信公众号原文

PG好处都有啥

PG好处都有啥，我要给它夸一夸，为什么PG是世界上最先进的开源关系型数据库

著： 冯若航（@Vonng） | 2018-06-10

PostgreSQL的Slogan是“世界上最先进的开源关系型数据库”，但我觉得这口号不够响亮，而且一看就是在怼MySQL那个“世界上最流行的开源关系型数据库”的口号，有碰瓷之嫌。要我说最能生动体现PG特色的口号应该是：一专多长的全栈数据库，一招鲜吃遍天嘛。

pggood

全栈数据库

成熟的应用可能会用到许许多多的数据组件（功能）：缓存，OLTP，OLAP/批处理/数据仓库，流处理/消息队列，搜索索引，NoSQL/文档数据库，地理数据库，空间数据库，时序数据库，图数据库。传统的架构选型呢，可能会组合使用多种组件，典型的如：Redis + MySQL + Greenplum/Hadoop + Kafuka/Flink + ElasticSearch，一套组合拳基本能应付大多数需求了。不过比较令人头大的就是异构系统集成了：大量的代码都是重复繁琐的胶水代码，干着把数据从A组件搬运到B组件的事情。

在这里，MySQL就只能扮演OLTP关系型数据库的角色，但如果是PostgreSQL，就可以身兼多职，One handle them all，比如：

OLTP：事务处理是PostgreSQL的本行
OLAP：citus分布式插件，ANSI SQL兼容，窗口函数，CTE，CUBE等高级分析功能，任意语言写UDF
流处理：PipelineDB扩展，Notify-Listen，物化视图，规则系统，灵活的存储过程与函数编写
时序数据：timescaledb时序数据库插件，分区表，BRIN索引
空间数据：PostGIS扩展（杀手锏），内建的几何类型支持，GiST索引。
搜索索引：全文搜索索引足以应对简单场景；丰富的索引类型，支持函数索引，条件索引
NoSQL：JSON，JSONB，XML，HStore原生支持，至NoSQL数据库的外部数据包装器
数据仓库：能平滑迁移至同属Pg生态的GreenPlum，DeepGreen，HAWK等，使用FDW进行ETL
图数据：递归查询
缓存：物化视图

ext

以Extension作六器，礼天地四方。

以Greenplum礼天，

以Postgres-XL礼地，

以Citus礼东方，

以TimescaleDB礼南方，

以PipelineDB礼西方，

以PostGIS礼北方。

—— 《周礼.PG》

在探探的旧版架构中，整个系统就是围绕PostgreSQL设计的。几百万日活，几百万全局DB-TPS，几百TB数据的规模下，数据组件只用了PostgreSQL。独立的数仓，消息队列和缓存都是后来才引入的。而且这只是验证过的规模量级，进一步压榨PG是完全可行的。

因此，在一个很可观的规模内，PostgreSQL都可以扮演多面手的角色，一个组件当多种组件使。虽然在某些领域它可能比不上专用组件，至少都做的都还不赖。而单一数据组件选型可以极大地削减项目额外复杂度，这意味着能节省很多成本。它让十个人才能搞定的事，变成一个人就能搞定的事。

为了不需要的规模而设计是白费功夫，实际上这属于过早优化的一种形式。只有当没有单个软件能满足你的所有需求时，才会存在分拆与集成的利弊权衡。集成多种异构技术是相当棘手的工作，如果真有那么一样技术可以满足你所有的需求，那么使用该技术就是最佳选择，而不是试图用多个组件来重新实现它。

当业务规模增长到一定量级时，可能不得不使用基于微服务/总线的架构，将数据库的功能分拆为多个组件。但PostgreSQL的存在极大地推后了这个权衡到来的阈值，而且分拆之后依然能继续发挥重要作用。

运维友好

当然除了功能强大之外，Pg的另外一个重要的优势就是运维友好。有很多非常实用的特性：

DDL能放入事务中，删表，TRUNCATE，创建函数，索引，都可以放在事务里原子生效，或者回滚。

这就能进行很多骚操作，比如在一个事务里通过RENAME，完成两张表的王车易位。
能够并发地创建、删除索引，添加非空字段，重整索引与表（不锁表）。

这意味着可以随时在线上不停机进行重大的模式变更，按需对索引进行优化。
复制方式多样：段复制，流复制，触发器复制，逻辑复制，插件复制等等。

这使得不停服务迁移数据变得相当容易：复制，改读，改写三步走，线上迁移稳如狗。
提交方式多样：异步提交，同步提交，法定人数同步提交。

这意味着Pg允许在C和A之间做出权衡与选择，例如交易库使用同步提交，普通库使用异步提交。
系统视图非常完备，做监控系统相当简单。
FDW的存在让ETL变得无比简单，一行SQL就能解决。

FDW可以方便地让一个实例访问其他实例的数据或元数据。在跨分区操作，数据库监控指标收集，数据迁移等场景中妙用无穷。同时还可以对接很多异构数据系统。

生态健康

PostgreSQL的生态也很健康，社区相当活跃。

相比MySQL，PostgreSQL的一个巨大的优势就是协议友好。PG采用类似BSD/MIT的PostgreSQL协议，差不多理解为只要别打着Pg的旗号出去招摇撞骗，随便你怎么搞，换皮出去卖都行。君不见多少国产数据库，或者不少“自研数据库”实际都是Pg的换皮或二次开发产品。

当然，也有很多衍生产品会回馈主干，比如timescaledb, pipelinedb, citus 这些基于PG的“数据库”，最后都变成了原生PG的插件。很多时候你想实现个什么功能，一搜就能找到对应的插件或实现。开源嘛，还是要讲一些情怀的。

Pg的代码质量相当之高，注释写的非常清晰。C的代码读起来有种Go的感觉，代码都可以当文档看了。能从中学到很多东西。相比之下，其他数据库，比如MongoDB，看一眼我就放弃了读下去的兴趣。

而MySQL呢，社区版采用的是GPL协议，这其实挺蛋疼的。要不是GPL传染，怎么会有这么多基于MySQL改的数据库开源出来呢？而且MySQL还在乌龟壳的手里，让自己的蛋蛋攥在别人手中可不是什么明智的选择，更何况是业界毒瘤呢？Facebook修改React协议的风波就算是一个前车之鉴了。

问题

当然，要说有什么缺点或者遗憾，那还是有几个的：

因为使用了MVCC，数据库需要定期VACUUM，需要定期维护表和索引避免性能下降。
没有很好的开源集群监控方案（或者太丑！），需要自己做。
慢查询日志和普通日志是混在一起的，需要自己解析处理。
官方Pg没有很好用的列存储，对数据分析而言算一个小遗憾。

当然都是些无关痛痒的小毛小病，不过真正的问题可能和技术无关……

说到底，MySQL确实是最流行的开源关系型数据库，没办法，写Java的，写PHP的，很多人最开始用的都是MySQL…，所以Pg招人相对困难是一个事实，很多时候只能自己培养。不过看DB Engines上的流行度趋势，未来还是很光明的。

dbrank

其他

学PostgreSQL是一件很有趣的事，它让我意识到数据库的功能远远不止增删改查。我学着SQL Server与MySQL迈进数据库的大门。但却是PostgreSQL真正向我展示了数据库的奇妙世界。

之所以写本文，是因为在知乎上的老坟又被挖了出来，让笔者回想起当年邂逅PostgreSQL时的青葱岁月。（https://www.zhihu.com/question/20010554/answer/94999834 ）当然，现在我干了专职的PG DBA，忍不住再给这老坟补几铲。“王婆卖瓜，自卖自夸”，夸一夸PG也是应该的。嘿嘿嘿……

全栈工程师就该用全栈数据库嘛。

我自己比较选型过MySQL和PostgreSQL，难得地在阿里这种MySQL的世界中有过选择的自由。我认为单从技术因素上来讲，PG是完爆MySQL的。尽管阻力很大，最后还是把PostgreSQL用了起来，推了起来。我用它做过很多项目，解决了很多需求（小到算统计报表，大到给公司创收个小目标）。大多数需求PG单挑就搞定了，少部分也会再用些MQ和NoSQL（Redis，MongoDB，Cassandra/HBase）。Pg实在是让人爱不释手。

最后实在是对Pg爱不释手，以至于专职去研究PG了。

在我的第一份工作中就深刻尝到了甜头，使用PostgreSQL，一个人的开发效率能顶一个小团队：

后端懒得写怎么办，PostGraphQL直接从数据库模式定义生成GraphQL API，自动监听DDL变更，生成相应的CRUD方法与存储过程包装，对于后台开发再方便不过，类似的工具还有PostgREST与pgrest。对于中小数据量的应用都还堪用，省了一大半后端开发的活。
需要用到Redis的功能，直接上Pg，模拟普通功能不在话下，缓存也省了。Pub/Sub使用Notify/Listen/Trigger实现，用来广播配置变更，做一些控制非常方便。
需要做分析，窗口函数，复杂JOIN，CUBE，GROUPING，自定义聚合，自定义语言，爽到飞起。如果觉得规模大了想scale out可以上citus扩展（或者换greenplum）；比起数仓可能少个列存比较遗憾，但其他该有的都有了。
用到地理相关的功能，PostGIS堪称神器，千行代码才能实现的复杂地理需求，一行SQL轻松高效解决。
存储时序数据，timescaledb扩展虽然比不上专用时序数据库，但百万记录每秒的入库速率还是有的。用它解决过硬件传感器日志存储，监控系统Metrics存储的需求。
一些流计算的相关功能，可以用PipelineDB直接定义流式视图实现：UV，PV，用户画像实时呈现。
PostgreSQL的FDW是一种强大的机制，允许接入各种各样的数据源，以统一的SQL接口访问。它妙用无穷：
- file_fdw这种自带的扩展，可以将任意程序的输出接入数据表。最简单的应用就是监控系统信息。
- 管理多个PostgreSQL实例时，可以在一个元数据库中用自带的postgres_fdw导入所有远程数据库的数据字典。统一访问所有数据库实例的元数据，一行SQL拉取所有数据库的实时指标，监控系统做起来不要太爽。
- 之前做过的一件事就是用hbase_fdw和MongoFDW，将HBase中的历史批量数据，MongoDB中的当日实时数据包装为PostgreSQL数据表，一个视图就简简单单地实现了融合批处理与流处理的Lambda架构。
- 使用redis_fdw进行缓存更新推送；使用mongo_fdw完成从mongo到pg的数据迁移；使用mysql_fdw读取MySQL数据并存入数仓；实现跨数据库，甚至跨数据组件的JOIN；使用一行SQL就能完成原本多少行代码才能实现的复杂ETL，这是一件多么美妙的事情。
各种丰富的类型与方法支持：例如JSON，从数据库直接生成前端所需的JSON响应，轻松而惬意。范围类型，优雅地解决很多原本需要程序处理的边角情况。其他的例如数组，多维数组，自定义类型，枚举，网络地址，UUID，ISBN。很多开箱即用的数据结构让程序员省去了多少造轮子的功夫。
丰富的索引类型：通用的Btree索引；大幅优化顺序访问的Brin索引；等值查询的Hash索引；GIN倒排索引；GIST通用搜索树，高效支持地理查询，KNN查询；Bitmap同时利用多个独立索引；Bloom高效过滤索引；能大幅减小索引大小的条件索引；能优雅替代冗余字段的函数索引。而MySQL就只有那么可怜的几种索引。
稳定可靠，正确高效。MVCC轻松实现快照隔离，MySQL的RR隔离等级实现不完善，无法避免PMP与G-single异常。而且基于锁与回滚段的实现会有各种坑；PostgreSQL通过SSI能实现高性能的可序列化。
复制强大：WAL段复制，流复制（v9出现，同步、半同步、异步），逻辑复制（v10出现：订阅/发布），触发器复制，第三方复制，各种复制一应俱全。
运维友好：可以将DDL放在事务中执行（可回滚），创建索引不锁表，添加新列（不带默认值）不锁表，清理/备份不锁表。各种系统视图，监控功能都很完善。
扩展众多、功能丰富、可定制程度极强。在PostgreSQL中可以使用任意的语言编写函数：Python，Go，Javascript，Java，Shell等等。与其说Pg是数据库，不如说它是一个开发平台。我就试过很多没什么卵用但很好玩的东西：**数据库里（in-db）**的爬虫/ 推荐系统 / 神经网络 / Web服务器等等。有着各种功能强悍或脑洞清奇的第三方插件：https://pgxn.org。
PostgreSQL的License友好，BSD随便玩，君不见多少数据库都是PG的换皮产品。MySQL有GPL传染，还要被Oracle捏着蛋蛋。

微信公众号原文

区块链与分布式数据库

区块链的技术本质、提供的功能、及演化方向就是分布式数据库

著： 冯若航（@Vonng） | 2018-06-09

区块链的本质，想提供的功能，及其演化方向，就是分布式数据库。

确切的讲，是拜占庭容错（抗恶意节点攻击）的分布式（无领导者复制）数据库。

如果这种分布式数据库用来存储各种币的交易记录，这个系统就叫做所谓的“XX币”。例如以太坊就是这样一个分布式数据库，上面除了记载着各种山寨币的交易记录，还可以记载各种奇奇怪怪的内容。花一点以太币，就可以在这个分布式数据库里留下一条记录（一封信）。而所谓智能合约就是这个分布式数据库上的存储过程。

从形式上看，区块链与**预写式日志（Write-Ahead-Log, WAL, Binlog, Redolog）**在设计原理上是高度一致的。

WAL是数据库的核心数据结构，记录了从数据库创建之初到当前时刻的所有变更，用于实现主从复制、备份回滚、故障恢复等功能。如果保留了全量的WAL日志，就可以从起点回放WAL，时间旅行到任意时刻的状态，如PostgreSQL的PITR。

区块链其实就是这样一份日志，它记录了从创世以来的每笔Transaction。回放日志就可以还原数据库任意时刻的状态（反之则不成立）。所以区块链当然可以算作某种意义上的数据库。

区块链的两大特性：去中心化与防篡改，用数据库的概念也很好理解：

去中心化的实质就是无领导者复制（leaderless replication），核心在于分布式共识。
防篡改的实质就是拜占庭容错，即，使得篡改WAL的计算代价在概率上不可行。

正如WAL分为日志段，区块链也被划分为一个一个**区块，**且每一段带有先前日志段的哈希指纹。

所谓挖矿就是一个公开的猜数字比快游戏（满足条件的数字才会被共识承认），先猜中者能获取下一个日志段的初夜权：向日志段里写一笔向自己转账的记录（就是挖矿的奖励），并广播出去（如果别人也猜中了，以先广播至多数为准）。所有节点通过共识算法，保证当前最长的链为权威日志版本。区块链通过共识算法实现日志段的无主复制。

而如果想要修改某个WAL日志段中的一比交易记录，比如，转给自己一万个比特币，需要把这个区块以及其后所有区块的指纹给凑出来（连猜几次数字），并让多数节点相信这个伪造版本才行（拼一个更长的伪造版本，意味着猜更多次数字）。比特币中六个区块确认一个交易就是这个意思，篡改六个日志段之前的记录的算例代价，通常在概率上是不可行的。区块链通过这种机制（如Merkle树）实现拜占庭容错。

区块链涉及到的相关技术中，除了分布式共识外都很简单，但这种应用方式与机制设计确实是相当惊艳的。区块链可以算是一次数据库的演化尝试，长期来看前景广阔。但搞链能立竿见影起作用的领域，好像都是老大哥的地盘。而且不管怎么吹嘘，现在的区块链离真正意义上的分布式数据库还差的太远，所以现在入场搞应用的大概率都是先烈。

原文知乎链接

一致性：过载的术语

一致性这个词重载的很厉害，在不同的语境和上下文中，它其实代表着不同的东西：

著： 冯若航（@Vonng） | 2018-05-08

一致性这个词重载的很厉害，在不同的语境和上下文中，它其实代表着不同的东西：

在事务的上下文中，比如ACID里的C，指的就是通常的一致性（Consistency）
在分布式系统的上下文中，例如CAP里的C，实际指的是线性一致性（Linearizability）
此外，“一致性哈希”，“最终一致性”这些名词里的“一致性”也有不同的涵义。

这些一致性彼此不同却又有着千丝万缕的联系，所以经常会把人绕晕。

在事务的上下文中，一致性（Consistency） 的概念是：对数据的一组特定陈述必须始终成立。即不变量（invariants）。具体到分布式事务的上下文中这个不变量是：所有参与事务的节点状态保持一致：要么全部成功提交，要么全部失败回滚，不会出现一些节点成功一些节点失败的情况。

在分布式系统的上下文中，线性一致性（Linearizability） 的概念是：多副本的系统能够对外表现地像只有单个副本一样（系统保证从任何副本读取到的值都是最新的），且所有操作都以原子的方式生效（一旦某个新值被任一客户端读取到，后续任意读取不会再返回旧值）。

线性一致性这个词可能有些陌生，但说起它的另一个名字大家就清楚了：强一致性（strong consistency） ，当然还有一些诨名：原子一致性（atomic consistency），立即一致性（immediate consistency） 或 外部一致性（external consistency ） 说的都是它。

这两个“一致性”完全不是一回事儿，但之间其实有着微妙的联系，它们之间的桥梁就是共识（Consensus）

简单来说：

分布式事务一致性会因为协调者单点引入可用性问题
为了解决可用性问题，分布式事务的节点需要在协调者故障时就新协调者选取达成共识
解决共识问题等价于实现一个线性一致的存储
解决共识问题等价于实现全序广播（total order boardcast）
Paxos/Raft 实现了全序广播

具体来讲：

为了保证分布式事务的一致性，分布式事务通常需要一个协调者（Coordinator）/事务管理器（Transaction Manager）来决定事务的最终提交状态。但无论2PC还是3PC，都无法应对协调者失效的问题，而且具有扩大故障的趋势。这就牺牲了可靠性、可维护性与可扩展性。为了让分布式事务真正可用，就需要在协调者挂点的时候能赶快选举出一个新的协调者来解决分歧，这就需要所有节点对谁是Boss达成共识（Consensus）。

共识意味着让几个节点就某事达成一致，可以用来确定一些互不相容的操作中，哪一个才是赢家。共识问题通常形式化如下：一个或多个节点可以提议（propose）某些值，而共识算法决定采用其中的某个值。在保证分布式事务一致性的场景中，每个节点可以投票提议，并对谁是新的协调者达成共识。

共识问题与许多问题等价，两个最典型的问题就是：

实现一个具有线性一致性的存储系统
实现全序广播（保证消息不丢失，且消息以相同的顺序传递给每个节点。）

Raft算法解决了全序广播问题。维护多副本日志间的一致性，其实就是让所有节点对同全局操作顺序达成一致，也其实就是让日志系统具有线性一致性。 因而解决了共识问题。（当然正因为共识问题与实现强一致存储问题等价，Raft的具体实现etcd 其实就是一个线性一致的分布式数据库。）

总结一下：

线性一致性是一个精确定义的术语，线性一致性是一种 一致性模型 ，对分布式系统的行为作出了很强的保证。

分布式事务中的一致性则与事务ACID中的C一脉相承，并不是一个严格的术语。（因为什么叫一致，什么叫不一致其实是应用说了算。在分布式事务的场景下可以认为是：所有节点的事务状态始终保持相同）

分布式事务本身的一致性是通过协调者内部的原子操作与多阶段提交协议保证的，不需要共识；但解决分布式事务一致性带来的可用性问题需要用到共识。

为什么要学习数据库原理

计算机系为什么要学数据库原理和设计？

著： 冯若航（@Vonng） | 2018-04-20

问题

计算机系为什么要学数据库原理和设计？

我们学校开了数据库系统原理课程。但是我还是很迷茫，这几节课老师一上来就讲一堆令人头大的名词概念，我以为我们知道“如何设计构建表”，“如何mysql增删改查”就行了……那为什么还要了解关系模式的表示方法，计算，规范化……概念模型……各种模型的相互转换，为什么还要了解什么关系代数，什么笛卡尔积……这些的理论知识。我十分困惑，通过这些理论概念，该课的目的或者说该书的目的究竟是想让学生学会什么呢？

回答

只会写代码的是码农；学好数据库，基本能混口饭吃；在此基础上再学好操作系统和计算机网络，就能当一个不错的程序员。如果能再把离散数学、数字电路、体系结构、数据结构/算法、编译原理学通透，再加上丰富的实践经验与领域特定知识，就能算是一个优秀的工程师了。（前端算IO密集型应用就别抬杠了）

计算机其实就是存储/IO/CPU三大件；而计算说穿了就是两个东西：数据与算法（状态与转移函数）。常见的软件应用，除了各种模拟仿真、模型训练、视频游戏这些属于计算密集型应用外，绝大多数都属于数据密集型应用。从最抽象的意义上讲，这些应用干的事儿就是把数据拿进来，存进数据库，需要的时候再拿出来。

抽象是应对复杂度的最强武器。操作系统提供了对存储的基本抽象：内存寻址空间与磁盘逻辑块号。文件系统在此基础上提供了文件名到地址空间的KV存储抽象。而数据库则在其基础上提供了对应用通用存储需求的高级抽象。

在真实世界中，除非准备从基础组件的轮子造起，不然根本没那么多机会去摆弄花哨的数据结构和算法（对数据密集型应用而言）。甚至写代码的本事可能也没那么重要：可能只会有那么一两个Ad Hoc算法需要在应用层实现，大部分需求都有现成的轮子可以使用，主要的创造性工作往往是在数据模型设计上。实际生产中，数据表就是数据结构，索引与查询就是算法。而应用代码往往扮演的是胶水的角色，处理IO与业务逻辑，其他大部分的工作都是在数据系统之间搬运数据。

在最宽泛的意义上，有状态的地方就有数据库。它无所不在，网站的背后、应用的内部，单机软件，区块链里，甚至在离数据库最远的Web浏览器中，也逐渐出现了其雏形：各类状态管理框架与本地存储。“数据库”可以简单地只是内存中的哈希表/磁盘上的日志，也可以复杂到由多种数据系统集成而来。关系型数据库只是数据系统的冰山一角（或者说冰山之巅），实际上存在着各种各样的数据系统组件：

数据库：存储数据，以便自己或其他应用程序之后能再次找到（PostgreSQL，MySQL，Oracle）
缓存：记住开销昂贵操作的结果，加快读取速度（Redis，Memcached）
搜索索引：允许用户按关键字搜索数据，或以各种方式对数据进行过滤（ElasticSearch）
流处理：向其他进程发送消息，进行异步处理（Kafka，Flink）
批处理：定期处理累积的大批量数据（Hadoop）

**架构师最重要的能力之一，就是了解这些组件的性能特点与应用场景，能够灵活地权衡取舍、集成拼接这些数据系统。**绝大多数工程师都不会去从零开始编写存储引擎，因为在开发应用时，数据库已经是足够完美的工具了。关系型数据库则是目前所有数据系统中使用最广泛的组件，可以说是程序员吃饭的主要家伙，重要性不言而喻。

了解意义（WHY）比了解方法（HOW）更重要。但一个很遗憾的现实是，以大多数学生，甚至相当一部分公司能够接触到的现实问题而言，拿几个文件甚至在内存里放着估计都能应付大多数场景了（需求简单到低级抽象就可以Handle）。没什么机会接触到数据库真正要解决的问题，也就难有真正使用与学习数据库的驱动力，更别提数据库原理了。当软硬件故障把数据搞成一团浆糊（可靠性）；当单表超出了内存大小，并发访问的用户增多（可扩展性），当代码的复杂度发生爆炸，开发陷入泥潭（可维护性），人们才会真正意识到数据库的重要性。所以我也理解当前这种填鸭教学现状的苦衷：工作之后很难有这么大把的完整时间来学习原理了，所以老师只好先使劲灌输，多少让学生对这些知识有个印象。等学生参加工作后真正遇到这些问题，也许会想起大学好像还学了个叫数据库的东西，这些知识就会开始反刍。

数据库，尤其是关系型数据库，非常重要。那为什么要学习其原理呢？

对优秀的工程师来说，只会用数据库是远远不够的。学习原理对于当CRUD BOY搬砖收益并不大，但当通用组件真的无解需要自己撸起袖子上时，没有金坷垃怎么种庄稼？设计系统时，理解原理能让你以最少的复杂度代价写出更可靠高效的代码；遇到疑难杂症需要排查时，理解原理能带来精准的直觉与深刻的洞察。

数据库是一个博大精深的领域，存储I/O计算无所不包。其主要原理也可以粗略分为几个部分：数据模型设计原理（应用）、存储引擎原理（基础）、索引与查询优化器的原理（性能）、事务与并发控制的原理（正确性）、故障恢复与复制系统的原理（可靠性）。所有的原理都有其存在意义：为了解决实际问题。

例如数据模型设计中的范式理论，就是为了解决数据冗余这一问题而提出的，它是为了把事情做漂亮（可维护）。它是模型设计中一个很重要的设计权衡：通常而言，冗余少则复杂度小/可维护性强，冗余高则性能好。比如用了冗余字段，那更新时原本一条SQL就搞定的事情，现在现在就要用两条SQL更新两个地方，需要考虑多对象事务，以及并发执行时可能的竞态条件。这就需要仔细权衡利弊，选择合适的规范化等级。数据模型设计，就是生产中的数据结构设计。不了解这些原理，就难以提取良好的抽象，其他工作也就无从谈起。

而关系代数与索引的原理，则在查询优化中扮演重要的角色，它是为了把事情做得快（性能，可扩展）。当数据量越来越大，SQL写的越来越复杂时，它的意义就会体现出来：**怎样写出等价但是更高效的查询？**当查询优化器没那么智能时，就需要人来干这件事。这种优化往往成本极小而收益巨大，比如一个需要几秒的KNN查询，如果知道R树索引的原理，就可以通过改写查询，创建GIST索引优化到1毫秒内，千倍的性能提升。**不了解索引与查询设计原理，就难以充分发挥数据库的性能。**

事务与并发控制的原理，是为了把事情做正确（可靠性）。事务是数据处理领域最伟大的抽象之一，它提供了很多有用的保证（ACID），但这些保证到底意味着什么？事务的原子性让你在提交前能随时中止事务并丢弃所有写入，相应地，事务的持久性则承诺一旦事务成功提交，即使发生硬件故障或数据库崩溃，写入的任何数据也不会丢失。这让错误处理变得无比简单：要么成功完事，要么失败重试。有了后悔药，程序员不用再担心半路翻车会留下惨不忍睹的车祸现场了。

另一方面，事务的隔离性则保证同时执行的事务无法相互影响（Serializable），数据库提供了不同的隔离等级保证，以供程序员在性能与正确性之间进行权衡。编写并发程序并不容易，在几万TPS的负载下，各种极低概率，匪夷所思的问题都会出现：事务之间相互踩踏，丢失更新，幻读与写入偏差，慢查询拖慢快查询导致连接堆积，单表数据库并发增大后的性能急剧恶化，甚至快慢查询都减少但因比例变化导致的灵异抽风。这些问题，在低负载的情况下会潜伏着，随着规模量级增长突然跳出来，给你一个大大的惊喜。现实中真正可能出现的各类异常，也绝非SQL标准中简单的几种异常能说清的。 不理解事务的原理，意味着应用的可靠性可能遭受不必要的损失。

故障恢复与复制的原理，可能对于程序员没有那么重要，但架构师与DBA必须清楚。高可用是很多应用的追求目标，但什么是高可用，高可用怎么保证？读写分离？快慢分离？异地多活？x地x中心？说穿了底下的核心技术其实就是复制（Replication）（或再加上自动故障切换（Failover））。这里有无穷无尽的坑：复制延迟带来的各种灵异现象，网络分区与脑裂，存疑事务blahblah。不理解复制的原理，高可用就无从谈起。

对于一些程序员而言，可能数据库就是“增删改查”，包一包接口，原理似乎属于“屠龙之技”。如果止步于此，那原理确实没什么好学的，但有志者应当打破砂锅问到底的精神。私认为只了解自己本领域知识是不够的，只有把当前领域赖以建立的上层领域摸清楚，才能称为专家。在数据库面前，后端也是前端；对于程序员知识栈而言，数据库是一个合适的栈底。

上面讲了WHY，下面就说一下 HOW

数据库教学的一个矛盾是：如果连数据库都不会用，那学数据库原理有个卵用呢？

学数据库的原则是学以致用。只有实践，才能带来对问题的深刻理解；只有先知其然，才有条件去知其所以然。教材可以先草草的过一遍，然后直接去看数据库文档，上手去把数据库用起来，做个东西出来。通过实践掌握数据库的使用，再去学习原理就会事半功倍（以及充满动力）。对于学习而言，有条件去实习当然最好，没有条件那最好的办法就是自己创造场景，自己挖掘需求。

比如，从解决个人需求开始：管理个人密码，体重跟踪，记账，做个小网站、在线聊天小程序。当它演化的越来越复杂，开始有多个用户，出现各种蛋疼问题之后，你就会开始意识到事务的意义。

再比如，结合爬虫，抓一些房价、股价、地理、社交网络的数据存在数据库里，做一些挖掘与分析。当你积累的数据越来越多，分析查询越来越复杂；SQL长得没法读，跑起来慢出猪叫，这时候关系代数的理论就能指导你进一步进行优化。

当你意识到这些设计都是为了解决现实生产中的问题，并亲自遇到过这些问题之后，再去学习原理，才能相互印证，并知其所以然。当你发现查询时间随数据增长而指数增长时；当你遇到成千上万的用户同时读写为并发控制焦头烂额时；当你碰上软硬件故障把数据搅得稀巴烂时；当你发现数据冗余让代码复杂度快速爆炸时；你就会发现这些设计存在的意义。

教材、书籍、文档、视频、邮件组、博客都是很好的学习资源。教材的话华章的黑皮系列教材都还不错，《数据库系统概念》这本就挺好的。但我推荐先看看这本书：《设计数据密集型应用》，写的非常好，我觉得不错就义务翻译了一下。纸上得来终觉浅，绝知此事要躬行。实践方能出真知，新手上路选哪家？个人推荐世界上最先进的开源关系型数据库PostgreSQL，设计优雅，功能强大。传教就有请德哥出场了：https://github.com/digoal/blog 。有时间的话可以再看看Redis，源码简单易读，实践中也很常用，非关系型数据库也应当多了解一下。

最后，关系型数据库虽然强大，却绝非数据处理的终章，尽可能多地去尝试各种各样的数据库吧。

知乎原文链接

微信公众号原文

开发

关于使用PostgreSQL进行开发的经验

PostgreSQL高级模糊查询

如何在PostgreSQL中实现比较复杂的模糊查询逻辑？

著： 冯若航（@Vonng） | 2021-03-05

PostgreSQL高级模糊查询

日常开发中，经常见到有模糊查询的需求。今天就简单聊一聊如何用PostgreSQL实现一些高级一点的模糊查询。

当然这里说的模糊查询，不是LIKE表达式前模糊后模糊两侧模糊，这种老掉牙的东西。让我们直接用一个具体的例子开始吧。

问题

现在，假设我们做了个应用商店，想给用户提供搜索功能。用户随便输入点什么，找出所有与输入内容匹配的应用，排个序返回给用户。

严格来说，这种需求其实是需要一个搜索引擎，最好还是用专用软件，例如ElasticSearch来搞。但实际上只要不是特别复杂的逻辑，也可以很好的用PostgreSQL实现。

数据

样例数据如下所示，一张应用表。抽除了所有无关字段，就留下一个应用名称name作为主键。

CREATE TABLE app(name TEXT PRIMARY KEY); 
-- COPY app FROM '/tmp/app.csv';

里面的数据差不多长这样，中英混杂，共计150万条。

Rome travel guide, rome italy map rome tourist attractions directions to colosseum, vatican museum, offline ATAC city rome bus tram underground train maps, 罗马地图,罗马地铁,罗马火车,罗马旅行指南"""
Urban Pics - 游戏俚语词典
世界经典童话故事大全(6到12岁少年儿童睡前故事英语亲子软件) 2 - 高级版
星征服者
客房控制系统
Santa ME! - 易圣诞老人,小精灵快乐的脸效果！

输入

用户在搜索框可能输入的东西，差不多就跟你自己在应用商店搜索框里会键入的东西差不多。“天气”，“外卖”，“交友”……

而我们想做到的效果，跟你对应用商店查询返回结果的期待也差不多。当然是越准确越好，最好还能按相关度排个序。

当然，作为一个生产级的应用，还必须能及时响应。不可以全表扫描，得用到索引。

那么，这类问题怎么解呢？

解题思路

针对这一问题，有三种解题思路。

基于LIKE的模式匹配。
基于pg_trgm的字符串相似度的匹配
基于自定义分词与倒排索引的模糊查询

LIKE模式匹配

最简单粗暴的方式就是使用 LIKE '%' 模式匹配查询。

老生常谈，没啥技术含量。把用户输入的关键词前后加一个百分号，然后执行这种查询：

SELECT * FROM app WHERE name LIKE '%支付宝%';

前后模糊的查询可以通过常规的Btree索引进行加速，注意在PostgreSQL中使用 LIKE查询时不要掉到LC_COLLATE的坑里去了，详情参考这篇文章：PG中的本地化排序规则。

CREATE INDEX ON app(name COLLATE "C");          -- 后模糊
CREATE INDEX ON app(reverse(name) COLLATE "C"); -- 前模糊

如果用户的输入非常精准清晰，这样的方式也不是不可以。响应速度也不错。但有两个问题：

太机械死板，假设应用厂商发了个名字，在原来的关键词里面加了个空格或者什么符号，这种查询立刻就失效了。
没有距离度量，我们没有一个合适的度量，来排序返回的结果。说如果返回几百个结果没有排序，那很难让用户满意的。
有时候准确度还是不行，比如一些应用做SEO，把各种头部应用的名字都嵌到自己的名字中来提高搜索排名。

PG TRGM

PostgreSQL自带了一个名为pg_trgm的扩展，提供的基于三字符语素的模糊查询。

pg_trgm模块提供用于决定基于 trigram 匹配的字母数字文本相似度的函数和操作符，以及支持快速搜索相似字符串的索引操作符类。

使用方式

-- 使用trgm操作符提取关键词素，并建立gist索引
CREATE INDEX ON app USING gist (name gist_trgm_ops);

查询方式也很直观，直接使用% 运算符即可，比如从应用表中查到与支付宝相关的应用。

SELECT name, similarity(name, '支付宝') AS sim FROM app 
WHERE name % '支付宝'  ORDER BY 2 DESC;

         name          |     sim
-----------------------+------------
 支付宝 - 让生活更简单 | 0.36363637
 支付搜                | 0.33333334
 支付社                | 0.33333334
 支付啦                | 0.33333334
(4 rows)

Time: 231.872 ms

Sort  (cost=177.20..177.57 rows=151 width=29) (actual time=251.969..251.970 rows=4 loops=1)
"  Sort Key: (similarity(name, '支付宝'::text)) DESC"
  Sort Method: quicksort  Memory: 25kB
  ->  Index Scan using app_name_idx1 on app  (cost=0.41..171.73 rows=151 width=29) (actual time=145.414..251.956 rows=4 loops=1)
        Index Cond: (name % '支付宝'::text)
Planning Time: 2.331 ms
Execution Time: 252.011 ms

该方式的优点是：

提供了字符串的距离函数similarity，可以给出两个字符串之间相似程度的定性度量。因此可以排序。
提供了基于3字符组合的分词函数show_trgm。
可以利用索引加速查询。
SQL查询语句非常简单清晰，索引定义也很简单明了，维护简单

该方式的缺点是：

关键词很短的情况（1-2汉字）的情况下召回率很差，特别是只有一个字时，是无法查询出结果的
执行效率较低，例如上面这个查询使用了200ms
定制性太差，只能使用它自己定义的逻辑来定义字符串的相似度，而且这个度量对于中文的效果相当存疑（中文三字词频率很低）
对LC_CTYPE有特殊的要求，默认LC_CTYPE = C 无法正确对中文进行分词。

特殊问题

是pg_trgm的最大问题是，无法在LC_CTYPE = C的实例上针对中文使用。因为 LC_CTYPE=C 缺少一些字符的分类定义。不幸的是LC_CTYPE一旦设置，基本除了重新建库是没法更改的。

通常来说，PostgreSQL的Locale应当设置为C，或者至少将本地化规则中的排序规则LC_COLLATE 设置为C，以避免巨大的性能损失与功能缺失。但是因为pg_trgm的这个“问题”，您需要在创建库时，即指定LC_CTYPE = <non-C-locale>。这里基于i18n的LOCALE从原理上应该都可以使用。常见的en_US与zh_CN都是可以的。但注意特别注意，macOS上对Locale的支持存在问题。过于依赖LOCALE的行为会降低代码的可移植性。

高级模糊查询

实现一个高级的模糊查询，需要两样东西：分词，倒排索引。

高级模糊查询，或者说全文检索基于以下思路实现：

分词：在维护阶段，每一个被模糊搜索的字段（例如应用名称），都会被分词逻辑加工处理成一系列关键词。
索引：在数据库中建立关键词到表记录的倒排索引
查询：将查询同样拆解为关键词，然后利用查询关键词通过倒排索引找出相关的记录来。

PostgreSQL内建了很多语言的分词程序，可以自动将文档拆分为一系列的关键词，是为全文检索功能。可惜中文还是比较复杂，PG并没有内建的中文分词逻辑，虽然有一些第三方扩展，诸如 pg_jieba, zhparser等，但也年久失修，在新版本的PG上能不能用还是一个问题。

但是这并不影响我们利用PostgreSQL提供的基础设施实现高级模糊查询。实际上上面说的分词逻辑是为了从一个很大的文本（例如网页）中抽取摘要信息（关键字）。而我们的需求恰恰相反，不仅不是抽取摘要进行概括精简，而且需要将关键词扩充，以实现特定的模糊需求。例如，我们完全可以在抽取应用名称关键词的过程中，把这些关键词的汉语拼音，首音缩写，英文缩写一起放进关键词列表中，甚至把作者，公司，分类，等一系列用户可能感兴趣的东西放进去。这样搜索的时候就可以使用丰富的输入了。

基本框架

我们先来构建整个问题解决的框架。

编写一个自定义的分词函数，从名称中抽取关键词（每个字，每个二字短语，拼音，英文缩写，放什么都可以）
在目标表上创建一个使用分词函数的函数表达式GIN索引。
通过数组操作或 tsquery 等方式定制你的模糊查询

-- 创建一个分词函数
CREATE OR REPLACE FUNCTION tokens12(text) returns text[] as $$....$$;

-- 基于该分词函数创建表达式索引
CREATE INDEX ON app USING GIN(tokens12(name));

-- 使用关键词进行复杂的定制查询（关键词数组操作）
SELECT * from app where split_to_chars(name) && ARRAY['天气'];

-- 使用关键词进行复杂的定制查询（tsquery操作）
SELECT * from app where to_tsvector123(name) @@ 'BTC &! 钱包 & ! 交易 '::tsquery;

PostgreSQL 提供了GIN索引，可以很好的支持倒排索引的功能，比较麻烦的是寻找一种比较合适的中文分词插件。将应用名称分解为一系列关键词。好在对于此类模糊查询的需求，也用不着像搞搜索引擎，自然语言处理那么精细的语义解析。只要参考pg_trgm的思路把中文也给手动一锅烩了就行。除此之外，通过自定义的分词逻辑，还可以实现很多有趣的功能。比如使用拼音模糊查询，使用拼音首字母缩写模糊查询。

让我们从最简单的分词开始。

快速开始

首先来定义一个非常简单粗暴的分词函数，它只是把输入拆分成2字词语的组合。

-- 创建分词函数，将字符串拆为单字，双字组成的词素数组
CREATE OR REPLACE FUNCTION tokens12(text) returns text[] AS $$
DECLARE
    res TEXT[];
BEGIN
    SELECT regexp_split_to_array($1, '') INTO res;
    FOR i in 1..length($1) - 1 LOOP
            res := array_append(res, substring($1, i, 2));
    END LOOP;
    RETURN res;
END;
$$ LANGUAGE plpgsql STRICT PARALLEL SAFE IMMUTABLE;

使用这个分词函数，可以将一个应用名称肢解为一系列的语素

SELECT tokens2('艾米莉的埃及历险记');
-- {艾米,米莉,莉的,的埃,埃及,及历,历险,险记}

现在假设用户搜索关键词“艾米利”，这个关键词被拆分为：

SELECT tokens2('艾米莉');
-- {艾米,米莉}

然后，我们可以通过以下查询非常迅速地，找到所有包含这两个关键词素的记录：

SELECT * FROM app WHERE tokens2(name) @> tokens2('艾米莉');
 美味餐厅 - 艾米莉的圣诞颂歌
 美味餐厅 - 艾米莉的瓶中信笺
 小清新艾米莉
 艾米莉的埃及历险记
 艾米莉的极地大冒险
 艾米莉的万圣节历险记
 6rows / 0.38ms

这里通过关键词数组的倒排索引，可以快速实现前后模糊的效果。

这里的条件比较严格，应用需要完整的包含两个关键词才会匹配。

如果我们改用更宽松的条件来执行模糊查询，例如，只要包含任意一个语素：

SELECT * FROM app WHERE tokens2(name) && tokens2('艾米莉');

 AR艾米互动故事-智慧妈妈必备
 Amy and train 艾米和小火车
 米莉·马洛塔的涂色探索
 给利伴_艾米罗公司旗下专业购物返利网
 艾米团购
 记忆游戏 - 米莉和泰迪
 (56 row ) / 0.4 ms

那么可供近一步筛选的应用候选集就更宽泛了。同时执行时间也并没有发生巨大的变化。

更近一步，我们并不需要在查询中使用完全一致的分词逻辑，完全可以手工进行精密的查询控制。

我们完全可以通过数组的布尔运算，控制哪些关键词是我们想要的，哪些是不想要的，哪些可选，哪些必须。

-- 包含关键词 微信、红包，但不包含 ‘支付’ (1ms | 11 rows)
SELECT * FROM app WHERE tokens2(name) @> ARRAY['微信','红包'] 
AND NOT tokens2(name) @> ARRAY['支付'];

当然，也可以对返回的结果进行相似度排序。一种常用的字符串似度衡量是L式编辑距离，即一个字符串最少需要多少次单字编辑才能变为另一个字符串。这个距离函数levenshtein 在PG的官方扩展包fuzzystrmatch中提供。

-- 包含关键词 微信 的应用，按照L式编辑距离排序 ( 1.1 ms | 10 rows)
-- create extension fuzzystrmatch;
SELECT name, levenshtein(name, '微信') AS d 
FROM app WHERE tokens12(name) @> ARRAY['微信'] 
ORDER BY 2 LIMIT 10;

 微信           | 0
 微信读书       | 2
 微信趣图       | 2
 微信加密       | 2
 企业微信       | 2
 微信通助手     | 3
 微信彩色消息   | 4
 艺术微信平台网 | 5
 涂鸦画板- 微信 | 6
 手写板for微信  | 6

改进全文检索方式

接下来，我们可以对分词的方式进行一些改进：

缩小关键词范围：将标点符号从关键词中移除，将语气助词（的得地，啊唔之乎者也）之类排除掉。（可选）
扩大关键词列表：将已有关键词的汉语拼音，首字母缩写一并加入关键词列表。
优化关键词大小：针对单字，3字短语，4字成语进行提取与优化。中文不同于英文，英文拆分为3字符的小串效果很好，中文信息密度更大，单字或双字就有很大的区分度了。
去除重复关键词：例如前后重复出现，或者通假字，同义词之类的。
跨语言分词处理，例如中西夹杂的名称，我们可以分别对中英文进行处理，中日韩字符采用中式分词处理逻辑，英文字母使用常规的pg_trgm处理逻辑。

实际上也不一定用得着这些逻辑，而这些逻辑也不一定非要在数据库里用存储过程实现。比较好的方式当然是在外部读取数据库然后使用专用的分词库和自定义业务逻辑来进行分词，分完之后再回写到数据表的另一列上。

当然这里出于演示目的，我们就直接用存储过程直接上了，实现一个比较简单的改进版分词逻辑。

CREATE OR REPLACE FUNCTION cjk_to_tsvector(_src text) RETURNS tsvector AS $$
DECLARE
    res TEXT[]:= show_trgm(_src);
    cjk TEXT; -- 中日韩连续文本段
BEGIN
    FOR cjk IN SELECT unnest(i) FROM regexp_matches(_src,'[\u4E00-\u9FCC\u3400-\u4DBF\u20000-\u2A6D6\u2A700-\u2B81F\u2E80-\u2FDF\uF900-\uFA6D\u2F800-\u2FA1B]+','g') regex(i) LOOP
            FOR i in 1..length(cjk) - 1 LOOP
                    res := array_append(res, substring(cjk, i, 2));
                END LOOP; -- 将每个中日韩连续文本段两字词语加入列表
        END LOOP;
    return array_to_tsvector(res);
end
$$ LANGUAGE PlPgSQL PARALLEL SAFE COST 100 STRICT IMMUTABLE;


-- 如果需要使用标签数组的方式，可以使用此函数。
CREATE OR REPLACE FUNCTION cjk_to_array(_src text) RETURNS TEXT[] AS $$
BEGIN
    RETURN tsvector_to_array(cjk_to_tsvector(_src));
END
$$ LANGUAGE PlPgSQL PARALLEL SAFE COST 100 STRICT IMMUTABLE;

-- 创建分词专用函数索引
CREATE INDEX ON app USING GIN(cjk_to_array(name));

基于 tsvector

除了基于数组的运算之外，PostgreSQL还提供了tsvector与tsquery类型，用于全文检索。

我们可以使用这两种类型的运算取代数组之间的运算，写出更灵活的查询来：

CREATE OR REPLACE FUNCTION to_tsvector123(src text) RETURNS tsvector AS $$
DECLARE
    res TEXT[];
    n INTEGER:= length(src);
begin
    SELECT regexp_split_to_array(src, '') INTO res;
    FOR i in 1..n - 2 LOOP res := array_append(res, substring(src, i, 2));res := array_append(res, substring(src, i, 3)); END LOOP;
    res := array_append(res, substring(src, n-1, 2));
    SELECT array_agg(distinct i) INTO res FROM (SELECT i FROM unnest(res) r(i) EXCEPT SELECT * FROM (VALUES(' '),('，'),('的'),('。'),('-'),('.')) c ) d; -- optional (normalize)
    RETURN array_to_tsvector(res);
end
$$ LANGUAGE PlPgSQL PARALLEL SAFE COST 100 STRICT IMMUTABLE;

-- 使用自定义分词函数，创建函数表达式索引
CREATE INDEX ON app USING GIN(to_tsvector123(name));

使用tsvector进行查询的方式也相当直观

-- 包含 '学英语' 和 '雅思'
SELECT * from app where to_tsvector123(name) @@ '学英语 & 雅思'::tsquery;

-- 所有关于 'BTC' 但不含'钱包' '交易'字样的应用
SELECT * from app where to_tsvector123(name) @@ 'BTC &! 钱包 & ! 交易 '::tsquery;

参考文章：

PostgreSQL 模糊查询最佳实践 - (含单字、双字、多字模糊查询方法)

https://developer.aliyun.com/article/672293

PgSQL JsonPath

有了JSONPATH，PostgreSQL用户就能以一种简洁而高效的方式操作JSON数据。

著： 冯若航（@Vonng） | 2019-11-12

PostgreSQL 12 JSON

PostgreSQL 12 已经正式放出了Beta1测试版本。PostgreSQL12带来了很多给力的新功能，其中最有吸引力的特性之一莫过于新的JSONPATH支持。在以前的版本中，虽说PostgreSQL在JSON功能的支持上已经很不错了，但要实现一些特定的功能，还是需要写复杂难懂的SQL或者存储过程才能实现。

有了JSONPATH，PostgreSQL用户就能以一种简洁而高效的方式操作JSON数据。

8.14.6 jsonpath类型

该jsonpath类型实现了对PostgreSQL中 SQL / JSON路径语言的支持，以有效地查询JSON数据。它提供了已解析的SQL / JSON路径表达式的二进制表示，该表达式指定路径引擎从JSON数据中检索的项目，以便使用SQL / JSON查询函数进行进一步处理。

SQL / JSON路径语言完全集成到SQL引擎中：其谓词和运算符的语义通常遵循SQL。同时，为了提供一种最自然的JSON数据处理方式，SQL / JSON路径语法使用了一些JavaScript约定：

Dot .用于成员访问。
方括号[]用于数组访问。
SQL / JSON数组是0相对的，不像从1开始的常规SQL数组。

SQL / JSON路径表达式是SQL字符串文字，因此在传递给SQL / JSON查询函数时必须用单引号括起来。遵循JavaScript约定，路径表达式中的字符串文字必须用双引号括起来。此字符串文字中的任何单引号必须使用SQL约定的单引号进行转义。

路径表达式由一系列路径元素组成，可以是以下内容：

JSON基元类型的路径文字：Unicode文本，数字，true，false或null。
路径变量列于表8.24。
表8.25中列出了访问者运算符。
jsonpath第9.15.1.2节中列出的运算符和方法
括号，可用于提供过滤器表达式或定义路径评估的顺序。

有关在jsonpathSQL / JSON查询函数中使用表达式的详细信息，请参见第9.15.1节。

表8.24。 jsonpath变量

变量	描述
`$`	表示要查询的JSON文本的变量（上下文项）。
`$varname`	一个命名变量。其值必须在`PASSING`SQL / JSON查询函数的子句中设置。详情。
`@`	表示过滤器表达式中路径评估结果的变量。

表8.25。 jsonpath访问器

访问者操作员	描述
.key``."$varname"	成员访问器，返回具有指定键的对象成员。如果键名是以符号`$`或不符合标识符的JavaScript规则的命名变量，则必须将其括在双引号中作为字符串文字。
`.*`	通配符成员访问器，返回位于当前对象顶级的所有成员的值。
`.**`	递归通配符成员访问器，它处理当前对象的所有级别的JSON层次结构，并返回所有成员值，而不管其嵌套级别如何。这是SQL / JSON标准的PostgreSQL扩展。
.*{level}``.{lower_level* toupper_level}``.*{lower_level* to last}	与`.**`，但是使用JSON层次结构的嵌套级别进行过滤。级别指定为整数。零级别对应于当前对象。这是SQL / JSON标准的PostgreSQL扩展。
`[subscript, ...]`	数组元素访问器。`subscript`可能有两种形式：`expr`或。第一种形式通过索引指定单个数组元素。第二种形式通过索引范围指定数组切片。零索引对应于第一个数组元素。`lower_expr to upper_expr`下标中的表达式可以包括整数，数值表达式或`jsonpath`返回单个数值的任何其他表达式。的`last`关键字可以在表达式表示在阵列中的最后一个下标来使用。这对处理未知长度的数组很有帮助。
`[*]`	返回所有数组元素的通配符数组元素访问器。

[6]为此，术语 “ 值 ”包括数组元素，尽管JSON术语有时会认为数组元素与对象内的值不同。

PgSQL事务隔离等级

PostgreSQL实际上只有两种事务隔离等级：读已提交（Read Commited）与可序列化（Serializable）

著： 冯若航（@Vonng） | 2019-11-12

PostgreSQL 事务隔离等级

基础

SQL标准定义了四种隔离级别，但PostgreSQL实际上只有两种事务隔离等级：读已提交（Read Commited）与可序列化（Serializable）

SQL标准定义了四种隔离级别，但实际上这也是很粗鄙的一种划分。详情请参考并发异常那些事。

查看/设置事务隔离等级

通过执行：SELECT current_setting('transaction_isolation'); 可以查看当前事务隔离等级。

通过在事务块顶部执行 SET TRANSACTION ISOLATION LEVEL { SERIALIZABLE | REPEATABLE READ | READ COMMITTED | READ UNCOMMITTED } 来设定事务的隔离等级。

或者为当前会话生命周期设置事务隔离等级：

SET SESSION CHARACTERISTICS AS TRANSACTION transaction_mode

Actual isolation level	P4	G-single	G2-item	G2
RC（monotonic atomic views）	-	-	-	-
RR（snapshot isolation）	✓	✓	-	-
Serializable	✓	✓	✓	✓

隔离等级与并发问题

创建测试表 t ，并插入两行测试数据。

CREATE TABLE t (k INTEGER PRIMARY KEY, v int);
TRUNCATE t; INSERT INTO t VALUES (1,10), (2,20);

更新丢失（P4）

PostgreSQL的 读已提交RC 隔离等级无法阻止丢失更新的问题，但可重复读隔离等级则可以。

丢失更新，顾名思义，就是一个事务的写入覆盖了另一个事务的写入结果。

在读已提交隔离等级下，无法阻止丢失更新的问题，考虑一个计数器并发更新的例子，两个事务同时从计数器中读取出值，加1后写回原表。

T1	T2	Comment
`begin;`
	`begin;`
`SELECT v FROM t WHERE k = 1`		T1读
	`SELECT v FROM t WHERE k = 1`	T2读
`update t set v = 11 where k = 1;`		T1写
	`update t set v = 11 where k = 1;`	T2因T1阻塞
`COMMIT`		T2恢复，写入
	`COMMIT`	T2写入覆盖T1

解决这个问题有两种方式，使用原子操作，或者在可重复读的隔离等级执行事务。

使用原子操作的方式为：

T1	T2	Comment
`begin;`
	`begin;`
`update t set v = v+1 where k = 1;`		T1写
	`update t set v = v + 1 where k = 1;`	T2因T1阻塞
`COMMIT`		T2恢复，写入
	`COMMIT`	T2写入覆盖T1

解决这个问题有两种方式，使用原子操作，或者在可重复读的隔离等级执行事务。

在可重复读的隔离等级

读已提交（RC）

begin; set transaction isolation level read committed; -- T1
begin; set transaction isolation level read committed; -- T2

update t set v = 11 where k = 1; -- T1
update t set v = 12 where k = 1; -- T2, BLOCKS
update t set v = 21 where k = 2; -- T1

commit; -- T1. This unblocks T2
select * from t; -- T1. Shows 1 => 11, 2 => 21
update t set v = 22 where k = 2; -- T2


commit; -- T2
select * from test; -- either. Shows 1 => 12, 2 => 22

T1	T2	Comment
`begin; set transaction isolation level read committed;`
	`begin; set transaction isolation level read committed;`
`update t set v = 11 where k = 1;`
	`update t set v = 12 where k = 1;`	T2会等待T1持有的锁
`SELECT * FROM t`		2:20, 1:11
`update pair set v = 21 where k = 2;`
`commit;`		T2解锁
	`select * from pair;`	T2看见T1的结果和自己的修改
	`update t set v = 22 where k = 2`
	`commit`

提交后的结果

 relname | locktype | virtualtransaction |  pid  |       mode       | granted | fastpath
---------+----------+--------------------+-------+------------------+---------+----------
 t_pkey  | relation | 4/578              | 37670 | RowExclusiveLock | t       | t
 t       | relation | 4/578              | 37670 | RowExclusiveLock | t       | t

 relname | locktype | virtualtransaction |  pid  |       mode       | granted | fastpath
---------+----------+--------------------+-------+------------------+---------+----------
 t_pkey  | relation | 4/578              | 37670 | RowExclusiveLock | t       | t
 t       | relation | 4/578              | 37670 | RowExclusiveLock | t       | t
 t_pkey  | relation | 6/494              | 37672 | RowExclusiveLock | t       | t
 t       | relation | 6/494              | 37672 | RowExclusiveLock | t       | t
 t       | tuple    | 6/494              | 37672 | ExclusiveLock    | t       | f

 relname | locktype | virtualtransaction |  pid  |       mode       | granted | fastpath
---------+----------+--------------------+-------+------------------+---------+----------
 t_pkey  | relation | 4/578              | 37670 | RowExclusiveLock | t       | t
 t       | relation | 4/578              | 37670 | RowExclusiveLock | t       | t
 t_pkey  | relation | 6/494              | 37672 | RowExclusiveLock | t       | t
 t       | relation | 6/494              | 37672 | RowExclusiveLock | t       | t
 t       | tuple    | 6/494              | 37672 | ExclusiveLock    | t       | f

Testing PostgreSQL transaction isolation levels

These tests were run with Postgres 9.3.5.

Setup (before every test case):

create table test (id int primary key, value int);
insert into test (id, value) values (1, 10), (2, 20);

To see the current isolation level:

select current_setting('transaction_isolation');

Read Committed basic requirements (G0, G1a, G1b, G1c)

Postgres “read committed” prevents Write Cycles (G0) by locking updated rows:

begin; set transaction isolation level read committed; -- T1
begin; set transaction isolation level read committed; -- T2
update test set value = 11 where id = 1; -- T1
update test set value = 12 where id = 1; -- T2, BLOCKS
update test set value = 21 where id = 2; -- T1
commit; -- T1. This unblocks T2
select * from test; -- T1. Shows 1 => 11, 2 => 21
update test set value = 22 where id = 2; -- T2
commit; -- T2
select * from test; -- either. Shows 1 => 12, 2 => 22

Postgres “read committed” prevents Aborted Reads (G1a):

begin; set transaction isolation level read committed; -- T1
begin; set transaction isolation level read committed; -- T2
update test set value = 101 where id = 1; -- T1
select * from test; -- T2. Still shows 1 => 10
abort;  -- T1
select * from test; -- T2. Still shows 1 => 10
commit; -- T2

Postgres “read committed” prevents Intermediate Reads (G1b):

begin; set transaction isolation level read committed; -- T1
begin; set transaction isolation level read committed; -- T2
update test set value = 101 where id = 1; -- T1
select * from test; -- T2. Still shows 1 => 10
update test set value = 11 where id = 1; -- T1
commit; -- T1
select * from test; -- T2. Now shows 1 => 11
commit; -- T2

Postgres “read committed” prevents Circular Information Flow (G1c):

begin; set transaction isolation level read committed; -- T1
begin; set transaction isolation level read committed; -- T2
update test set value = 11 where id = 1; -- T1
update test set value = 22 where id = 2; -- T2
select * from test where id = 2; -- T1. Still shows 2 => 20
select * from test where id = 1; -- T2. Still shows 1 => 10
commit; -- T1
commit; -- T2

Observed Transaction Vanishes (OTV)

Postgres “read committed” prevents Observed Transaction Vanishes (OTV):

begin; set transaction isolation level read committed; -- T1
begin; set transaction isolation level read committed; -- T2
begin; set transaction isolation level read committed; -- T3
update test set value = 11 where id = 1; -- T1
update test set value = 19 where id = 2; -- T1
update test set value = 12 where id = 1; -- T2. BLOCKS
commit; -- T1. This unblocks T2
select * from test where id = 1; -- T3. Shows 1 => 11
update test set value = 18 where id = 2; -- T2
select * from test where id = 2; -- T3. Shows 2 => 19
commit; -- T2
select * from test where id = 2; -- T3. Shows 2 => 18
select * from test where id = 1; -- T3. Shows 1 => 12
commit; -- T3

Predicate-Many-Preceders (PMP)

Postgres “read committed” does not prevent Predicate-Many-Preceders (PMP):

begin; set transaction isolation level read committed; -- T1
begin; set transaction isolation level read committed; -- T2
select * from test where value = 30; -- T1. Returns nothing
insert into test (id, value) values(3, 30); -- T2
commit; -- T2
select * from test where value % 3 = 0; -- T1. Returns the newly inserted row
commit; -- T1

Postgres “repeatable read” prevents Predicate-Many-Preceders (PMP):

begin; set transaction isolation level repeatable read; -- T1
begin; set transaction isolation level repeatable read; -- T2
select * from test where value = 30; -- T1. Returns nothing
insert into test (id, value) values(3, 30); -- T2
commit; -- T2
select * from test where value % 3 = 0; -- T1. Still returns nothing
commit; -- T1

Postgres “read committed” does not prevent Predicate-Many-Preceders (PMP) for write predicates – example from Postgres documentation:

begin; set transaction isolation level read committed; -- T1
begin; set transaction isolation level read committed; -- T2
update test set value = value + 10; -- T1
delete from test where value = 20;  -- T2, BLOCKS
commit; -- T1. This unblocks T2
select * from test where value = 20; -- T2, returns 1 => 20 (despite ostensibly having been deleted)
commit; -- T2

Postgres “repeatable read” prevents Predicate-Many-Preceders (PMP) for write predicates – example from Postgres documentation:

begin; set transaction isolation level repeatable read; -- T1
begin; set transaction isolation level repeatable read; -- T2
update test set value = value + 10; -- T1
delete from test where value = 20;  -- T2, BLOCKS
commit; -- T1. T2 now prints out "ERROR: could not serialize access due to concurrent update"
abort;  -- T2. There's nothing else we can do, this transaction has failed

Lost Update (P4)

Postgres “read committed” does not prevent Lost Update (P4):

begin; set transaction isolation level read committed; -- T1
begin; set transaction isolation level read committed; -- T2
select * from test where id = 1; -- T1
select * from test where id = 1; -- T2
update test set value = 11 where id = 1; -- T1
update test set value = 11 where id = 1; -- T2, BLOCKS
commit; -- T1. This unblocks T2, so T1's update is overwritten
commit; -- T2

Postgres “repeatable read” prevents Lost Update (P4):

begin; set transaction isolation level repeatable read; -- T1
begin; set transaction isolation level repeatable read; -- T2
select * from test where id = 1; -- T1
select * from test where id = 1; -- T2
update test set value = 11 where id = 1; -- T1
update test set value = 11 where id = 1; -- T2, BLOCKS
commit; -- T1. T2 now prints out "ERROR: could not serialize access due to concurrent update"
abort;  -- T2. There's nothing else we can do, this transaction has failed

Read Skew (G-single)

Postgres “read committed” does not prevent Read Skew (G-single):

begin; set transaction isolation level read committed; -- T1
begin; set transaction isolation level read committed; -- T2
select * from test where id = 1; -- T1. Shows 1 => 10
select * from test where id = 1; -- T2
select * from test where id = 2; -- T2
update test set value = 12 where id = 1; -- T2
update test set value = 18 where id = 2; -- T2
commit; -- T2
select * from test where id = 2; -- T1. Shows 2 => 18
commit; -- T1

Postgres “repeatable read” prevents Read Skew (G-single):

begin; set transaction isolation level repeatable read; -- T1
begin; set transaction isolation level repeatable read; -- T2
select * from test where id = 1; -- T1. Shows 1 => 10
select * from test where id = 1; -- T2
select * from test where id = 2; -- T2
update test set value = 12 where id = 1; -- T2
update test set value = 18 where id = 2; -- T2
commit; -- T2
select * from test where id = 2; -- T1. Shows 2 => 20
commit; -- T1

Postgres “repeatable read” prevents Read Skew (G-single) – test using predicate dependencies:

begin; set transaction isolation level repeatable read; -- T1
begin; set transaction isolation level repeatable read; -- T2
select * from test where value % 5 = 0; -- T1
update test set value = 12 where value = 10; -- T2
commit; -- T2
select * from test where value % 3 = 0; -- T1. Returns nothing
commit; -- T1

Postgres “repeatable read” prevents Read Skew (G-single) – test using write predicate:

begin; set transaction isolation level repeatable read; -- T1
begin; set transaction isolation level repeatable read; -- T2
select * from test where id = 1; -- T1. Shows 1 => 10
select * from test; -- T2
update test set value = 12 where id = 1; -- T2
update test set value = 18 where id = 2; -- T2
commit; -- T2
delete from test where value = 20; -- T1. Prints "ERROR: could not serialize access due to concurrent update"
abort; -- T1. There's nothing else we can do, this transaction has failed

Write Skew (G2-item)

Postgres “repeatable read” does not prevent Write Skew (G2-item):

begin; set transaction isolation level repeatable read; -- T1
begin; set transaction isolation level repeatable read; -- T2
select * from test where id in (1,2); -- T1
select * from test where id in (1,2); -- T2
update test set value = 11 where id = 1; -- T1
update test set value = 21 where id = 2; -- T2
commit; -- T1
commit; -- T2

Postgres “serializable” prevents Write Skew (G2-item):

begin; set transaction isolation level serializable; -- T1
begin; set transaction isolation level serializable; -- T2
select * from test where id in (1,2); -- T1
select * from test where id in (1,2); -- T2
update test set value = 11 where id = 1; -- T1
update test set value = 21 where id = 2; -- T2
commit; -- T1
commit; -- T2. Prints out "ERROR: could not serialize access due to read/write dependencies among transactions"

Anti-Dependency Cycles (G2)

Postgres “repeatable read” does not prevent Anti-Dependency Cycles (G2):

begin; set transaction isolation level repeatable read; -- T1
begin; set transaction isolation level repeatable read; -- T2
select * from test where value % 3 = 0; -- T1
select * from test where value % 3 = 0; -- T2
insert into test (id, value) values(3, 30); -- T1
insert into test (id, value) values(4, 42); -- T2
commit; -- T1
commit; -- T2
select * from test where value % 3 = 0; -- Either. Returns 3 => 30, 4 => 42

Postgres “serializable” prevents Anti-Dependency Cycles (G2):

begin; set transaction isolation level serializable; -- T1
begin; set transaction isolation level serializable; -- T2
select * from test where value % 3 = 0; -- T1
select * from test where value % 3 = 0; -- T2
insert into test (id, value) values(3, 30); -- T1
insert into test (id, value) values(4, 42); -- T2
commit; -- T1
commit; -- T2. Prints out "ERROR: could not serialize access due to read/write dependencies among transactions"

Postgres “serializable” prevents Anti-Dependency Cycles (G2) – Fekete et al’s example with two anti-dependency edges:

begin; set transaction isolation level serializable; -- T1
select * from test; -- T1. Shows 1 => 10, 2 => 20
begin; set transaction isolation level serializable; -- T2
update test set value = value + 5 where id = 2; -- T2
commit; -- T2
begin; set transaction isolation level serializable; -- T3
select * from test; -- T3. Shows 1 => 10, 2 => 25
commit; -- T3
update test set value = 0 where id = 1; -- T1. Prints out "ERROR: could not serialize access due to read/write dependencies among transactions"
abort; -- T1. There's nothing else we can do, this transaction has failed

PgSQL前后端通信协议

了解PostgreSQL服务器与客户端通信使用的TCP协议

著： 冯若航（@Vonng） | 2019-11-12

了解PostgreSQL服务器与客户端通信使用的TCP协议

启动阶段

基本流程

客户端发送一条StartupMessage (F)向服务端发起连接请求

载荷包括0x30000的Int32版本号魔数，以及一系列kv结构的运行时参数（NULL0分割，必须参数为user），
客户端等待服务端响应，主要是等待服务端发送的ReadyForQuery (Z)事件，该事件代表服务端已经准备好接收请求。

上面是连接建立过程中最主要的两个事件，其他事件包括包括认证消息 AuthenticationXXX (R) ，后端密钥消息 BackendKeyData (K)，错误消息ErrorResponse (E)，一系列上下文无关消息（NoticeResponse (N)，NotificationResponse (A)，ParameterStatus(S)）

模拟客户端

编写一个go程序模拟这一过程

package main

import (
	"fmt"
	"net"
	"time"

	"github.com/jackc/pgx/pgproto3"
)

func GetFrontend(address string) *pgproto3.Frontend {
	conn, _ := (&net.Dialer{KeepAlive: 5 * time.Minute}).Dial("tcp4", address)
	frontend, _ := pgproto3.NewFrontend(conn, conn)
	return frontend
}

func main() {
	frontend := GetFrontend("127.0.0.1:5432")

	// 建立连接
	startupMsg := &pgproto3.StartupMessage{
		ProtocolVersion: pgproto3.ProtocolVersionNumber,
		Parameters:      map[string]string{"user": "vonng"},
	}
	frontend.Send(startupMsg)

	// 启动过程，收到ReadyForQuery消息代表启动过程结束
	for {
		msg, _ := frontend.Receive()
		fmt.Printf("%T %v\n", msg, msg)
		if _, ok := msg.(*pgproto3.ReadyForQuery); ok {
			fmt.Println("[STARTUP] connection established")
			break
		}
	}

	// 简单查询协议
	simpleQueryMsg := &pgproto3.Query{String: `SELECT 1 as a;`}
	frontend.Send(simpleQueryMsg)
	// 收到CommandComplete消息代表查询结束
	for {
		msg, _ := frontend.Receive()
		fmt.Printf("%T %v\n", msg, msg)
		if _, ok := msg.(*pgproto3.CommandComplete); ok {
			fmt.Println("[QUERY] query complete")
			break
		}
	}
}

输出结果为：

*pgproto3.Authentication &{0 [0 0 0 0] [] []}
*pgproto3.ParameterStatus &{application_name }
*pgproto3.ParameterStatus &{client_encoding UTF8}
*pgproto3.ParameterStatus &{DateStyle ISO, MDY}
*pgproto3.ParameterStatus &{integer_datetimes on}
*pgproto3.ParameterStatus &{IntervalStyle postgres}
*pgproto3.ParameterStatus &{is_superuser on}
*pgproto3.ParameterStatus &{server_encoding UTF8}
*pgproto3.ParameterStatus &{server_version 11.3}
*pgproto3.ParameterStatus &{session_authorization vonng}
*pgproto3.ParameterStatus &{standard_conforming_strings on}
*pgproto3.ParameterStatus &{TimeZone PRC}
*pgproto3.BackendKeyData &{35703 345830596}
*pgproto3.ReadyForQuery &{73}
[STARTUP] connection established
*pgproto3.RowDescription &{[{a 0 0 23 4 -1 0}]}
*pgproto3.DataRow &{[[49]]}
*pgproto3.CommandComplete &{SELECT 1}
[QUERY] query complete

连接代理

可以在jackc/pgx/pgproto3的基础上，很轻松地编写一些中间件。例如下面的代码就是一个非常简单的“连接代理”：

package main

import (
	"io"
	"net"
	"strings"
	"time"

	"github.com/jackc/pgx/pgproto3"
)

type ProxyServer struct {
	UpstreamAddr string
	ListenAddr   string
	Listener     net.Listener
	Dialer       net.Dialer
}

func NewProxyServer(listenAddr, upstreamAddr string) *ProxyServer {
	ln, _ := net.Listen(`tcp4`, listenAddr)
	return &ProxyServer{
		ListenAddr:   listenAddr,
		UpstreamAddr: upstreamAddr,
		Listener:     ln,
		Dialer:       net.Dialer{KeepAlive: 1 * time.Minute},
	}
}

func (ps *ProxyServer) Serve() error {
	for {
		conn, err := ps.Listener.Accept()
		if err != nil {
			panic(err)
		}
		go ps.ServeOne(conn)
	}
}

func (ps *ProxyServer) ServeOne(clientConn net.Conn) error {
	backend, _ := pgproto3.NewBackend(clientConn, clientConn)
	startupMsg, err := backend.ReceiveStartupMessage()
	if err != nil && strings.Contains(err.Error(), "ssl") {
		if _, err := clientConn.Write([]byte(`N`)); err != nil {
			panic(err)
		}
		// ssl is not welcome, now receive real startup msg
		startupMsg, err = backend.ReceiveStartupMessage()
		if err != nil {
			panic(err)
		}
	}

	serverConn, _ := ps.Dialer.Dial(`tcp4`, ps.UpstreamAddr)
	frontend, _ := pgproto3.NewFrontend(serverConn, serverConn)
	frontend.Send(startupMsg)

	errChan := make(chan error, 2)
	go func() {
		_, err := io.Copy(clientConn, serverConn)
		errChan <- err
	}()
	go func() {
		_, err := io.Copy(serverConn, clientConn)
		errChan <- err
	}()

	return <-errChan
}

func main() {
	proxy := NewProxyServer("127.0.0.1:5433", "127.0.0.1:5432")
	proxy.Serve()
}

这里代理监听5433端口，并将消息解析并转发至在5432端口的真实的数据库服务器。在另一个Session中执行以下命令：

$ psql postgres://127.0.0.1:5433/data?sslmode=disable -c 'SELECT * FROM pg_stat_activity LIMIT 1;'

可以观察到这一过程中的消息往来：

[B2F] *pgproto3.ParameterStatus &{application_name psql}
[B2F] *pgproto3.ParameterStatus &{client_encoding UTF8}
[B2F] *pgproto3.ParameterStatus &{DateStyle ISO, MDY}
[B2F] *pgproto3.ParameterStatus &{integer_datetimes on}
[B2F] *pgproto3.ParameterStatus &{IntervalStyle postgres}
[B2F] *pgproto3.ParameterStatus &{is_superuser on}
[B2F] *pgproto3.ParameterStatus &{server_encoding UTF8}
[B2F] *pgproto3.ParameterStatus &{server_version 11.3}
[B2F] *pgproto3.ParameterStatus &{session_authorization vonng}
[B2F] *pgproto3.ParameterStatus &{standard_conforming_strings on}
[B2F] *pgproto3.ParameterStatus &{TimeZone PRC}
[B2F] *pgproto3.BackendKeyData &{41588 1354047533}
[B2F] *pgproto3.ReadyForQuery &{73}
[F2B] *pgproto3.Query &{SELECT * FROM pg_stat_activity LIMIT 1;}
[B2F] *pgproto3.RowDescription &{[{datid 11750 1 26 4 -1 0} {datname 11750 2 19 64 -1 0} {pid 11750 3 23 4 -1 0} {usesysid 11750 4 26 4 -1 0} {usename 11750 5 19 64 -1 0} {application_name 11750 6 25 -1 -1 0} {client_addr 11750 7 869 -1 -1 0} {client_hostname 11750 8 25 -1 -1 0} {client_port 11750 9 23 4 -1 0} {backend_start 11750 10 1184 8 -1 0} {xact_start 11750 11 1184 8 -1 0} {query_start 11750 12 1184 8 -1 0} {state_change 11750 13 1184 8 -1 0} {wait_event_type 11750 14 25 -1 -1 0} {wait_event 11750 15 25 -1 -1 0} {state 11750 16 25 -1 -1 0} {backend_xid 11750 17 28 4 -1 0} {backend_xmin 11750 18 28 4 -1 0} {query 11750 19 25 -1 -1 0} {backend_type 11750 20 25 -1 -1 0}]}
[B2F] *pgproto3.DataRow &{[[] [] [52 56 55 52] [] [] [] [] [] [] [50 48 49 57 45 48 53 45 49 56 32 50 48 58 52 56 58 49 57 46 51 50 55 50 54 55 43 48 56] [] [] [] [65 99 116 105 118 105 116 121] [65 117 116 111 86 97 99 117 117 109 77 97 105 110] [] [] [] [] [97 117 116 111 118 97 99 117 117 109 32 108 97 117 110 99 104 101 114]]}
[B2F] *pgproto3.CommandComplete &{SELECT 1}
[B2F] *pgproto3.ReadyForQuery &{73}
[F2B] *pgproto3.Terminate &{}

PgSQL变更数据捕获

数据变更捕获是一种很有趣的ETL替代方案。

著： 冯若航（@Vonng） | 2019-06-12

在实际生产中，我们经常需要把数据库的状态同步到其他地方去，例如同步到数据仓库进行分析，同步到消息队列供下游消费，同步到缓存以加速查询。总的来说，搬运状态有两大类方法：ETL与CDC。

前驱知识

CDC与ETL

数据库在本质上是一个状态集合，任何对数据库的变更（增删改）本质上都是对状态的修改。

ETL（ExtractTransformLoad）着眼于状态本身，用定时批量轮询的方式拉取状态本身。
CDC（ChangeDataCapture）则着眼于变更，以流式的方式持续收集状态变化事件（变更）。

ETL大家都耳熟能详，每天批量跑ETL任务，从生产OLTP数据库 拉取（E） ， 转换（T） 格式， 导入（L） 数仓，在此不赘述。相比ETL而言，CDC算是个新鲜玩意，随着流计算的崛起也越来越多地进入人们的视线。

变更数据捕获（change data capture, CDC）是一种观察写入数据库的所有数据变更，并将其提取并转换为可以复制到其他系统中的形式的过程。 CDC很有意思，特别是当变更能在被写入数据库后立刻用于后续的流处理时。

例如用户可以捕获数据库中的变更，并不断将相同的变更应用至搜索索引（e.g elasticsearch）。如果变更日志以相同的顺序应用，则可以预期的是，搜索索引中的数据与数据库中的数据是匹配的。同理，这些变更也可以应用于后台刷新缓存（redis），送往消息队列（Kafka），导入数据仓库（EventSourcing，存储不可变的事实事件记录而不是每天取快照），收集统计数据与监控（Prometheus），等等等等。在这种意义下，外部索引，缓存，数仓都成为了PostgreSQL在逻辑上的从库，这些衍生数据系统都成为了变更流的消费者，而PostgreSQL成为了整个数据系统的主库。在这种架构下，应用只需要操心怎样把数据写入数据库，剩下的事情交给CDC即可。系统设计可以得到极大地简化：所有的数据组件都能够自动与主库在逻辑上保证（最终）一致。用户不用再为如何保证多个异构数据系统之间数据同步而焦头烂额了。

实际上PostgreSQL自10.0版本以来提供的逻辑复制（logical replication）功能，实质上就是一个CDC应用：从主库上提取变更事件流：INSERT, UPDATE, DELETE, TRUNCATE，并在另一个PostgreSQL主库实例上重放。如果这些增删改事件能够被解析出来，它们就可以用于任何感兴趣的消费者，而不仅仅局限于另一个PostgreSQL实例。

逻辑复制

想在传统关系型数据库上实施CDC并不容易，关系型数据库本身的预写式日志WAL 实际上就是数据库中变更事件的记录。因此从数据库中捕获变更，基本上可以认为等价于消费数据库产生的WAL日志/复制日志。（当然也有其他的变更捕获方式，例如在表上建立触发器，当变更发生时将变更记录写入另一张变更日志表，客户端不断tail这张日志表，当然也有一定的局限性）。

大多数数据库的复制日志的问题在于，它们一直被当做数据库的内部实现细节，而不是公开的API。客户端应该通过其数据模型和查询语言来查询数据库，而不是解析复制日志并尝试从中提取数据。许多数据库根本没有记录在案的获取变更日志的方式。因此捕获数据库中所有的变更然后将其复制到其他状态存储（搜索索引，缓存，数据仓库）中是相当困难的。

此外，仅有数据库变更日志仍然是不够的。如果你拥有全量变更日志，当然可以通过重放日志来重建数据库的完整状态。但是在许多情况下保留全量历史WAL日志并不是可行的选择（例如磁盘空间与重放耗时的限制）。例如，构建新的全文索引需要整个数据库的完整副本 —— 仅仅应用最新的变更日志是不够的，因为这样会丢失最近没有更新过的项目。因此如果你不能保留完整的历史日志，那么你至少需要包留一个一致的数据库快照，并保留从该快照开始的变更日志。

因此实施CDC，数据库至少需要提供以下功能：

获取数据库的变更日志（WAL），并解码成逻辑上的事件（对表的增删改而不是数据库的内部表示）
获取数据库的"一致性快照"，从而订阅者可以从任意一个一致性状态开始订阅而不是数据库创建伊始。
保存消费者偏移量，以便跟踪订阅者的消费进度，及时清理回收不用的变更日志以免撑爆磁盘。

我们会发现，PostgreSQL在实现逻辑复制的同时，已经提供了一切CDC所需要的基础设施。

逻辑解码（Logical Decoding），用于从WAL日志中解析逻辑变更事件
复制协议（Replication Protocol）：提供了消费者实时订阅（甚至同步订阅）数据库变更的机制
快照导出（export snapshot）：允许导出数据库的一致性快照（pg_export_snapshot）
复制槽（Replication Slot），用于保存消费者偏移量，跟踪订阅者进度。

因此，在PostgreSQL上实施CDC最为直观优雅的方式，就是按照PostgreSQL的复制协议编写一个"逻辑从库" ，从数据库中实时地，流式地接受逻辑解码后的变更事件，完成自己定义的处理逻辑，并及时向数据库汇报自己的消息消费进度。就像使用Kafka一样。在这里CDC客户端可以将自己伪装成一个PostgreSQL的从库，从而不断地实时从PostgreSQL主库中接收逻辑解码后的变更内容。同时CDC客户端还可以通过PostgreSQL提供的复制槽（Replication Slot）机制来保存自己的消费者偏移量，即消费进度，实现类似消息队列一至少次的保证，保证不错过变更数据。(客户端自己记录消费者偏移量跳过重复记录，即可实现"恰好一次 “的保证 )

逻辑解码

在开始进一步的讨论之前，让我们先来看一看期待的输出结果到底是什么样子。

PostgreSQL的变更事件以二进制内部表示形式保存在预写式日志（WAL）中，使用其自带的pg_waldump工具可以解析出来一些人类可读的信息：

rmgr: Btree       len (rec/tot):     64/    64, tx:       1342, lsn: 2D/AAFFC9F0, prev 2D/AAFFC810, desc: INSERT_LEAF off 126, blkref #0: rel 1663/3101882/3105398 blk 4
rmgr: Heap        len (rec/tot):    485/   485, tx:       1342, lsn: 2D/AAFFCA30, prev 2D/AAFFC9F0, desc: INSERT off 10, blkref #0: rel 1663/3101882/3105391 blk 139

WAL日志里包含了完整权威的变更事件记录，但这种记录格式过于底层。用户并不会对磁盘上某个数据页里的二进制变更（文件A页面B偏移量C追加写入二进制数据D）感兴趣，他们感兴趣的是某张表中增删改了哪些行哪些字段。逻辑解码就是将物理变更记录翻译为用户期望的逻辑变更事件的机制（例如表A上的增删改事件）。

例如用户可能期望的是，能够解码出等价的SQL语句

INSERT INTO public.test (id, data) VALUES (14, 'hoho');

或者最为通用的JSON结构（这里以JSON格式记录了一条UPDATE事件）

{
  "change": [
    {
      "kind": "update",
      "schema": "public",
      "table": "test",
      "columnnames": ["id", "data" ],
      "columntypes": [ "integer", "text" ],
      "columnvalues": [ 1, "hoho"],
      "oldkeys": { "keynames": [ "id"],
        "keytypes": ["integer" ],
        "keyvalues": [1]
      }
    }
  ]
}

当然也可以是更为紧凑高效严格的Protobuf格式，更为灵活的Avro格式，抑或是任何用户感兴趣的格式。

逻辑解码 所要解决的问题，就是将数据库内部二进制表示的变更事件，解码（Decoding）成为用户感兴趣的格式。之所以需要这样一个过程，是因为数据库内部表示是非常紧凑的，想要解读原始的二进制WAL日志，不仅仅需要WAL结构相关的知识，还需要系统目录（System Catalog），即元数据。没有元数据就无从得知用户可能感兴趣的模式名，表名，列名，只能解析出来的一系列数据库自己才能看懂的oid。

关于流复制协议，复制槽，事务快照等概念与功能，这里就不展开了，让我们进入动手环节。

快速开始

假设我们有一张用户表，我们希望捕获任何发生在它上面的变更，假设数据库发生了如下变更操作

下面会重复用到这几条命令

DROP TABLE IF EXISTS users;
CREATE TABLE users(id SERIAL PRIMARY KEY, name TEXT);

INSERT INTO users VALUES (100, 'Vonng');
INSERT INTO users VALUES (101, 'Xiao Wang');
DELETE FROM users WHERE id = 100;
UPDATE users SET name = 'Lao Wang' WHERE id = 101;

最终数据库的状态是：只有一条(101, 'Lao Wang')的记录。无论是曾经有一个名为Vonng的用户存在过的痕迹，抑或是隔壁老王也曾年轻过的事实，都随着对数据库的删改而烟消云散。我们希望这些事实不应随风而逝，需要被记录下来。

操作流程

通常来说，订阅变更需要以下几步操作：

选择一个一致性的数据库快照，作为订阅变更的起点。(创建一个复制槽)
(数据库发生了一些变更)
读取这些变更，更新自己的的消费进度。

那么，让我们先从最简单的办法开始，从PostgreSQL自带的的SQL接口开始

SQL接口

逻辑复制槽的增删查API：

TABLE pg_replication_slots; -- 查
pg_create_logical_replication_slot(slot_name name, plugin name) -- 增
pg_drop_replication_slot(slot_name name) -- 删

从逻辑复制槽中获取最新的变更数据：

pg_logical_slot_get_changes(slot_name name, ...)  -- 消费掉
pg_logical_slot_peek_changes(slot_name name, ...) -- 只查看不消费

在正式开始前，还需要对数据库参数做一些修改，修改wal_level = logical，这样在WAL日志中的信息才能足够用于逻辑解码。

-- 创建一个复制槽test_slot，使用系统自带的测试解码插件test_decoding，解码插件会在后面介绍
SELECT * FROM pg_create_logical_replication_slot('test_slot', 'test_decoding');

-- 重放上面的建表与增删改操作
-- DROP TABLE | CREATE TABLE | INSERT 1 | INSERT 1 | DELETE 1 | UPDATE 1

-- 读取复制槽test_slot中未消费的最新的变更事件流
SELECT * FROM  pg_logical_slot_get_changes('test_slot', NULL, NULL);
    lsn    | xid |                                data
-----------+-----+--------------------------------------------------------------------
 0/167C7E8 | 569 | BEGIN 569
 0/169F6F8 | 569 | COMMIT 569
 0/169F6F8 | 570 | BEGIN 570
 0/169F6F8 | 570 | table public.users: INSERT: id[integer]:100 name[text]:'Vonng'
 0/169F810 | 570 | COMMIT 570
 0/169F810 | 571 | BEGIN 571
 0/169F810 | 571 | table public.users: INSERT: id[integer]:101 name[text]:'Xiao Wang'
 0/169F8C8 | 571 | COMMIT 571
 0/169F8C8 | 572 | BEGIN 572
 0/169F8C8 | 572 | table public.users: DELETE: id[integer]:100
 0/169F938 | 572 | COMMIT 572
 0/169F970 | 573 | BEGIN 573
 0/169F970 | 573 | table public.users: UPDATE: id[integer]:101 name[text]:'Lao Wang'
 0/169F9F0 | 573 | COMMIT 573

-- 清理掉创建的复制槽
SELECT pg_drop_replication_slot('test_slot');

这里，我们可以看到一系列被触发的事件，其中每个事务的开始与提交都会触发一个事件。因为目前逻辑解码机制不支持DDL变更，因此CREATE TABLE与DROP TABLE并没有出现在事件流中，只能看到空荡荡的BEGIN+COMMIT。另一点需要注意的是，只有成功提交的事务才会产生逻辑解码变更事件。也就是说用户不用担心收到并处理了很多行变更消息之后，最后发现事务回滚了，还需要担心怎么通知消费者去会跟变更。

通过SQL接口，用户已经能够拉取最新的变更了。这也就意味着任何有着PostgreSQL驱动的语言都可以通过这种方式从数据库中捕获最新的变更。当然这种方式实话说还是略过于土鳖。更好的方式是利用PostgreSQL的复制协议直接从数据库中订阅变更数据流。当然相比使用SQL接口，这也需要更多的工作。

使用客户端接收变更

在编写自己的CDC客户端之前，让我们先来试用一下官方自带的CDC客户端样例——pg_recvlogical。与pg_receivewal类似，不过它接收的是逻辑解码后的变更，下面是一个具体的例子：

# 启动一个CDC客户端，连接数据库postgres，创建名为test_slot的槽，使用test_decoding解码插件，标准输出
pg_recvlogical \
	-d postgres \
	--create-slot --if-not-exists --slot=test_slot \
	--plugin=test_decoding \
	--start -f -

# 开启另一个会话，重放上面的建表与增删改操作
# DROP TABLE | CREATE TABLE | INSERT 1 | INSERT 1 | DELETE 1 | UPDATE 1

# pg_recvlogical输出结果
BEGIN 585
COMMIT 585
BEGIN 586
table public.users: INSERT: id[integer]:100 name[text]:'Vonng'
COMMIT 586
BEGIN 587
table public.users: INSERT: id[integer]:101 name[text]:'Xiao Wang'
COMMIT 587
BEGIN 588
table public.users: DELETE: id[integer]:100
COMMIT 588
BEGIN 589
table public.users: UPDATE: id[integer]:101 name[text]:'Lao Wang'
COMMIT 589

# 清理：删除创建的复制槽
pg_recvlogical -d postgres --drop-slot --slot=test_slot

上面的例子中，主要的变更事件包括事务的开始与结束，以及数据行的增删改。这里默认的test_decoding插件的输出格式为：

BEGIN {事务标识}
table {模式名}.{表名} {命令INSERT|UPDATE|DELETE}  {列名}[{类型}]:{取值} ...
COMMIT {事务标识}

实际上，PostgreSQL的逻辑解码是这样工作的，每当特定的事件发生（表的Truncate，行级别的增删改，事务开始与提交），PostgreSQL都会调用一系列的钩子函数。所谓的逻辑解码输出插件（Logical Decoding Output Plugin），就是这样一组回调函数的集合。它们接受二进制内部表示的变更事件作为输入，查阅一些系统目录，将二进制数据翻译成为用户感兴趣的结果。

逻辑解码输出插件

除了PostgreSQL自带的"用于测试"的逻辑解码插件：test_decoding 之外，还有很多现成的输出插件，例如：

JSON格式输出插件：wal2json
SQL格式输出插件：decoder_raw
Protobuf输出插件：decoderbufs

当然还有PostgreSQL自带逻辑复制所使用的解码插件：pgoutput，其消息格式文档地址。

安装这些插件非常简单，有一些插件（例如wal2json）可以直接从官方二进制源轻松安装。

yum install wal2json11
apt install postgresql-11-wal2json

或者如果没有二进制包，也可以自己下载编译。只需要确保pg_config已经在你的PATH中，然后执行make & sudo make install两板斧即可。以输出SQL格式的decoder_raw插件为例：

git clone https://github.com/michaelpq/pg_plugins && cd pg_plugins/decoder_raw
make && sudo make install

使用wal2json接收同样的变更

pg_recvlogical -d postgres --drop-slot --slot=test_slot
pg_recvlogical -d postgres --create-slot --if-not-exists --slot=test_slot \
	--plugin=wal2json --start -f -

结果为：

{"change":[]}
{"change":[{"kind":"insert","schema":"public","table":"users","columnnames":["id","name"],"columntypes":["integer","text"],"columnvalues":[100,"Vonng"]}]}
{"change":[{"kind":"insert","schema":"public","table":"users","columnnames":["id","name"],"columntypes":["integer","text"],"columnvalues":[101,"Xiao Wang"]}]}
{"change":[{"kind":"delete","schema":"public","table":"users","oldkeys":{"keynames":["id"],"keytypes":["integer"],"keyvalues":[100]}}]}
{"change":[{"kind":"update","schema":"public","table":"users","columnnames":["id","name"],"columntypes":["integer","text"],"columnvalues":[101,"Lao Wang"],"oldkeys":{"keynames":["id"],"keytypes":["integer"],"keyvalues":[101]}}]}

而使用decoder_raw获取SQL格式的输出

pg_recvlogical -d postgres --drop-slot --slot=test_slot
pg_recvlogical -d postgres --create-slot --if-not-exists --slot=test_slot \
	--plugin=decoder_raw --start -f -

结果为：

INSERT INTO public.users (id, name) VALUES (100, 'Vonng');
INSERT INTO public.users (id, name) VALUES (101, 'Xiao Wang');
DELETE FROM public.users WHERE id = 100;
UPDATE public.users SET id = 101, name = 'Lao Wang' WHERE id = 101;

decoder_raw可以用于抽取SQL形式表示的状态变更，将这些抽取得到的SQL语句在同样的基础状态上重放，即可得到相同的结果。PostgreSQL就是使用这样的机制实现逻辑复制的。

一个典型的应用场景就是数据库不停机迁移。在传统不停机迁移模式（双写，改读，改写）中，第三步改写完成后是无法快速回滚的，因为写入流量在切换至新主库后如果发现有问题想立刻回滚，老主库上会丢失一些数据。这时候就可以使用decoder_raw提取主库上的最新变更，并通过一行简单的Bash命令，将新主库上的变更实时同步到旧主库。保证迁移过程中任何时刻都可以快速回滚至老主库。

pg_recvlogical -d <new_master_url> --slot=test_slot --plugin=decoder_raw --start -f - |
psql <old_master_url>

另一个有趣的场景是UNDO LOG。PostgreSQL的故障恢复是基于REDO LOG的，通过重放WAL会到历史上的任意时间点。在数据库模式不发生变化的情况下，如果只是单纯的表内容增删改出现了失误，完全可以利用类似decoder_raw的方式反向生成UNDO日志。提高此类故障恢复的速度。

最后，输出插件可以将变更事件格式化为各种各样的形式。解码输出为Redis的kv操作，或者仅仅抽取一些关键字段用于更新统计数据或者构建外部索引，有着很大的想象空间。

编写自定义的逻辑解码输出插件并不复杂，可以参阅这篇官方文档。毕竟逻辑解码输出插件本质上只是一个拼字符串的回调函数集合。在官方样例的基础上稍作修改，即可轻松实现一个你自己的逻辑解码输出插件。

CDC客户端

PostgreSQL自带了一个名为pg_recvlogical的客户端应用，可以将逻辑变更的事件流写至标准输出。但并不是所有的消费者都可以或者愿意使用Unix Pipe来完成所有工作的。此外，根据端到端原则，使用pg_recvlogical将变更数据流落盘并不意味着消费者已经拿到并确认了该消息，只有消费者自己亲自向数据库确认才可以做到这一点。

编写PostgreSQL的CDC客户端程序，本质上是实现了一个"猴版”数据库从库。客户端向数据库建立一条复制连接（Replication Connection） ，将自己伪装成一个从库：从主库获取解码后的变更消息流，并周期性地向主库汇报自己的消费进度（落盘进度，刷盘进度，应用进度）。

复制连接

复制连接，顾名思义就是用于复制（Replication） 的特殊连接。当与PostgreSQL服务器建立连接时，如果连接参数中提供了replication=database|on|yes|1，就会建立一条复制连接，而不是普通连接。复制连接可以执行一些特殊的命令，例如IDENTIFY_SYSTEM, TIMELINE_HISTORY, CREATE_REPLICATION_SLOT, START_REPLICATION, BASE_BACKUP, 在逻辑复制的情况下，还可以执行一些简单的SQL查询。具体细节可以参考PostgreSQL官方文档中前后端协议一章：https://www.postgresql.org/docs/current/protocol-replication.html

譬如，下面这条命令就会建立一条复制连接：

$ psql 'postgres://localhost:5432/postgres?replication=on&application_name=mocker'

从系统视图pg_stat_replication可以看到主库识别到了一个新的"从库”

vonng=# table pg_stat_replication ;
-[ RECORD 1 ]----+-----------------------------
pid              | 7218
usesysid         | 10
usename          | vonng
application_name | mocker
client_addr      | ::1
client_hostname  |
client_port      | 53420

编写自定义逻辑

无论是JDBC还是Go语言的PostgreSQL驱动，都提供了相应的基础设施，用于处理复制连接。

这里让我们用Go语言编写一个简单的CDC客户端，样例使用了jackc/pgx，一个很不错的Go语言编写的PostgreSQL驱动。这里的代码只是作为概念演示，因此忽略掉了错误处理，非常Naive。将下面的代码保存为main.go，执行go run main.go即可执行。

默认的三个参数分别为数据库连接串，逻辑解码输出插件的名称，以及复制槽的名称。默认值为：

dsn := "postgres://localhost:5432/postgres?application_name=cdc"
plugin := "test_decoding"
slot := "test_slot"

go run main.go postgres:///postgres?application_name=cdc test_decoding test_slot

代码如下所示：

package main

import (
	"log"
	"os"
	"time"

	"context"
	"github.com/jackc/pgx"
)

type Subscriber struct {
	URL    string
	Slot   string
	Plugin string
	Conn   *pgx.ReplicationConn
	LSN    uint64
}

// Connect 会建立到服务器的复制连接，区别在于自动添加了replication=on|1|yes|dbname参数
func (s *Subscriber) Connect() {
	connConfig, _ := pgx.ParseURI(s.URL)
	s.Conn, _ = pgx.ReplicationConnect(connConfig)
}

// ReportProgress 会向主库汇报写盘，刷盘，应用的进度坐标（消费者偏移量）
func (s *Subscriber) ReportProgress() {
	status, _ := pgx.NewStandbyStatus(s.LSN)
	s.Conn.SendStandbyStatus(status)
}

// CreateReplicationSlot 会创建逻辑复制槽，并使用给定的解码插件
func (s *Subscriber) CreateReplicationSlot() {
	if consistPoint, snapshotName, err := s.Conn.CreateReplicationSlotEx(s.Slot, s.Plugin); err != nil {
		log.Fatalf("fail to create replication slot: %s", err.Error())
	} else {
		log.Printf("create replication slot %s with plugin %s : consist snapshot: %s, snapshot name: %s",
			s.Slot, s.Plugin, consistPoint, snapshotName)
		s.LSN, _ = pgx.ParseLSN(consistPoint)
	}
}

// StartReplication 会启动逻辑复制（服务器会开始发送事件消息）
func (s *Subscriber) StartReplication() {
	if err := s.Conn.StartReplication(s.Slot, 0, -1); err != nil {
		log.Fatalf("fail to start replication on slot %s : %s", s.Slot, err.Error())
	}
}

// DropReplicationSlot 会使用临时普通连接删除复制槽（如果存在）,注意如果复制连接正在使用这个槽是没法删的。
func (s *Subscriber) DropReplicationSlot() {
	connConfig, _ := pgx.ParseURI(s.URL)
	conn, _ := pgx.Connect(connConfig)
	var slotExists bool
	conn.QueryRow(`SELECT EXISTS(SELECT 1 FROM pg_replication_slots WHERE slot_name = $1)`, s.Slot).Scan(&slotExists)
	if slotExists {
		if s.Conn != nil {
			s.Conn.Close()
		}
		conn.Exec("SELECT pg_drop_replication_slot($1)", s.Slot)
		log.Printf("drop replication slot %s", s.Slot)
	}
}

// Subscribe 开始订阅变更事件，主消息循环
func (s *Subscriber) Subscribe() {
	var message *pgx.ReplicationMessage
	for {
		// 等待一条消息, 消息有可能是真的消息，也可能只是心跳包
		message, _ = s.Conn.WaitForReplicationMessage(context.Background())
		if message.WalMessage != nil {
			DoSomething(message.WalMessage) // 如果是真的消息就消费它
			if message.WalMessage.WalStart > s.LSN { // 消费完后更新消费进度，并向主库汇报
				s.LSN = message.WalMessage.WalStart + uint64(len(message.WalMessage.WalData))
				s.ReportProgress()
			}
		}
		// 如果是心跳包消息，按照协议，需要检查服务器是否要求回送进度。
		if message.ServerHeartbeat != nil && message.ServerHeartbeat.ReplyRequested == 1 {
			s.ReportProgress() // 如果服务器心跳包要求回送进度，则汇报进度
		}
	}
}

// 实际消费消息的函数，这里只是把消息打印出来，也可以写入Redis，写入Kafka，更新统计信息，发送邮件等
func DoSomething(message *pgx.WalMessage) {
	log.Printf("[LSN] %s [Payload] %s", 
             pgx.FormatLSN(message.WalStart), string(message.WalData))
}

// 如果使用JSON解码插件，这里是用于Decode的Schema
type Payload struct {
	Change []struct {
		Kind         string        `json:"kind"`
		Schema       string        `json:"schema"`
		Table        string        `json:"table"`
		ColumnNames  []string      `json:"columnnames"`
		ColumnTypes  []string      `json:"columntypes"`
		ColumnValues []interface{} `json:"columnvalues"`
		OldKeys      struct {
			KeyNames  []string      `json:"keynames"`
			KeyTypes  []string      `json:"keytypes"`
			KeyValues []interface{} `json:"keyvalues"`
		} `json:"oldkeys"`
	} `json:"change"`
}

func main() {
	dsn := "postgres://localhost:5432/postgres?application_name=cdc"
	plugin := "test_decoding"
	slot := "test_slot"
	if len(os.Args) > 1 {
		dsn = os.Args[1]
	}
	if len(os.Args) > 2 {
		plugin = os.Args[2]
	}
	if len(os.Args) > 3 {
		slot = os.Args[3]
	}

	subscriber := &Subscriber{
		URL:    dsn,
		Slot:   slot,
		Plugin: plugin,
	}                                // 创建新的CDC客户端
	subscriber.DropReplicationSlot() // 如果存在，清理掉遗留的Slot

	subscriber.Connect()                   // 建立复制连接
	defer subscriber.DropReplicationSlot() // 程序中止前清理掉复制槽
	subscriber.CreateReplicationSlot()     // 创建复制槽
	subscriber.StartReplication()          // 开始接收变更流
	go func() {
		for {
			time.Sleep(5 * time.Second)
			subscriber.ReportProgress()
		}
	}()                                    // 协程2每5秒地向主库汇报进度
	subscriber.Subscribe()                 // 主消息循环
}

在另一个数据库会话中再次执行上面的变更，可以看到客户端及时地接收到了变更的内容。这里客户端只是简单地将其打印了出来，实际生产中，客户端可以完成任何工作，比如写入Kafka，写入Redis，写入磁盘日志，或者只是更新内存中的统计数据并暴露给监控系统。甚至，还可以通过配置同步提交，确保所有系统中的变更能够时刻保证严格同步（当然相比默认的异步模式比较影响性能就是了）。

对于PostgreSQL主库而言，这看起来就像是另一个从库。

postgres=# table pg_stat_replication; -- 查看当前从库
-[ RECORD 1 ]----+------------------------------
pid              | 14082
usesysid         | 10
usename          | vonng
application_name | cdc
client_addr      | 10.1.1.95
client_hostname  |
client_port      | 56609
backend_start    | 2019-05-19 13:14:34.606014+08
backend_xmin     |
state            | streaming
sent_lsn         | 2D/AB269AB8     -- 服务端已经发送的消息坐标
write_lsn        | 2D/AB269AB8     -- 客户端已经执行完写入的消息坐标
flush_lsn        | 2D/AB269AB8     -- 客户端已经刷盘的消息坐标（不会丢失）
replay_lsn       | 2D/AB269AB8     -- 客户端已经应用的消息坐标（已经生效）
write_lag        |
flush_lag        |
replay_lag       |
sync_priority    | 0
sync_state       | async

postgres=# table pg_replication_slots;  -- 查看当前复制槽
-[ RECORD 1 ]-------+------------
slot_name           | test
plugin              | decoder_raw
slot_type           | logical
datoid              | 13382
database            | postgres
temporary           | f
active              | t
active_pid          | 14082
xmin                |
catalog_xmin        | 1371
restart_lsn         | 2D/AB269A80       -- 下次客户端重连时将从这里开始重放
confirmed_flush_lsn | 2D/AB269AB8       -- 客户端确认完成的消息进度

局限性

想要在生产环境中使用CDC，还需要考虑一些其他的问题。略有遗憾的是，在PostgreSQL CDC的天空上，还飘着两朵小乌云。

完备性

就目前而言，PostgreSQL的逻辑解码只提供了以下几个钩子：

LogicalDecodeStartupCB startup_cb;
LogicalDecodeBeginCB begin_cb;
LogicalDecodeChangeCB change_cb;
LogicalDecodeTruncateCB truncate_cb;
LogicalDecodeCommitCB commit_cb;
LogicalDecodeMessageCB message_cb;
LogicalDecodeFilterByOriginCB filter_by_origin_cb;
LogicalDecodeShutdownCB shutdown_cb;

其中比较重要，也是必须提供的是三个回调函数：begin：事务开始，change：行级别增删改事件，commit：事务提交。遗憾的是，并不是所有的事件都有相应的钩子，例如数据库的模式变更，Sequence的取值变化，以及特殊的大对象操作。

通常来说，这并不是一个大问题，因为用户感兴趣的往往只是表记录而不是表结构的增删改。而且，如果使用诸如JSON，Avro等灵活格式作为解码目标格式，即使表结构发生变化，也不会有什么大问题。

但是尝试从目前的变更事件流生成完备的UNDO Log是不可能的，因为目前模式的变更DDL并不会记录在逻辑解码的输出中。好消息是未来会有越来越多的钩子与支持，因此这个问题是可解的。

同步提交

需要注意的一点是，有一些输出插件会无视Begin与Commit消息。这两条消息本身也是数据库变更日志的一部分，如果输出插件忽略了这些消息，那么CDC客户端在汇报消费进度时就可能会出现偏差（落后一条消息的偏移量）。在一些边界条件下可能会触发一些问题：例如写入极少的数据库启用同步提交时，主库迟迟等不到从库确认最后的Commit消息而卡住)

故障切换

理想很美好，现实很骨感。当一切正常时，CDC工作流工作的很好。但当数据库出现故障，或者出现故障转移时，事情就变得比较棘手了。

恰好一次保证

另外一个使用PostgreSQL CDC的问题是消息队列中经典的恰好一次问题。

PostgreSQL的逻辑复制实际上提供的是至少一次保证，因为消费者偏移量的值会在检查点的时候保存。如果PostgreSQL主库宕机，那么重新发送变更事件的起点，不一定恰好等于上次订阅者已经消费的位置。因此有可能会发送重复的消息。

解决方法是：逻辑复制的消费者也需要记录自己的消费者偏移量，以便跳过重复的消息，实现真正的恰好一次 消息传达保证。这并不是一个真正的问题，只是任何试图自行实现CDC客户端的人都应当注意这一点。

Failover Slot

对目前PostgreSQL的CDC来说，Failover Slot是最大的难点与痛点。逻辑复制依赖复制槽，因为复制槽持有着消费者的状态，记录着消费者的消费进度，因而数据库不会将消费者还没处理的消息清理掉。

但以目前的实现而言，复制槽只能用在主库上，且复制槽本身并不会被复制到从库上。因此当主库进行Failover时，消费者偏移量就会丢失。如果在新的主库承接任何写入之前没有重新建好逻辑复制槽，就有可能会丢失一些数据。对于非常严格的场景，使用这个功能时仍然需要谨慎。

这个问题计划将于下一个大版本（13）解决，Failover Slot的Patch计划于版本13（2020）年合入主线版本。

在那之前，如果希望在生产中使用CDC，那么务必要针对故障切换进行充分地测试。例如使用CDC的情况下，Failover的操作就需要有所变更：核心思想是运维与DBA必须手工完成复制槽的复制工作。在Failover前可以在原主库上启用同步提交，暂停写入流量并在新主库上使用脚本复制复制原主库的槽，并在新主库上创建同样的复制槽，从而手工完成复制槽的Failover。对于紧急故障切换，即原主库无法访问，需要立即切换的情况，也可以在事后使用PITR重新将缺失的变更恢复出来。

小结一下：CDC的功能机制已经达到了生产应用的要求，但可靠性的机制还略有欠缺，这个问题可以等待下一个主线版本，或通过审慎地手工操作解决，当然激进的用户也可以自行拉取该补丁提前尝鲜。

PostgreSQL中的锁

详细介绍PostgreSQL中的各种锁

著： 冯若航（@Vonng） | 2019-06-11

PostgreSQL的并发控制以 快照隔离（SI） 为主，以 两阶段锁定（2PL） 机制为辅。PostgreSQL对DML（SELECT, UPDATE, INSERT, DELETE等命令）使用SSI，对DDL（CREATE TABLE等命令）使用2PL。

PostgreSQL有好几类锁，其中最主要的是 表级锁 与 行级锁，此外还有页级锁，咨询锁等，表级锁 通常是各种命令执行时自动获取的，或者通过事务中的LOCK语句显式获取；而行级锁则是由SELECT FOR UPDATE|SHARE语句显式获取的。执行数据库命令时，都是先获取表级锁，再获取行级锁。本文主要介绍PostgreSQL中的表锁。

表级锁

表级锁通常会在执行各种命令执行时自动获取，或者通过在事务中使用LOCK语句显式获取。
每种锁都有自己的冲突集合，在同一时刻的同一张表上，两个事务可以持有不冲突的锁，不能持有冲突的锁。
有些锁是 自斥(self-conflict) 的，即最多只能被一个事务所持有。
表级锁总共有八种模式，有着并不严格的强度递增关系（例外是Share锁不自斥）
表级锁存在于PG的共享内存中，可以通过pg_locks系统视图查阅。

表级锁的模式

如何记忆这么多类型的锁呢？让我们从演化的视角来看这些锁。

表级锁的演化

最开始只有两种锁：Share与Exclusive，共享锁与排它锁，即所谓读锁与写锁。读锁的目的是阻止表数据的变更，而写锁的目的是阻止一切并发访问。这很好理解。

多版本并发控制

后来随着多版本并发控制技术的出现（PostgreSQL使用快照隔离实现MVCC），读不阻塞写，写不阻塞读（针对表的增删改查而言）。因而原有的锁模型就需要升级了：这里的共享锁与排他锁都有了一个升级版本，即前面多加一个ACCESS。ACCESS SHARE是改良版共享锁，即允许ACCESS（多版本并发访问）的SHARE锁，这种锁意味着即使其他进程正在并发修改数据也不会阻塞本进程读取数据。当然有了多版本读锁也就会有对应的多版本写锁来阻止一切访问，即连ACCESS（多版本并发访问）都要EXCLUSIVE的锁，这种锁会阻止一切访问，是最强的写锁。

引入MVCC后，INSERT|UPDATE|DELETE仍然使用原来的Exclusive锁，而普通的只读SELECT则使用多版本的AccessShare锁。因为AccessShare锁与原来的Exclusive锁不冲突，所以读写之间就不会阻塞了。原来的Share锁现在主要的应用场景为创建索引（非并发创建模式下，创建索引会阻止任何对底层数据的变更），而升级的多版本AccessExclusive锁主要用于除了增删改之外的排他性变更（DROP|TRUNCATE|REINDEX|VACUUM FULL等），这个模型如图（a）所示。

当然，这样还是有问题的。虽然在MVCC中读写之间相互不阻塞了，但写-写之间还是会产生冲突。上面的模型中，并发写入是通过表级别的Exclusive锁解决的。表级锁虽然可以解决并发写入冲突问题，但这个粒度太大了，会影响并发度：因为同一时刻一张表上只能有一个进程持有Exclusive锁并执行写入，而典型的OLTP场景是以单行写入为主。所以常见的DBMS解决写-写冲突通常都是采用行级锁来实现（下面会讲到）。

行级锁和表级锁不是一回事，但这两种锁之间仍然存在着联系，协调这两种锁之间的关系，就需要引入意向锁。

意向锁

意向锁用于协调表锁与行锁之间的关系：它用于保护较低资源级别上的锁，即说明下层节点已经被加了锁。当进程想要锁定或修改某表上的某一行时，它会在这一行上加上行级锁。但在加行级锁之前，它还需要在这张表上加上一把意向锁，表示自己将会在表中的若干行上加锁。

举个例子，假设不存在意向锁。假设进程A获取了表上某行的行锁，持有行上的排他锁意味着进程A可以对这一行执行写入；同时因为不存在意向锁，进程B很顺利地获取了该表上的表级排他锁，这意味着进程B可以对整个表，包括A锁定对那一行进行修改，这就违背了常识逻辑。因此A需要在获取行锁前先获取表上的意向锁，这样后来的B就意识到自己无法获取整个表上的排他锁了（但B依然可以加一个意向锁，获取其他行上的行锁）。

因此，这里RowShare就是行级共享锁对应的表级意向锁（SELECT FOR SHARE|UPDATE命令获取），而RowExclusive（INSERT|UPDATE|DELETE获取）则是行级排他锁对应的表级意向锁。注意因为MVCC的存在，只读查询并不会在行上加锁。引入意向锁后的模型如图（c）所示。而合并MVCC与意向锁模型之后的锁模型如图（d）所示。

自斥锁

上面这个模型已经相当不错，但仍然存在一些问题，譬如自斥：这里RowExclusive与Share锁都不是自斥的。

举个例子，并发VACUUM不应阻塞数据写入，而且一个表上不应该允许多个VACUUM进程同时工作。因为不能阻塞写入，因此VACUUM所需的锁强度必须要比Share锁弱，弱于Share的最强锁为RowExclusive，不幸的是，该锁并不自斥。如果VACUUM使用该锁，就无法阻止单表上出现多个VACUUM进程。因此需要引入一个自斥版本的RowExclusive锁，即ShareUpdateExclusive锁。

同理，再比如执行触发器管理操作（创建，删除，启用）时，该操作不应阻塞读取和锁定，但必须禁止一切实际的数据写入，否则就难以判断某条元组的变更是否应该触发触发器。Share锁满足不阻塞读取和锁定的条件，但并不自斥，因此可能出现多个进程在同一个表上并发修改触发器。并发修改触发器会带来很多问题（譬如丢失更新，A将其配置为Replica Trigger，B将其配置为Always Trigger，都反回成功了，以谁为准？）。因此这里也需要一个自斥版本的Share锁，即ShareRowExclusive锁。

因此，引入两种自斥版本的锁后，就是PostgreSQL中的最终表级锁模型，如图（e）所示。

表级锁的命名与记忆

PostgreSQL的表级锁的命名有些诘屈聱牙，这是因为一些历史因素，但也可以总结出一些规律便于记忆。

最初只有两种锁：共享锁（Share）与排他锁（Exclusive）。
- 特征是只有一个单词，表示这是两种最基本的锁：读锁与写锁。
多版本并发控制的出现，引入了多版本的共享锁与排他锁（AccessShare与AccessExclusive）。
- 特征是Access前缀，表示这是用于"多版本并发控制"的改良锁。
为了处理并发写入之间的冲突，又引入了两种意向锁（RowShare与RowExclusive）
- 特征是Row前缀，表示这是行级别共享/排他锁对应的表级意向锁。
最后，为了处理意向排他锁与共享锁不自斥的问题，引入了这两种锁的自斥版本（ShareUpdateExclusive, ShareRowExclusive）。这两种锁的名称比较难记：
- 都是以Share打头，以Exclusive结尾。表示这两种锁都是某种共享锁的自斥版本。
- 两种锁强度围绕在Share前后，Update弱于Share，Row强于Share。
- ShareRowExclusive可以理解为Share + Row Exclusive，因为Share不排斥其他Share，但RowExclusive排斥Share，因此同时加这两种锁的结果等效于ShareRowExclusive，即SIX。
- ShareUpdateExclusive可以理解为ShareUpdate + Exclusive：UPDATE操作持有RowExclusive锁，而ShareUpdate指的是本锁与普通的增删改（持RowExclusive锁）相容，而Exclusive则表示自己和自己不相容。
Share, ShareRowUpdate, Exclusive 这三种锁极少出现，基本可以无视。所以实际上主要用到的锁是：
- 多版本两种：AccessShare, AccessExclusive
- 意向锁两种：RowShare,RowExclusive
- 自斥意向锁一种：ShareUpdateExclusive

显式加锁

通常表级锁会在相应命令执行中自动获取，但也可以手动显式获取。使用LOCK命令加锁的方式：

LOCK [ TABLE ] [ ONLY ] name [ * ] [, ...] [ IN lockmode MODE ] [ NOWAIT ]

显式锁表必须在事务中进行，在事务外锁表会报错。
锁定视图时，视图定义中所有出现的表都会被锁定。
使用表继承时，默认父表和所有后代表都会加锁，指定ONLY选项则继承于该表的子表不会自动加锁。
锁表或者锁视图需要对应的权限，例如AccessShare锁需要SELECT权限。
默认获取的锁模式为AccessExclusive，即最强的锁。
LOCK TABLE只能获取表锁，默认会等待冲突的锁被释放，指定NOWAIT选项时，如果命令不能立刻获得锁就会中止并报错。
命令一旦获取到锁，会被在当前事务中一直持有。没有UNLOCK TABLE命令，锁总是在事务结束时释放。

例子：数据迁移

举个例子，以迁移数据为例，假设希望将某张表的数据迁移到另一个实例中。并保证在此期间旧表上的数据在迁移期间不发生变化，那么我们可以做的就是在复制数据前在表上显式加锁，并在复制结束，应用开始写入新表后释放。应用仍然可以从旧表上读取数据，但不允许写入。那么根据锁冲突矩阵，允许只读查询的锁要弱于AccessExclusive，阻止写入的锁不能弱于ShareRowExclusive，因此可以选择ShareRowExclusive或Exclusive锁。因为拒绝写入意味着锁定没有任何意义，所以这里选择更强的Exclusive锁。

BEGIN;
LOCK TABLE tbl IN EXCLUSIVE MODE;
-- DO Something
COMMIT

锁的查询

PostgreSQL提供了一个系统视图pg_locks，包含了当前活动进程持锁的信息。可以锁定的对象包括：关系，页面，元组，事务标识（虚拟的或真实的），其他数据库对象（带有OID）。

CREATE TABLE pg_locks
(
    -- 锁针对的客体对象
    locktype           text, -- 锁类型：关系，页面，元组，事务ID，对象等
    database           oid,  -- 数据库OID
    relation           oid,  -- 关系OID
    page               integer, -- 关系内页号
    tuple              smallint, -- 页内元组号
    virtualxid         text,     -- 虚拟事务ID
    transactionid      xid,      -- 事务ID
    classid            oid,      -- 锁对象所属系统目录表本身的OID
    objid              oid,      -- 系统目录内的对象的OID
    objsubid           smallint, -- 列号
  
    -- 持有|等待锁的主体
    virtualtransaction text,     -- 持锁|等待锁的虚拟事务ID
    pid                integer,  -- 持锁|等待锁的进程PID
    mode               text,     -- 锁模式
    granted            boolean,  -- t已获取，f等待中
    fastpath           boolean   -- t通过fastpath获取
);

名称	类型	描述
`locktype`	`text`	可锁对象的类型： `relation`， `extend`， `page`， `tuple`， `transactionid`， `virtualxid`， `object`， `userlock`或`advisory`
`database`	`oid`	若锁目标为数据库（或下层对象），则为数据库OID，并引用`pg_database.oid`，共享对象为0，否则为空
`relation`	`oid`	若锁目标为关系（或下层对象），则为关系OID，并引用`pg_class.oid`，否则为空
`page`	`integer`	若锁目标为页面（或下层对象），则为页面号，否则为空
`tuple`	`smallint`	若锁目标为元组，则为页内元组号，否则为空
`virtualxid`	`text`	若锁目标为虚拟事务，则为虚拟事务ID，否则为空
`transactionid`	`xid`	若锁目标为事务，则为事务ID，否则为空
`classid`	`oid`	若目标为数据库对象，则为该对象相应系统目录的OID，并引用`pg_class.oid`，否则为空。
`objid`	`oid`	锁目标在其系统目录中的OID，如目标不是普通数据库对象则为空
`objsubid`	`smallint`	锁的目标列号（`classid`和`objid`指向表本身），若目标是某种其他普通数据库对象则此列为0，如果目标不是一个普通数据库对象则此列为空。
`virtualtransaction`	`text`	持有或等待这个锁的虚拟ID
`pid`	`integer`	持有或等待这个锁的服务器进程ID，如果此锁被一个预备事务所持有则为空
`mode`	`text`	持有或者等待锁的模式
`granted`	`boolean`	为真表示已经获得的锁，为假表示还在等待的锁
`fastpath`	`boolean`	为真表示锁是通过fastpath获取的

样例数据

这个视图需要一些额外的知识才能解读。

该视图是数据库集簇范围的视图，而非仅限于单个数据库，即可以看见其他数据库中的锁。
一个进程在一个时间点只能等待至多一个锁，等待锁用granted=f表示，等待进程会休眠至其他锁被释放，或者系统检测到死锁。
每个事务都有一个虚拟事务标识virtualtransaction（以下简称vxid），修改数据库状态（或者显式调用txid_current获取）的事务才会被分配一个真实的事务标识transactionid（简称txid），vxid|txid本身也是可以锁定的对象。
每个事务都会持有自己vxid上的Exclusive锁，如果有txid，也会同时持有其上的Exclusive锁（即同时持有txid和vxid上的排它锁）。因此当一个事务需要等待另一个事务时，它会尝试获取另一个事务txid|vxid上的共享锁，因而只有当目标事务结束（自动释放自己事务标识上的Exclusive锁）时，等待事务才会被唤醒。
pg_locks视图通常并不会直接显示行级锁信息，因为这些信息存储在磁盘磁盘上（），如果真的有进程在等待行锁，显示的形式通常是一个事务等待另一个事务，而不是等待某个具体的行锁。
咨询锁本质上的锁对象客体是一个数据库范畴内的BIGINT，classid里包含了该整数的高32bit，objid里包含有低32bit，objsubid里则说明了咨询锁的类型，单一Bigint则取值为1，两个int32则取值为2。
本视图并不一定能保证提供一个一致的快照，因为所有fastpath=true的锁信息是从每个后端进程收集而来的，而fastpath=false的锁是从常规锁管理器中获取的，同时谓词锁管理器中的数据也是单独获取的，因此这几种来源的数据之间可能并不一致。
频繁访问本视图会对数据库系统性能产生影响，因为要对锁管理器加锁获取一致性快照。

虚拟事务

一个后端进程在整个生命周期中的每一个事务都会有一个自己的虚拟事务ID。

PG中事务号是有限的（32-bit整型），会循环使用。为了节约事务号，PG只会为实际修改数据库状态的事务分配真实事务ID，而只读事务就不分配了，用虚拟事务ID凑合一下。txid是事务标识，全局共享，而vxid是虚拟事务标识，在短期内可以保证全局唯一性。因为vxid由两部分组成：BackendID与LocalTransactionId，前者是后端进程的标识符（本进程在内存中进程数组中的序号），后者是一个递增的事务计数器。因此两者组合即可获得一个暂时唯一的虚拟事务标识（之所以是暂时是因为这里的后端ID是有可能重复的）
typedef struct {
	BackendId	backendId;		/* 后端ID，初始化时确定，其实是后端进程数组内索引号 */
	LocalTransactionId localTransactionId;	/* 后端内本地使用的命令标ID，类似自增计数器 */
} VirtualTransactionId;

应用

常见操作的冲突关系

SELECT与UPDATE|DELETE|INSERT不会相互阻塞，即使访问的是同一行。
I|U|D写入操作与I|U|D写入操作在表层面不会互斥，会在具体的行上通过RowExclusive锁实现。
SELECT FOR UPDATE锁定操作与I|U|D写入在表层级也不会互斥，仍然是通过具体元组上的行锁实现。
并发VACUUM，并发创建索引等操作不会阻塞读写，但它们是自斥的，即同一时刻只会有一个（所以同时在一个表上执行两个CREATE INDEX CONCURRENTLY是没有意义的，不要被名字骗了）
普通的索引创建CREATE INDEX，不带CONCURRENTLY会阻塞增删改，但不会阻塞查，很少用到。
任何对于触发器的操作，或者约束类的操作，都会阻止增删改，但不会阻塞只读查询以及锁定。
冷门的命令REFRESH MATERIALIZED VIEW CONCURRENTLY允许SELECT和锁定。
大多数很硬的变更：VACUUM FULL, DROP TABLE, TRUNCATE, ALTER TABLE的大多数形式都会阻塞一切读取。

注意，锁虽有强弱之分，但冲突关系是对等的。一个持有AccessShare锁的SELECT会阻止后续的DROP TABLE获得AccessExclusive锁。后面的命令会进入锁队列中。

锁队列

PG中每个锁上都会有一个锁队列。如果事务A占有一个排他锁，那么事务B在尝试获取其上的锁时就会在其锁队列中等待。如果这时候事务C同样要获取该锁，那么它不仅要和事务A进行冲突检测，也要和B进行冲突检测，以及队列中其他的事务。这意味着当用户尝试获取一个很强的锁而未得等待时，已经会阻止后续新锁的获取。一个具体的例子是加列：

ALTER TABLE tbl ADD COLUMN mtime TIMESTAMP;

即使这是一个不带默认值的加列操作（不会重写整个表，因而很快），但本命令需要表上的AccessExclusive锁，如果这张表上面已经有不少查询，那么这个命令可能会等待相当一段时间。因为它需要等待其他查询结束并释放掉锁后才能执行。相应地，因为这条命令已经在等待队列中，后续的查询都会被它所阻塞。因此，当执行此类命令时的一个最佳实践是在此类命令前修改lock_timeout，从而避免雪崩。

SET lock_timeout TO '1s';
ALTER TABLE tbl ADD COLUMN mtime TIMESTAMP;

这个设计的好处是，命令不会饿死：不会出现源源不断的短小只读查询无限阻塞住一个排他操作。

加锁原则

够用即可：使用满足条件的锁中最弱的锁模式
越快越好：如果可能，可以用（长时间的弱锁+短时间的强锁）替换长时间的强锁
递增获取：遵循2PL原则申请锁；越晚使用激进锁策略越好；在真正需要时再获取。
相同顺序：获取锁尽量以一致的顺序获取，从而减小死锁的几率

最小化锁阻塞时长

除了手工锁定之外，很多常见的操作都会"锁表"，最常见的莫过于添加新字段与添加新约束。这两种操作都会获取表上的AccessExclusive锁以阻止一切并发访问。当DBA需要在线维护数据库时应当最小化持锁的时间。

例如，为表添加新字段的ALTER TABLE ADD COLUMN子句，根据新列是否提供易变默认值，会重写整个表。

ALTER TABLE tbl ADD COLUMN mtime TIMESTAMP DEFAULT CURRENT_TIMESTAMP;

如果只是个小表，业务负载也不大，那么也许可以直接这么干。但如果是很大的表，以及很高的负载，那么阻塞的时间就会很可观。在这段时间里，命令都会持有表上的AccessExclusive锁阻塞一切访问。

可以通过先加一个空列，再慢慢更新的方式来最小化锁等待时间：

ALTER TABLE tbl ADD COLUMN mtime TIMESTAMP;
UPDATE tbl SET mtime = CURRENT_TIMESTAMP; -- 可以分批进行

这样，第一条加列操作的锁阻塞时间就会非常短，而后面的更新（重写）操作就可以以不阻塞读写的形式慢慢进行，最小化锁阻塞。

同理，当想要为表添加新的约束时（例如新的主键），也可以采用这种方式：

CREATE UNIQUE INDEX CONCURRENTLY tbl_pk ON tbl(id); -- 很慢，但不阻塞读写
ALTER TABLE tbl ADD CONSTRAINT tbl_pk PRIMARY KEY USING INDEX tbl_pk;  -- 阻塞读写，但很快

替代单纯的

ALTER TABLE tbl ADD PRIMARY KEY (id);

微信公众号原文

GIN搜索的O(n2)负载度

GIN索引如果使用很长的关键词列表进行搜索，会导致性能显著下降。本文解释了为什么GIN索引关键词搜索的时间复杂度为O(n^2)

著： 冯若航（@Vonng） | 2019-04-12

Here is the detail of why that query have O(N^2) inside GIN implementation.

Details

Inspect the index example_keys_idx

postgres=# select oid,* from pg_class where relname = 'example_keys_idx';
-[ RECORD 1 ]-------+-----------------
oid                 | 20699
relname             | example_keys_idx
relnamespace        | 20692
reltype             | 0
reloftype           | 0
relowner            | 10
relam               | 2742
relfilenode         | 20699
reltablespace       | 0
relpages            | 2051
reltuples           | 300000
relallvisible       | 0
reltoastrelid       | 0
relhasindex         | f
relisshared         | f
relpersistence      | p
relkind             | i
relnatts            | 1
relchecks           | 0
relhasoids          | f
relhasrules         | f
relhastriggers      | f
relhassubclass      | f
relrowsecurity      | f
relforcerowsecurity | f
relispopulated      | t
relreplident        | n
relispartition      | f
relrewrite          | 0
relfrozenxid        | 0
relminmxid          | 0
relacl              |
reloptions          | {fastupdate=off}
relpartbound        |

Find index information via index’s oid

postgres=# select * from pg_index where indexrelid = 20699;
-[ RECORD 1 ]--+------
indexrelid     | 20699
indrelid       | 20693
indnatts       | 1
indnkeyatts    | 1
indisunique    | f
indisprimary   | f
indisexclusion | f
indimmediate   | t
indisclustered | f
indisvalid     | t
indcheckxmin   | f
indisready     | t
indislive      | t
indisreplident | f
indkey         | 2
indcollation   | 0
indclass       | 10075
indoption      | 0
indexprs       |
indpred        |

Find corresponding operator class for that index via indclass

postgres=# select * from pg_opclass where oid = 10075;
-[ RECORD 1 ]+----------
opcmethod    | 2742
opcname      | array_ops
opcnamespace | 11
opcowner     | 10
opcfamily    | 2745
opcintype    | 2277
opcdefault   | t
opckeytype   | 2283

Find four operator corresponding to operator faimily array_ops

postgres=# select * from pg_amop where amopfamily =2745;
-[ RECORD 1 ]--+-----
amopfamily     | 2745
amoplefttype   | 2277
amoprighttype  | 2277
amopstrategy   | 1
amoppurpose    | s
amopopr        | 2750
amopmethod     | 2742
amopsortfamily | 0
-[ RECORD 2 ]--+-----
amopfamily     | 2745
amoplefttype   | 2277
amoprighttype  | 2277
amopstrategy   | 2
amoppurpose    | s
amopopr        | 2751
amopmethod     | 2742
amopsortfamily | 0
-[ RECORD 3 ]--+-----
amopfamily     | 2745
amoplefttype   | 2277
amoprighttype  | 2277
amopstrategy   | 3
amoppurpose    | s
amopopr        | 2752
amopmethod     | 2742
amopsortfamily | 0
-[ RECORD 4 ]--+-----
amopfamily     | 2745
amoplefttype   | 2277
amoprighttype  | 2277
amopstrategy   | 4
amoppurpose    | s
amopopr        | 1070
amopmethod     | 2742
amopsortfamily | 0

https://www.postgresql.org/docs/10/xindex.html

Table 37.6. GIN Array Strategies

Operation	Strategy Number
overlap	1
contains	2
is contained by	3
equal	4

When we access that index with && operator, we are using stragety 1 overlap, which corresponding operator oid is 2750.

postgres=# select * from pg_operator where oid = 2750;
-[ RECORD 1 ]+-----------------
oprname      | &&
oprnamespace | 11
oprowner     | 10
oprkind      | b
oprcanmerge  | f
oprcanhash   | f
oprleft      | 2277
oprright     | 2277
oprresult    | 16
oprcom       | 2750
oprnegate    | 0
oprcode      | arrayoverlap
oprrest      | arraycontsel
oprjoin      | arraycontjoinsel

The underlying C function to judge arrayoverlap is arrayoverlap in here

Datum
arrayoverlap(PG_FUNCTION_ARGS)
{
	AnyArrayType *array1 = PG_GETARG_ANY_ARRAY_P(0);
	AnyArrayType *array2 = PG_GETARG_ANY_ARRAY_P(1);
	Oid			collation = PG_GET_COLLATION();
	bool		result;

	result = array_contain_compare(array1, array2, collation, false,
								   &fcinfo->flinfo->fn_extra);

	/* Avoid leaking memory when handed toasted input. */
	AARR_FREE_IF_COPY(array1, 0);
	AARR_FREE_IF_COPY(array2, 1);

	PG_RETURN_BOOL(result);
}

It actually use array_contain_compare to test whether two array are overlap

static bool
array_contain_compare(AnyArrayType *array1, AnyArrayType *array2, Oid collation,
					  bool matchall, void **fn_extra)

Line 4177, we see a nested loop to iterate two array, which makes it O(N^2)

	for (i = 0; i < nelems1; i++)
	{
		Datum		elt1;
		bool		isnull1;

		/* Get element, checking for NULL */
		elt1 = array_iter_next(&it1, &isnull1, i, typlen, typbyval, typalign);

		/*
		 * We assume that the comparison operator is strict, so a NULL can't
		 * match anything.  XXX this diverges from the "NULL=NULL" behavior of
		 * array_eq, should we act like that?
		 */
		if (isnull1)
		{
			if (matchall)
			{
				result = false;
				break;
			}
			continue;
		}

		for (j = 0; j < nelems2; j++)

IP地理逆查询优化

在应用开发中，一个‘很常见’的需求就是GeoIP转换。将请求的来源IP转换为相应的地理坐标，或者行政区划（国家-省-市-县-乡-镇）

著： 冯若航（@Vonng） | 2018-07-07

IP归属地查询的高效实现

在应用开发中，一个‘很常见’的需求就是GeoIP转换。将请求的来源IP转换为相应的地理坐标，或者行政区划（国家-省-市-县-乡-镇）。这种功能有很多用途，譬如分析网站流量的地理来源，或者干一些坏事。使用PostgreSQL可以多快好省，优雅高效地实现这一需求。

0x01 思路方法

通常网上的IP地理数据库的形式都是：start_ip, stop_ip , longitude, latitude，再缀上一些国家代码，城市代码，邮编之类的属性字段。大概长这样：

Column	Type
start_ip	text
end_ip	text
longitude	text
latitude	text
country_code	text
……	text

说到底，其核心是从IP地址段到地理坐标点的映射。

典型查询实际上是给出一个IP地址，返回该地址对应的地理范围。其逻辑用SQL来表示差不多长这样：

SELECT longitude, latitude FROM geoip 
WHERE start_ip <= target_ip AND target_ip <= stop_ip;

不过，想直接提供服务，还有几个问题需要解决：

第一个问题：虽然IPv4实际上是一个uint32，但我们已经完全习惯了123.123.123.123这种文本表示形式。而这种文本表示形式是无法比较大小的。
第二个问题：这里的IP范围是用两个IP边界字段表示的范围，那么这个范围是开区间还是闭区间呢？是不是还需要一个额外字段来表示？
第三个问题：想要高效地查询，那么在两个字段上的索引又该如何建立？
第四个问题：我们希望所有的IP段相互之间不会出现重叠，但简单的建立在(start_ip, stop_ip)上的唯一约束并无法保证这一点，那又如何是好？

令人高兴的是，对于PostgreSQL而言，这些都不是问题。上面四个问题，可以轻松使用PostgreSQL的特性解决。

网络数据类型：高性能，紧凑，灵活的网络地址表示。
范围类型：对区间的良好抽象，对区间查询与操作的良好支持。
GiST索引：既能作用于IP地址段，也可以用于地理位置点。
Exclude约束：泛化的高级UNIQUE约束，从根本上确保数据完整性。

0x01 网络地址类型

PostgreSQL提供用于存储 IPv4、IPv6 和 MAC 地址的数据类型。包括cidr，inet以及macaddr，并且提供了很多常见的操作函数，不需要再在程序中去实现一些繁琐重复的功能。

最常见的网络地址就是IPv4地址，对应着PostgreSQL内建的inet类型，inet类型可以用来存储IPv4，IPv6地址，或者带上一个可选的子网。当然这些细节操作都可以参阅文档，在此不详细展开。

一个需要注意的点就是，虽然我们知道IPv4实质上是一个Unsigned Integer，但在数据库中实际存储成INTEGER其实是不行的，因为SQL标准并不支持Unsigned这种用法，所以有一半的IP地址的表示就会被解释为负数，在比大小的时候产生令人惊异的结果，真要这么存请使用BIGINT。此外，直接面对一堆长长的整数也是相当令人头大的问题，inet是最佳的选择。

如果需要将IP地址（inet类型）与对应的整数相互转换，只要与0.0.0.0做加减运算即可；当然也可以使用以下函数，并创建一个类型转换，然后就能直接在inet与bigint之间来回转换：

-- inet to bigint
CREATE FUNCTION inet2int(inet) RETURNS bigint AS $$
SELECT $1 - inet '0.0.0.0';
$$ LANGUAGE SQL  IMMUTABLE RETURNS NULL ON NULL INPUT;

-- bigint to inet
CREATE FUNCTION int2inet(bigint) RETURNS inet AS $$
SELECT inet '0.0.0.0' + $1;
$$ LANGUAGE SQL  IMMUTABLE RETURNS NULL ON NULL INPUT;

-- create type conversion
CREATE CAST (inet AS bigint) WITH FUNCTION inet2int(inet);
CREATE CAST (bigint AS inet) WITH FUNCTION int2inet(bigint);

-- test
SELECT 123456::BIGINT::INET;
SELECT '1.2.3.4'::INET::BIGINT;

-- 生成随机的IP地址
SELECT (random() * 4294967295)::BIGINT::INET;

inet之间的大小比较也相当直接，直接使用大小比较运算符就可以了。实际比较的是底下的整数值。这就解决了第一个问题。

0x02 范围类型

PostgreSQL的Range类型是一种很实用的功能，它与数组类似，属于一种泛型。只要是能被B树索引（可以比大小）的数据类型，都可以作为范围类型的基础类型。它特别适合用来表示区间：整数区间，时间区间，IP地址段等等。而且对于开区间，闭区间，区间索引这类问题有比较细致的考虑。

PostgreSQL内置了预定义的int4range, int8range, numrange, tsrange, tstzrange, daterange，开箱即用。但没有提供网络地址对应的范围类型，好在自己造一个非常简单：

CREATE TYPE inetrange AS RANGE(SUBTYPE = inet)

当然为了高效地支持GiST索引查询，还需要实现一个距离度量，告诉索引两个inet之间的距离应该如何计算：

-- 定义基本类型间的距离度量
CREATE FUNCTION inet_diff(x INET, y INET) RETURNS FLOAT AS $$
  SELECT (x - y) :: FLOAT;
$$ LANGUAGE SQL IMMUTABLE STRICT;

-- 重新创建inetrange类型，使用新定义的距离度量。
CREATE TYPE inetrange AS RANGE(
  SUBTYPE = inet,
  SUBTYPE_DIFF = inet_diff
)

幸运的是，俩网络地址之间的距离定义天然就有一个很简单的计算方法，减一下就好了。

这个新定义的类型使用起来也很简单，构造函数会自动生成：

geo=# select misc.inetrange('64.60.116.156','64.60.116.161','[)');
inetrange | [64.60.116.156,64.60.116.161)

geo=# select '[64.60.116.156,64.60.116.161]'::inetrange;
inetrange | [64.60.116.156,64.60.116.161]

方括号和圆括号分别表示闭区间和开区间，与数学中的表示方法一致。

同时，检测一个IP地址是否落在给定的IP范围内也是很直接的：

geo=# select '[64.60.116.156,64.60.116.161]'::inetrange @> '64.60.116.160'::inet as res;
res | t

有了范围类型，就可以着手构建我们的数据表了。

0x03 范围索引

实际上，找一份IP地理对应数据花了我一个多小时，但完成这个需求只用了几分钟。

假设已经有了这样一份数据：

create table geoips
(
  ips          inetrange,
  geo          geometry(Point),
  country_code text,
  region_code  text,
  city_name    text,
  ad_code      text,
  postal_code  text
);

里面的数据大概长这样：

SELECT ips,ST_AsText(geo) as geo,country_code FROM geoips

 [64.60.116.156,64.60.116.161] | POINT(-117.853 33.7878) | US
 [64.60.116.139,64.60.116.154] | POINT(-117.853 33.7878) | US
 [64.60.116.138,64.60.116.138] | POINT(-117.76 33.7081)  | US

那么查询包含某个IP地址的记录就可以写作：

SELECT * FROM ip WHERE ips @> inet '67.185.41.77';

对于600万条记录，约600M的表，在笔者的机器上暴力扫表的平均用时是900ms，差不多单核QPS是1.1，48核生产机器也就差不多三四十的样子。肯定是没法用的。

CREATE INDEX ON geoips USING GiST(ips);

查询用时从1秒变为340微秒，差不多3000倍的提升。

-- pgbench
\set ip random(0,4294967295)
SELECT * FROM geoips WHERE ips @> :ip::BIGINT::INET;

-- result
latency average = 0.342 ms
tps = 2925.100036 (including connections establishing)
tps = 2926.151762 (excluding connections establishing)

折算成生产QPS差不多是十万QPS，啧啧啧，美滋滋。

如果需要把地理坐标转换为行政区划，可以参考上一篇文章：使用PostGIS高效解决行政区划归属地理编码问题。

一次地理编码也就是100微秒，从IP转换为省市区县整个的QPS，单机几万基本问题不大（全天满载相当于七八十亿次调用，根本用不满）。

0x04 EXCLUDE约束

问题至此已经基本解决了，不过还有一个问题。如何避免一个IP查出两条记录的尴尬情况？

数据完整性是极其重要的，但由应用保证的数据完整性并不总是那么靠谱：人会犯傻，程序会出错。如果能通过数据库约束来Enforce数据完整性，那是再好不过了。

然而，有一些约束是相当复杂的，例如确保表中的IP范围不发生重叠，类似的，确保地理区划表中各个城市的边界不会重叠。传统上要实现这种保证是相当困难的：譬如UNIQUE约束就无法表达这种语义，CHECK与存储过程或者触发器虽然可以实现这种检查，但也相当tricky。PostgreSQL提供的EXCLUDE约束可以优雅地解决这个问题。修改我们的geoips表：

create table geoips
(
  ips          inetrange,
  geo          geometry(Point),
  country_code text,
  region_code  text,
  city_name    text,
  ad_code      text,
  postal_code  text,
  EXCLUDE USING gist (ips WITH &&) DEFERRABLE INITIALLY DEFERRED 
);

这里EXCLUDE USING gist (ips WITH &&) 的意思就是ips字段上不允许出现范围重叠，即新插入的字段不能与任何现存范围重叠（&&为真）。而DEFERRABLE INITIALLY IMMEDIATE 表示在语句结束时再检查所有行上的约束。创建该约束会自动在ips字段上创建GIST索引，因此无需手工创建了。

0x05 小结

本文介绍了如何使用PostgreSQL特性高效而优雅地解决IP归属地查询的问题。性能表现优异，600w记录0.3ms定位；复杂度低到发指：只要一张表DDL，连索引都不用显式创建就解决了这一问题；数据完整性有充分的保证：百行代码才能解决的问题现在只要添加约束即可，从根本上保证数据完整性。

PostgreSQL这么棒棒，快快学起来用起来吧~。

什么？你问我数据哪里找？搜索MaxMind有真相，在隐秘的小角落能够找到不要钱的GeoIP数据。

PostgreSQL的触发器

详细了解PostgreSQL中触发器的管理与使用

著： 冯若航（@Vonng） | 2018-07-07

概览

触发器行为概述
触发器的分类
触发器的功能
触发器的种类
触发器的触发
触发器的创建
触发器的修改
触发器的查询
触发器的性能

触发器概述

触发器行为概述：英文，中文

触发器分类

触发时机：BEFORE, AFTER, INSTEAD

触发事件：INSERT, UPDATE, DELETE,TRUNCATE

触发范围：语句级，行级

内部创建：用于约束的触发器，用户定义的触发器

触发模式：origin|local(O), replica(R),disable(D)

触发器操作

触发器的操作通过SQL DDL语句进行，包括CREATE|ALTER|DROP TRIGGER，以及ALTER TABLE ENABLE|DISABLE TRIGGER进行。注意PostgreSQL内部的约束是通过触发器实现的。

创建

CREATE TRIGGER 可以用于创建触发器。

CREATE [ CONSTRAINT ] TRIGGER name { BEFORE | AFTER | INSTEAD OF } { event [ OR ... ] }
    ON table_name
    [ FROM referenced_table_name ]
    [ NOT DEFERRABLE | [ DEFERRABLE ] [ INITIALLY IMMEDIATE | INITIALLY DEFERRED ] ]
    [ REFERENCING { { OLD | NEW } TABLE [ AS ] transition_relation_name } [ ... ] ]
    [ FOR [ EACH ] { ROW | STATEMENT } ]
    [ WHEN ( condition ) ]
    EXECUTE { FUNCTION | PROCEDURE } function_name ( arguments )

event包括：
    INSERT
    UPDATE [ OF column_name [, ... ] ]
    DELETE
    TRUNCATE

删除

DROP TRIGGER 用于移除触发器。

DROP TRIGGER [ IF EXISTS ] name ON table_name [ CASCADE | RESTRICT ]

修改

ALTER TRIGGER 用于修改触发器定义，注意这里只能修改触发器名，以及其依赖的扩展。

ALTER TRIGGER name ON table_name RENAME TO new_name
ALTER TRIGGER name ON table_name DEPENDS ON EXTENSION extension_name

启用禁用触发器，修改触发模式是通过ALTER TABLE的子句实现的。

ALTER TABLE 包含了一系列触发器修改的子句：

ALTER TABLE tbl ENABLE TRIGGER tgname; -- 设置触发模式为O (本地连接写入触发，默认)
ALTER TABLE tbl ENABLE REPLICA TRIGGER tgname; -- 设置触发模式为R (复制连接写入触发)
ALTER TABLE tbl ENABLE ALWAYS TRIGGER tgname; -- 设置触发模式为A (总是触发)
ALTER TABLE tbl DISABLE TRIGGER tgname; -- 设置触发模式为D (禁用)

注意这里在ENABLE与DISABLE触发器时，可以指定用USER替换具体的触发器名称，这样可以只禁用用户显式创建的触发器，不会把系统用于维持约束的触发器也禁用了。

ALTER TABLE tbl_name DISABLE TRIGGER USER; -- 禁用所有用户定义的触发器，系统触发器不变  
ALTER TABLE tbl_name DISABLE TRIGGER ALL;  -- 禁用所有触发器
ALTER TABLE tbl_name ENABLE TRIGGER USER;  -- 启用所有用户定义的触发器
ALTER TABLE tbl_name ENABLE TRIGGER ALL;   -- 启用所有触发器

查询

获取表上的触发器

最简单的方式当然是psql的\d+ tablename。但这种方式只会列出用户创建的触发器，不会列出与表上约束相关联的触发器。直接查询系统目录pg_trigger，并通过tgrelid用表名过滤

SELECT * FROM pg_trigger WHERE tgrelid = 'tbl_name'::RegClass;

获取触发器定义

pg_get_triggerdef(trigger_oid oid)函数可以给出触发器的定义。

该函数输入参数为触发器OID，返回创建触发器的SQL DDL语句。

SELECT pg_get_triggerdef(oid) FROM pg_trigger; -- WHERE xxx

触发器视图

pg_trigger (中文) 提供了系统中触发器的目录

名称	类型	引用	描述
`oid`	`oid`		触发器对象标识，系统隐藏列
`tgrelid`	`oid`	`pg_class.oid`	触发器所在的表 oid
`tgname`	`name`		触发器名，表级命名空间内不重名
`tgfoid`	`oid`	`pg_proc.oid`	触发器所调用的函数
`tgtype`	`int2`		触发器类型，触发条件，详见注释
`tgenabled`	`char`		触发模式，详见下。`O
`tgisinternal`	`bool`		如果是内部用于约束的触发器则为真
`tgconstrrelid`	`oid`	`pg_class.oid`	参照完整性约束中被引用的表，无则为0
`tgconstrindid`	`oid`	`pg_class.oid`	支持约束的相关索引，没有则为0
`tgconstraint`	`oid`	`pg_constraint.oid`	与触发器相关的约束对象
`tgdeferrable`	`bool`		`DEFERRED`则为真
`tginitdeferred`	`bool`		`INITIALLY DEFERRED`则为真
`tgnargs`	`int2`		传入触发器函数的字符串参数个数
`tgattr`	`int2vector`	`pg_attribute.attnum`	如果是列级更新触发器，这里存储列号，否则为空数组。
`tgargs`	`bytea`		传递给触发器的参数字符串，C风格零结尾字符串
`tgqual`	`pg_node_tree`		触发器`WHEN`条件的内部表示
`tgoldtable`	`name`		`OLD TABLE`的`REFERENCING`列名称，无则为空
`tgnewtable`	`name`		`NEW TABLE`的`REFERENCING`列名称，无则为空

触发器类型

TRIGGER_TYPE_ROW         (1 << 0)  // [0] 0:语句级 	1:行级
TRIGGER_TYPE_BEFORE      (1 << 1)  // [1] 0:AFTER 	1:BEFORE
TRIGGER_TYPE_INSERT      (1 << 2)  // [2] 1: INSERT
TRIGGER_TYPE_DELETE      (1 << 3)  // [3] 1: DELETE
TRIGGER_TYPE_UPDATE      (1 << 4)  // [4] 1: UPDATE
TRIGGER_TYPE_TRUNCATE    (1 << 5)  // [5] 1: TRUNCATE
TRIGGER_TYPE_INSTEAD     (1 << 6)  // [6] 1: INSTEAD OF

触发器模式

触发器tgenabled字段控制触发器的工作模式，参数session_replication_role 可以用于配置触发器的触发模式。该参数可以在会话层级更改，可能的取值包括：origin(default),replica,local。

(D)isable触发器永远不会被触发，(A)lways触发器在任何情况下触发， (O)rigin触发器会在origin|local模式触发（默认），而 (R)eplica触发器replica模式触发。R触发器主要用于逻辑复制，例如pglogical的复制连接就会将会话参数session_replication_role设置为replica，而R触发器只会在该连接进行的变更上触发。

ALTER TABLE tbl ENABLE TRIGGER tgname; -- 设置触发模式为O (本地连接写入触发，默认)
ALTER TABLE tbl ENABLE REPLICA TRIGGER tgname; -- 设置触发模式为R (复制连接写入触发)
ALTER TABLE tbl ENABLE ALWAYS TRIGGER tgname; -- 设置触发模式为A (始终触发)
ALTER TABLE tbl DISABLE TRIGGER tgname; -- 设置触发模式为D (禁用)

在information_schema中还有两个触发器相关的视图：information_schema.triggers, information_schema.triggered_update_columns，表过不提。

触发器FAQ

触发器可以建在哪些类型的表上？

普通表（分区表主表，分区表分区表，继承表父表，继承表子表），视图，外部表。

触发器的类型限制

视图上不允许建立BEFORE与AFTER触发器（不论是行级还是语句级）
视图上只能建立INSTEAD OF触发器，INSERTEAD OF触发器也只能建立在视图上，且只有行级，不存在语句级INSTEAD OF触发器。
INSTEAD OF` 触发器只能定义在视图上，并且只能使用行级触发器，不能使用语句级触发器。

触发器与锁

在表上创建触发器会先尝试获取表级的Share Row Exclusive Lock。这种锁会阻止底层表的数据变更，且自斥。因此创建触发器会阻塞对表的写入。

触发器与COPY的关系

COPY只是消除了数据解析打包的开销，实际写入表中时仍然会触发触发器，就像INSERT一样。

理解字符编码

如果不了解字符编码的基本原理，即使只是简单常规的字符串比较、排序、随机访问操作，都可能会一不小心栽进大坑中。尝试写这一篇科普文，希望能讲清楚这个问题。

著： 冯若航（@Vonng） | 2018-07-01

程序员，是与Code（代码/编码）打交道的，而字符编码又是最为基础的编码。如何使用二进制数来表示字符，这个字符编码问题并没有看上去那么简单，实际上它的复杂程度远超一般人的想象：输入、比较排序与搜索、反转、换行与分词、大小写、区域设置，控制字符，组合字符与规范化，排序规则，处理不同语言中的特异需求，变长编码，字节序与BOM，Surrogate，历史兼容性，正则表达式兼容性，微妙与严重的安全问题等等等等。

如果不了解字符编码的基本原理，即使只是简单常规的字符串比较、排序、随机访问操作，都可能会一不小心栽进大坑中。但根据我的观察，很多工程师与程序员却对字符编码本身几近一无所知，只是对诸如ASCII，Unicode，UTF这些名词有一些模糊的感性认识。因此尝试写这一篇科普文，希望能讲清楚这个问题。

0x01 基本概念

万物皆数 —— 毕达哥拉斯

为了解释字符编码，我们首先需要理解什么是编码，什么又是字符？

编码

从程序员的视角来看，我们有着许许多多的基础数据类型：整数，浮点数，字符串，指针。程序员将它们视作理所当然的东西，但从数字计算机的物理本质来看，只有一种类型才是真正的基础类型：二进制数。

而编码（Code）就是这些高级类型与底层二进制表示之间映射转换的桥梁。编码分为两个部分：编码（encode）与解码（decode），以无处不在的自然数为例。数字42，这个纯粹抽象的数学概念，在计算机中可能就会表示为00101010的二进制位串（假设使用8位整型）。从抽象数字42到二进制数表示00101010的这个过程就是编码。相应的，当计算机读取到00101010这个二进制位串时，它会根据上下文将其解释为抽象的数字42，这个过程就是解码（decode）。

任何‘高级’数据类型与底层二进制表示之间都有着编码与解码的过程，比如单精度浮点数，这种看上去这么基础的类型，也存在着一套相当复杂的编码过程。例如在float32中，1.0和-2.0就表示为如下的二进制串：

0 01111111 00000000000000000000000 = 1
1 10000000 00000000000000000000000 = −2

字符串当然也不例外。字符串是如此的重要与基础，以至于几乎所有语言都将其作为内置类型而实现。字符串，它首先是一个串（String），所谓串，就是由同类事物依序构成的序列。对于字符串而言，就是由**字符（Character）**构成的序列。字符串或字符的编码，实际上就是将抽象的字符序列映射为其二进制表示的规则。

不过，在讨论字符编码问题之前，我们先来看一看，什么是字符？

字符

字符是指字母、数字、标点、表意文字（如汉字）、符号、或者其他文本形式的书写“原子”。它是书面语中最小语义单元的抽象实体。这里说的字符都是抽象字符（abstract character），其确切定义是：用于组织、控制、显示文本数据的信息单元。

抽象字符是一种抽象的符号，与具体的形式无关：区分字符（character）与字形（Glyph）是非常重要的，我们在屏幕上看到的有形的东西是字形（Glyph），它是抽象字符的视觉表示形式。抽象字符通过渲染（Render）呈现为字形，用户界面呈现的字形通过人眼被感知，通过人脑被认知，最终又在人的大脑中还原为抽象的实体概念。字形在这个过程中起到了媒介的作用，但决不能将其等价为抽象字符本身。

要注意的是，虽然多数时候字形与字符是一一对应的，但仍然存在一些多对多的情况：一个字形可能由多个字符组合而成，例如抽象字符à（拼音中的第四声a），我们将其视作单个‘字符’，但它既可以真的是一个单独的字符，也可以由字符a与去声撇号字符 ̀组合而成。另一方面，一个字符也可能由多个字形组成，例如很多阿拉伯语印地语中的文字，由很多图元（字形）组成的符号，复杂地像一幅画，实际上却是单个字符。

>>> print u'\u00e9', u'e\u0301',u'e\u0301\u0301\u0301'
é é é́́

字形的集合构成了字体（font），不过那些都属于渲染的内容：渲染是将字符序列映射为字形序列的过程。那是另一个堪比字符编码的复杂主题，本文不会涉及渲染的部分，而专注于另一侧：将抽象字符转变为二进制字节序列的过程，即，字符编码（Character Encoding）。

思路

我们会想，如果有一张表，能将所有的字符一一映射到字节byte(s)，问题不就解决了吗？实际上对于英文和一些西欧文字而言，这么做是很直观的想法，ASCII就是这样做的：它通过ASCII编码表，使用一个字节中的7位，将128个字符编码为相应的二进制值，一个字符正好对应一个字节（单射而非满射，一半字节没有对应字符）。一步到位，简洁、清晰、高效。

计算机科学发源于欧美，因而文本处理的问题，一开始指的就是英文处理的问题。不过计算机是个好东西，世界各族人民都想用。但语言文字是一个极其复杂的问题：学一门语言文字已经相当令人头大，更别提设计一套能够处理世界各国语言文字的编码标准了。从简单的ASCII发展到当代的大一统Unicode标准，人们遇到了各种问题，也走过一些弯路。

好在计算机科学中，有句俗语：“计算机科学领域的任何问题都可以通过增加一个间接的中间层来解决”。字符编码的模型与架构也是随着历史而不断演进的，下面我们就先来概览一下现代编码模型中的体系结构。

0x02 模型概览

现代编码模型自底向上分为五个层次：
抽象字符表（Abstract Character Repertoire, ACR）
编码字符集（Coded Character Set, CCS）
字符编码表（Character Encoding Form, CEF）
字符编码方案（Character Encoding Schema, CES）
传输编码语法（Transfer Encoding Syntax, TES）

我们所熟悉的诸多名词，都可以归类到这个模型的相应层次之中。例如，Unicode字符集（UCS），ASCII字符集，GBK字符集，这些都属于编码字符集CCS；而常见的UTF8，UTF16，UTF32这些概念，都属于字符编码表CEF，不过也有同名的字符编码方案CES。而我们熟悉的base64，URLEncode这些就属于传输编码语法TES。

这些概念之间的关系可以用下图表示：

可以看到，为了将一个抽象字符转换为二进制，中间其实经过了几次概念的转换。在抽象字符序列与字节序列间还有两种中间形态：码位序列与码元序列。简单来说：

所有待编码的抽象字符构成的集合，称为抽象字符集。
因为我们需要指称集合中的某个具体字符，故为每一个抽象字符指定一个唯一的自然数作为标识，这个被指定的自然数，就称作字符的码位（Code Point）。
码位与字符集中的抽象字符是一一对应的。抽象字符集中的字符经过编码就形成了编码字符集。
码位是正整数，但计算机的整数表示范围是有限的，因此需要调和无限的码位与有限的整型之间的矛盾。字符编码表将码位映射为码元序列（Code Unit Sequence），将整数转变为计算机中的整型。
计算机中多字节整型存在大小端字节序的问题，字符编码方案指明了字节序问题的解决方案。

Unicode标准为什么不像ASCII那样一步到位，直接将抽象字符映射为二进制表示呢？实际上如果只有一种字符编码方案，譬如UTF-8，那么确实是一步到位的。可惜因为一些历史原因（比如觉得65536个字符绝对够用了…），我们有好几种编码方案。但不论如何，比起各国自己搞的百花齐放的编码方案，Unicode的编码方案已经是非常简洁了。可以说，每一层都是为了解决一些问题而不得已引入的：

抽象字符集到编码字符集解决了唯一标识字符的问题（字形无法唯一标识字符）；
编码字符集到字符编码表解决了无限的自然数到有限的计算机整型的映射问题（调和无限与有限）；
字符编码方案则解决了字节序的问题（解决传输歧义）。

下面让我们来看一下每个层次之间的细节。

0x03 字符集

字符集，顾名思义就是字符的集合。字符是什么，在第一节中已经解释过了。在现代编码模型中，有两种层次不同的字符集：抽象字符集 ACR与编码字符集 CCS。

抽象字符集 ACR

抽象字符集顾名思义，指的是抽象字符的集合。已经有了很多标准的字符集定义，US-ASCII, UCS(Unicode)，GBK这些我们耳熟能详的名字，都是(或至少是)抽象字符集

US-ASCII定义了128个抽象字符的集合。GBK挑选了两万多个中日韩汉字和其他一些字符组成字符集，而UCS则尝试去容纳一切的抽象字符。它们都是抽象字符集。

抽象字符英文字母A同时属于US-ASCII, UCS, GBK这三个字符集。
抽象字符中文文字蛤不属于US-ASCII，属于GBK字符集，也属于UCS字符集。
抽象文字 Emoji 😂不属于US-ASCII与GBK字符集，但属于UCS字符集。

抽象字符集可以使用类似set的数据结构来表示：

# ACR
{"a","啊","あ","Д","α","å","😯"}

编码字符集 CCS

集合的一个重要特性，就是无序性。集合中的元素都是无序的，所以抽象字符集中的字符都是无序的。

这就带来一个问题，如何指称字符集中的某个特定字符呢？我们不能抽象字符的字形来指代其实体，原因如前面所说，看上去一样的字形，实际上可能由不同的字符组合而成（如字形à就有两种字符组合方式）。对于抽象字符，我们有必要给它们分配唯一对应的ID，用关系型数据库的话来说，字符数据表需要一个主键。这个码位分配（Code Point Allocation）的操作就称为编码（Encode）。它将抽象字符与一个正整数关联起来。

如果抽象字符集中的所有字符都有了对应的码位（Code Point/Code Position），这个集合就升级成了映射：类似于从set数据结构变成了dict。我们称这个映射为编码字符集 CCS。

# CCS
{
  "a": 97,
  "啊": 21834,
  "あ": 12354,
  "Д": 1044,
  "α": 945,
  "å": 229,
  "😯": 128559
}

注意这里的映射是单射，每个抽象字符都有唯一的正整数码位，但并不是所有的正整数都有对应的抽象字符。码位被分为七大类：图形，格式，控制，代理，非字符，保留。像代理（Surrogate, D800-DFFF）区中的码位，单独使用时就不对应任何字符。

抽象字符集与编码字符集之间的区别通常是Trivial的，毕竟指定字符的同时通常也会指定一个顺序，为每个字符分配一个数字ID。所以我们通常就将它们统称为字符集。字符集解决的问题是，将抽象字符单向映射为自然数。那么既然计算机已经解决了整数编码的问题，是不是直接用字符码位的整型二进制表示就可以了呢？

不幸的是，还有另外一个问题。字符集有开放与封闭之分，譬如ASCII字符集定义了128个抽象字符，再也不会增加。它就是一个封闭字符集。而Unicode尝试收纳所有的字符，一直在不断地扩张之中。截止至2016.06，Unicode 9.0.0已经收纳了128,237个字符，并且未来仍然会继续增长，它是一个开放的字符集。开放意味着字符的数量是没有上限的，随时可以添加新的字符，例如Emoji，几乎每年都会有新的表情字符被引入到Unicode字符集中。这就产生了一对内在的矛盾：无限的自然数与有限的整型值之间的矛盾。

而字符编码表，就是为了解决这个问题的。

0x04 字符编码表

字符集解决了抽象字符到自然数的映射问题，将自然数表示为二进制就是字符编码的另一个核心问题了。字符编码表（CEF）会将一个自然数，转换为一个或多个计算机内部的整型数值。这些整型数值称为码元。码元是能用于处理或交换编码文本的最小比特组合。

码元与数据的表示关系紧密，通常计算机处理字符的码元为一字节的整数倍：1字节，2字节，4字节。对应着几种基础的整型：uint8, uint16, uint32，单字节、双字节、四字节整型。整形的计算往往以计算机的字长作为一个基础单元，通常来讲，也就是4字节或8字节。

曾经，人们以为使用16位短整型来表示字符就足够了，16位短整型可以表示2的十六次方个状态，也就是65536个字符，看上去已经足够多了。但是程序员们很少从这种事情上吸取教训：光是中国的汉字可能就有十万个，一个旨在兼容全世界字符的编码不能不考虑这一点。因此如果使用一个整型来表示一个码位，双字节的短整型int16并不足以表示所有字符。另一方面，四字节的int32能表示约41亿个状态，在进入星辰大海宇宙文明的阶段之前，恐怕是不太可能有这么多的字符需要表示的。（实际上到现在也就分配了不到14万个字符）。

根据使用码元单位的不同，我们有了三种字符编码表：UTF8，UTF-16，UTF-32。

属性\编码	UTF8	UTF16	UTF32
使用码元	`uint8`	`uint16`	`uint32`
码元长度	1byte = 8bit	2byte = 16bit	4byte = 32bit
编码长度	1码位 = 1~4码元	1码位 = 1或2码元	1码位 = 1码元
独门特性	兼容ASCII	针对BMP优化	定长编码

定长编码与变长编码

双字节的整数只能表示65536个状态，对于目前已有的十四万个字符显得捉襟见肘。但另一方面，四字节整数可以表示约42亿个状态。恐怕直到人类进入宇宙深空时都遇不到这么多字符。因此对于码元而言，如果采用四字节，我们可以确保编码是定长的：一个（表示字符的）自然数码位始终能用一个uint32表示。但如果使用uint8或uint16作为码元，超出单个码元表示范围的字符就需要使用多个码元来表示了。因此是为变长编码。因此，UTF-32是定长编码，而UTF-8和UTF-16是变长编码。

设计编码时，容错是最为重要的考量之一：计算机并不是绝对可靠的，诸如比特反转，数据坏块等问题是很有可能遇到的。字符编码的一个基本要求就是自同步（self-synchronization ）。对于变长编码而言，这个问题尤为重要。应用程序必须能够从二进制数据中解析出字符的边界，才可以正确解码字符。如果如果文本数据中出现了一些细微的错漏，导致边界解析错误，我们希望错误的影响仅仅局限于那个字符，而不是后续所有的文本边界都失去了同步，变成乱码无法解析。

为了保证能够从编码的二进制中自然而然的凸显出字符边界，所有的变长编码方案都应当确保编码之间不会出现重叠（Overlap）：譬如一个双码元的字符，其第二个码元本身不应当是另一个字符的表示，否则在出现错误时，程序无法分辨出它到底是一个单独的字符，还是某个双码元字符的一部分，就达不到自同步的要求。我们在UTF-8和UTF-16中可以看到，它们的编码表都是针对这一于要求而设计的。

下面让我们来看一下三种具体的编码表：UTF-32, UTF-16, UTF-8。

UTF32

最为简单的编码方案，就是使用一个四字节标准整型int32表示一个字符，也就是采用四字节32位无符号整数作为码元，即，UTF-32。很多时候计算机内部处理字符时，确实是这么做的。例如在C语言和Go语言中，很多API都是使用int来接收单个字符的。

UTF-32最突出的特性是定长编码，一个码位始终编码为一个码元，因此具有随机访问与实现简单的优势：第n个字符，就是数组中的第n个码元，使用简单，实现更简单。当然这样的编码方式有个缺陷：特别浪费存储。虽然总共有十几万个字符，但即使是中文，最常用的字符通常码位也落在65535以内，可以使用两个字节来表示。而对于纯英文文本而言，只要一个字节来表示一个字符就足够了。因此使用UTF32可能导致二至四倍的存储消耗，都是真金白银啊。当然在内存与磁盘容量没有限制的时候，用UTF32可能是最为省心的做法。

UTF16

UTF16是一种变长编码，使用双字节16位无符号整型作为码元。位于U+0000-U+FFFF之间的码位使用单个16位码元表示，而在U+10000-U+10FFFF之间的码位则使用两个16位的码元表示。这种由两个码元组成的码元对儿，称为代理对（Surrogate Paris）。

UTF16是针对**基本多语言平面（Basic Multilingual Plane, BMP）**优化的，也就是码位位于U+FFFF以内可以用单个16位码元表示的部分。Anyway，对于落在BMP内的高频常用字符而言，UTF-16可以视作定长编码，也就有着与UTF32一样随机访问的好处，但节省了一倍的存储空间。

UTF-16源于早期的Unicode标准，那时候人们认为65536个码位足以表达所有字符了。结果汉字一种文字就足够打爆它了……。**代理（Surrogate）**就是针对此打的补丁。它通过预留一部分码位作为特殊标记，将UTF-16改造成了变长编码。很多诞生于那一时期的编程语言与操作系统都受此影响（Java，Windows等）

对于需要权衡性能与存储的应用，UTF-16是一种选择。尤其是当所处理的字符集仅限于BMP时，完全可以假装它是一种定长编码。需要注意的是UTF-16本质上是变长的，因此当出现超出BMP的字符时，如果以定长编码的方式来计算处理，很可能会出现错误，甚至崩溃。这也是为什么很多应用无法正确处理Emoji的原因。

UTF8

UTF8是一种完完全全的变长编码，它使用单字节8位无符号整数作为码元。0xFF以内的码位使用单字节编码，且与ASCII保持完全一致；U+0100-U+07FF之间的码位使用两个字节；U+0800到U+FFFF之间的码位使用三字节，超出U+FFFF的码位使用四字节，后续还可以继续扩展到最多用7个字节来表示一个字符。

UTF8最大的优点，一是面向字节编码，二是兼容ASCII，三是能够自我同步。众所周知，只有多字节的类型才会存在大小端字节序的问题，如果码元本身就是单个字节，就压根不存在字节序的问题了。而兼容性，或者说ASCII透明性，使得历史上海量使用ASCII编码的程序与文件无需任何变动就能继续在UTF-8编码下继续工作（ASCII范围内）。最后，自我同步机制使得UTF-8具有良好的容错性。

这些特性这使得UTF-8非常适合用于信息的传输与交换。互联网上大多数文本文件的编码都是UTF-8。而Go、Python3也采用了UTF-8作为其默认编码。

当然，UTF-8也是有代价的。对于中文而言，UTF-8通常使用三个字节进行编码。比起双字节编码而言带来了50%的额外存储开销。与此同时，变长编码无法进行随机访问字符，也使得处理相比“定长编码”更为复杂，也会有更高的计算开销。对于正确性不甚在乎，但对性能有严苛要求的中文文字处理应用可能不会喜欢UTF-8。

UTF-8的一个巨大优势就在于，它没有字节序的问题。而UTF-16与UTF-32就不得不操心大端字节在前还是小端字节在前的问题了。这个问题通常在**字符编码方案（Character Encoding Schema）**中通过BOM来解决。

字符编码方案

字符编码表 CEF解决了如何将自然数码位编码为码元序列的问题，无论使用哪种码元，计算机中都有相应的整型。但我们可以说编码问题就解决了吗？还不行，假设一个字符按照UTF16拆成了若干个码元组成的码元序列，因为每个码元都是一个uint16，实际上各由两个字节组成。因此将码元序列化为字节序列的时候，就会遇到一些问题：每个码元究竟是高位字节在前还是低位字节在前呢？这就是大小端字节序问题。

对于网络交换和本地处理，大小端序各有优劣，因此不同的系统往往也会采用不同的大小端序。为了标明二进制文件的大小端序，人们引入了**字节序标记（Byte Order Mark, BOM）**的概念。BOM是放置于编码字节序列开始处的一段特殊字节序列，用于表示文本序列的大小端序。

字符编码方案，实质上就是带有字节序列化方案的字符编码表。即：CES = 解决端序问题的CEF。对于大小端序标识方法的不同选择，产生了几种不同的字符编码方案：

UTF-8：没有端序问题。
UTF-16LE：小端序UTF-16，不带BOM
UTF-16BE：大端序UTF-16，不带BOM
UTF-16：通过BOM指定端序
UTF-32LE：小端序UTF-32，不带BOM
UTF-32BE：大端序UTF-32，不带BOM
UTF-32：通过BOM指定端序

UTF-8因为已经采用字节作为码元了，所以实际上不存在字节序的问题。其他两种UTF，都有三个相应地字符编码方案：一个大端版本，一个小端版本，还有一个随机应变大小端带 BOM的版本。

当然要注意，在当前上下文中的UTF-8，UTF-16，UTF-32其实是CES层次的概念，即带有字节序列化方案的CEF，这会与CEF层次的同名概念产生混淆。因此，当我们在说UTF-8，UTF-16，UTF-32时，一定要注意区分它是CEF还是CES。例如，作为一种编码方案的UTF-16产生的字节序列是会带有BOM的，而作为一种编码表的UTF-16产生的码元序列则是没有BOM这个概念的。

0x05 UTF-8

介绍完了现代编码模型，让我们深入看一下一个具体的编码方案：UTF-8。 UTF-8将Unicode码位映射成1~4个字节，满足如下规则：

标量值	字节1	字节2	字节3	字节4
`00000000 0xxxxxxx`	`0xxxxxxx`
`00000yyy yyxxxxxx`	`110yyyyy`	`10xxxxxx`
`zzzzyyyy yyxxxxxx`	`1110zzzz`	`10yyyyyy`	`10xxxxxx`
`000uuuuu zzzzyyyy yyxxxxxx`	`11110uuu`	`10uuzzzz`	`10yyyyyy`	`10xxxxxx`

其实比起死记硬背，UTF-8的编码规则可以通过几个约束自然而然地推断出来：

与ASCII编码保持兼容，因此有第一行的规则。
需要有自我同步机制，因此需要在首字节中保有当前字符的长度信息。
需要容错机制，码元之间不允许发生重叠，这意味着字节2,3,4,…不能出现字节1可能出现的码元。

0, 10, 110, 1110, 11110, …这些是不会发生冲突的字节前缀，0前缀被ASCII兼容规则对应的码元用掉了。次优的10前缀就分配给后缀字节作为前缀，表示自己是某个字符的外挂部分。相应地，110,1110,11110这几个前缀就用于首字节中的长度标记，例如110前缀的首字节就表示当前字符还有一个额外的外挂字节，而1110前缀的首字节就表示还有两个额外的外挂字节。因此，UTF-8的编码规则其实非常简单。下面是使用Go语言编写的函数，展示了将一个码位编码为UTF-8字节序列的逻辑：

func UTF8Encode(i uint32) (b []byte) {
	switch {
	case i <= 0xFF: 	/* 1 byte */
		b = append(b, byte(i))
	case i <= 0x7FF: 	/* 2 byte */
		b = append(b, 0xC0|byte(i>>6))
		b = append(b, 0x80|byte(i)&0x3F)
	case i <= 0xFFFF: 	/* 3 byte*/
		b = append(b, 0xE0|byte(i>>12))
		b = append(b, 0x80|byte(i>>6)&0x3F)
		b = append(b, 0x80|byte(i)&0x3F)
	default: 			/* 4 byte*/
		b = append(b, 0xF0|byte(i>>18))
		b = append(b, 0x80|byte(i>>12)&0x3F)
		b = append(b, 0x80|byte(i>>6)&0x3F)
		b = append(b, 0x80|byte(i)&0x3F)
	}
	return
}

0x06 编程语言中的字符编码

讲完了现代编码模型，让我们来看两个现实编程语言中的例子：Go和Python2。这两者都是非常简单实用的语言。但在字符编码的模型设计上却是两个典型：一个正例一个反例。

Go

Go语言的缔造者之一，Ken Thompson，同时也是UTF-8的发明人（同时也是C语言，Go语言，Unix的缔造者），因此Go对于字符编码的实现堪称典范。Go的语法与C和Python类似，非常简单。它也是一门比较新的语言，抛开了一些历史包袱，直接使用了UTF-8作为默认编码。

UTF-8编码在Go语言中有着特殊的位置，无论是源代码的文本编码，还是字符串的内部编码都是UTF-8。Go绕开前辈语言们踩过的坑，使用了UTF8作为默认编码是一个非常明智的选择。相比之下，Java，Javascript都使用 UCS-2/UTF16作为内部编码，早期还有随机访问的优势，可当Unicode增长超出BMP之后，这一优势也荡然无存了。相比之下，字节序，Surrogate , 空间冗余带来的麻烦却仍让人头大无比。

Go语言中有三种重要的基本文本类型： byte, rune,string，分别是字节，字符，与字符串。其中：

字节byte实际上是uint8的别名，[]byte表示字节序列。
字符rune实质上是int32的别名，表示一个Unicode的码位。[]rune表示码位序列
字符串string实质上是UTF-8编码的二进制字节数组（底层是字节数组），加上一个长度字段。

而相应的编码与解码操作为：

编码：使用string(rune_array)将字符数组转换为UTF-8编码的字符串。
解码：使用for i,r := range str语法迭代字符串中的字符，实际上是依次将二进制UTF-8字节序列还原为码位序列。

更详细的内容可以参阅文档，我也写过一篇博文详细解释了Go语言中的文本类型。

Python2

如果说Go可以作为字符编码处理实现的典范，那么Python2则可以当做一个最典型的反例了。Python2使用ASCII作为默认编码以及默认源文件编码，因此如果不理解字符编码的相关知识，以及Python2的一些设计，在处理非ASCII编码很容易出现一些错误。实际上只要看到Python3与Python2在字符编码处理上的差异有多大就大概有数了。Python2用的人还是不少，所以这里的坑其实很多，但其实最严重的问题是：

Python2的默认编码方案的非常不合理。
Python2的字符串类型与字符串字面值很容易让人混淆。

第一个问题是，Python2的默认编码方案的非常不合理：

Python2使用'xxx'作为字节串字面值，其类型为<str>，但<str>本质上是字节串而不是字符串。
Python2使用u'xxx'作为字符串字面值的语法，其类型为<unicode>，<unicode>是真正意义上的字符串，每一个字符都属于UCS。

与此同时，Python2解释器的默认编码方案(CES)是US-ASCII 。作为对照，Java，C#，Javascript等语言内部的默认编码方案都是UTF-16，Go语言的内部默认编码方案使用UTF-8。默认使用US-ASCII的python2简直是骨骼清奇，当然，这也有一部分历史原因在里头。Python3就乖乖地改成UTF-8了。

第二个问题：python的默认’字符串类型<str>与其叫字符串，不如叫字节串，用下标去访问的每一个元素都是一个字节。而<unicode>类型才是真正意义上的字符串，用下标去访问的每一个元素都是一个字符(虽然底下可能每个字符长度不同)。字符串<unicode> 与字节串<str> 的关系为：

字符串<unicode> 通过字符编码方案编码得到字节串<str>
字节串<str> 通过字符编码方案解码得到字符串<unicode>

字节串就字节串，为啥要起个类型名叫<str>呢？另外，字面值语法用一对什么前缀都没有的引号表示str，这样的设计非常反直觉。因此让很多人掉进了坑里。当然，<str>与<unicode>这样的类型设计以及两者的关系设计本身是无可厚非的。该黑的应该是这两个类型起的名字和字面值表示方法。至于怎么改进是好的，Python3已经给出答案。在理解了字符编码模型之后，什么样的操作才是正确的操作，读者应该已经心里有数了。

微信公众号原文

并发异常那些事

并发程序很难写对，更难写好。本文将阐述SQL92标准中定义的隔离级别及其缺陷，现代模型中的隔离级别与定义这些级别的异常现象。

著： 冯若航（@Vonng） | 2018-06-09

并发异常那些事

并发程序很难写对，更难写好。很多程序员也没有真正弄清楚这些问题，不过是一股脑地把这些问题丢给数据库而已。并发异常并不仅仅是一个理论问题：这些异常曾经造成过很多资金损失，耗费过大量财务审计人员的心血。但即使是最流行、最强大的关系型数据库（通常被认为是“ACID”数据库），也会使用弱隔离级别，所以它们也不一定能防止这些并发异常的发生。比起盲目地依赖工具，我们应该对存在的并发问题的种类，以及如何防止这些问题有深入的理解。本文将阐述SQL92标准中定义的隔离级别及其缺陷，现代模型中的隔离级别与定义这些级别的异常现象。

0x01 引子

大多数数据库都会同时被多个客户端访问。如果它们各自读写数据库的不同部分，这是没有问题的，但是如果它们访问相同的数据库记录，则可能会遇到并发异常。

下图是一个简单的并发异常案例：两个客户端同时在数据库中增长一个计数器。（假设数据库中没有自增操作）每个客户端需要读取计数器的当前值，加1再回写新值。因为有两次增长操作，计数器应该从42增至44；但由于并发异常，实际上只增长至43。

图两个客户之间的竞争状态同时递增计数器

事务ACID特性中的I，即隔离性（Isolation）就是为了解决这种问题。隔离性意味着，同时执行的事务是相互隔离的：它们不能相互踩踏。传统的数据库教科书将隔离性形式化为可串行化（Serializability），这意味着每个事务可以假装它是唯一在整个数据库上运行的事务。数据库确保当事务已经提交时，结果与它们按顺序运行（一个接一个）是一样的，尽管实际上它们可能是并发运行的。如果两个事务不触及相同的数据，它们可以安全地并行（parallel）运行，因为两者都不依赖于另一个。当一个事务读取由另一个事务同时进行修改的数据时，或者当两个事务试图同时修改相同的数据时，并发问题（竞争条件）才会出现。只读事务之间不会有问题，但只要至少一个事务涉及到写操作，就有可能出现冲突，或曰：并发异常。并发异常很难通过测试找出来，因为这样的错误只有在特殊时机下才会触发。这样的时机可能很少，通常很难重现。也很难对并发问题进行推理研究，特别是在大型应用中，你不一定知道有没有其他的应用代码正在访问数据库。在一次只有一个用户时，应用开发已经很麻烦了，有许多并发用户使其更加困难，因为任何数据都可能随时改变。出于这个原因，数据库一直尝试通过提供事务隔离（transaction isolation）来隐藏应用开发中的并发问题。从理论上讲，隔离可以通过假装没有并发发生，让程序员的生活更加轻松：可串行化的隔离等级意味着数据库保证事务的效果与真的串行执行（即一次一个事务，没有任何并发）是等价的。实际上不幸的是：隔离并没有那么简单。可串行化会有性能损失，许多数据库与应用不愿意支付这个代价。因此，系统通常使用较弱的隔离级别来防止一部分，而不是全部的并发问题。这些弱隔离等级难以理解，并且会导致微妙的错误，但是它们仍然在实践中被使用。一些流行的数据库如Oracle 11g，甚至没有实现可串行化。在Oracle中有一个名为“可串行化”的隔离级别，但实际上它实现了一种叫做**快照隔离（snapshot isolation）**的功能，这是一种比可串行化更弱的保证。在研究现实世界中的并发异常前，让我们先来复习一下SQL92标准定义的事务隔离等级。

0x02 SQL92标准

按照ANSI SQL92的标准，三种**现象（phenomena）**区分出了四种隔离等级，如下表所示：

隔离等级	脏写P0	脏读 P1	不可重复读 P2	幻读 P3
读未提交RU	✅	⚠️	⚠️	⚠️
读已提交RC	✅	✅	⚠️	⚠️
可重复读RR	✅	✅	✅	⚠️
可串行化SR	✅	✅	✅	✅

四种现象分别缩写为P0，P1，P2，P3，P是**现象（Phenonmena）**的首字母。
脏写没有在标准中指明，但却是任何隔离等级都需要必须避免的异常

这四种异常可以概述如下：

P0 脏写（Dirty Write）

事务T1修改了数据项，而另一个事务T2在T1提交或回滚之前就修改了T1修改的数据项。无论如何，事务必须避免这种情况。

P1 脏读（Dirty Read）

事务T1修改了数据项，另一个事务T2在T1提交或回滚前就读到了这个数据项。如果T1选择了回滚，那么T2实际上读到了一个事实上不存在（未提交）的数据项。

P2 不可重复读（ Non-repeatable or Fuzzy Read）

事务T1读取了一个数据项，然后另一个事务T2修改或删除了该数据项并提交。如果T1尝试重新读取该数据项，它就会看到修改过后的值，或发现值已经被删除。

P3 幻读（Phantom）

事务T1读取了满足某一搜索条件的数据项集合，事务T2创建了新的满足该搜索条件的数据项并提交。如果T1再次使用同样的搜索条件查询，它会获得与第一次查询不同的结果。

标准的问题

SQL92标准对于隔离级别的定义是有缺陷的 —— 模糊，不精确，并不像标准应有的样子独立于实现。标准其实针对的是基于锁调度的实现来讲的，而基于多版本的实现就很难对号入座。有几个数据库实现了“可重复读”，但它们实际提供的保证存在很大的差异，尽管表面上是标准化的，但没有人真正知道可重复读的意思。标准还有其他的问题，例如在P3中只提到了创建/插入的情况，但实际上任何写入都可能导致异常现象。此外，标准对于可串行化也语焉不详，只是说“SERIALIZABLE隔离级别必须保证通常所知的完全序列化执行”。

现象与异常

现象（phenomena）与异常（anomalies）并不相同。现象不一定是异常，但异常肯定是现象。例如在脏读的例子中，如果T1回滚而T2提交，那么这肯定算一种异常：看到了不存在的东西。但无论T1和T2各自选择回滚还是提交，这都是一种可能导致脏读的现象。通常而言，异常是一种严格解释，而现象是一种宽泛解释。

0x03 现代模型

相比之下，现代的隔离等级与一致性等级对于这个问题有更清晰的阐述，如图所示：

isolation-level

图：隔离等级偏序关系图

图：一致性与隔离等级偏序关系

右子树主要讨论的是多副本情况下的一致性等级，略过不提。为了讨论便利起见，本图中刨除了MAV、CS、I-CI、P-CI等隔离等级，主要需要关注的是快照隔离SI。

表：各个隔离等级及其可能出现的异常现象

等级\现象	P0	P1	P4C	P4	P2	P3	A5A	A5B
读未提交 RU	✅	⚠️	⚠️	⚠️	⚠️	⚠️	⚠️	⚠️
读已提交 RC	✅	✅	⚠️	⚠️	⚠️	⚠️	⚠️	⚠️
游标稳定性 CS	✅	✅	✅	⚠️?	⚠️?	⚠️	⚠️	⚠️?
可重复读 RR	✅	✅	✅	✅	✅	⚠️	✅	✅
快照隔离 SI	✅	✅	✅	✅	✅	✅?	✅	⚠️
可序列化 SR	✅	✅	✅	✅	✅	✅	✅	✅

带有？标记的表示可能出现异常，依具体实现而异。

主流关系型数据库的实际隔离等级

相应地，将主流关系型数据库为了“兼容标准”而标称的隔离等级映射到现代隔离等级模型中，如下表所示：

表：主流关系型数据库标称隔离等级与实际隔离之间的对照关系

实际\标称	PostgreSQL/9.2+	MySQL/InnoDB	Oracle(11g)	SQL Server
读未提交 RU		RU		RU
读已提交 RC	RC	RC, RR	RC	RC
可重复读 RR				RR
快照隔离 SI	RR		SR	SI
可序列化 SR	SR	SR		SR

以PostgreSQL为例

如果按照ANSI SQL92标准来看，PostgreSQL实际上只有两个隔离等级：RC与SR。

隔离等级	脏读 P1	不可重复读 P2	幻读 P3
RU，RC	✅	⚠️	⚠️
RR，SR	✅	✅	✅

其中，RU和RC隔离等级中可能出现P2与P3两种异常情况。而RR与SR则能避免P1,P2,P3所有的异常。

当然实际上如果按照现代隔离等级模型，PostgreSQL的RR隔离等级实际上是快照隔离SI，无法解决A5B写偏差的问题。直到9.2引入可串行化快照隔离SSI之后才有真正意义上的SR，如下表所示：

标称	实际	P2	P3	A5A	P4	A5B
RC	RC	⚠️	⚠️	⚠️	⚠️	⚠️
RR	SI	✅	✅	✅	✅	⚠️
SR	SR	✅	✅	✅	✅	✅

作为一种粗略的理解，可以将RC等级视作语句级快照，而将RR等级视作事务级快照。

以MySQL为例

MySQL的RR隔离等级因为无法阻止丢失更新问题，被认为没有提供真正意义上的快照隔离/可重复读。

标称	实际	P2	P3	A5A	P4	A5B
RC	RC	⚠️	⚠️	⚠️	⚠️	⚠️
RR	RC	✅	✅？	✅	⚠️	⚠️
SR	SR	✅	✅	✅	✅	✅

参考测试用例：ept/hermitage/mysql

0x04 并发异常

isolation-level

回到这张图来，各个异常等级恰好就是通过可能出现的异常来定义的。如果在某个隔离等级A中会出现的所有异常都不会在隔离等级B中出现，我们就认为隔离等级A弱于隔离等级B。但如果某些异常在等级A中出现，在等级B中避免，同时另一些异常在等级B中出现，却在A中避免，这两个隔离等级就无法比较强弱了。

例如在这幅图中：RR与SI是明显强于RC的。但RR与SI之间的相对强弱却难以比较。SI能够避免RR中可能出现的幻读P3，但会出现写偏差A5B的问题；RR不会出现写偏差A5B，但有可能出现P3幻读。

防止脏写与脏读可以简单地通过数据项上的读锁与写锁来阻止，其形式化表示为：

P0: w1[x]...w2[x]...((c1 or a1) and (c2 or a2)) in any order)

P1: w1[x]...r2[x]...((c1 or a1) and (c2 or a2)) in any order)
A1: w1[x]...r2[x]...(a1 and c2 in any order)

因为大多数数据库使用RC作为默认隔离等级，因此脏写P0，脏读P1等异常通常很难遇到，就不再细说了。

下面以PostgreSQL为例，介绍这几种通常情况下可能出现的并发异常现象：

P2：不可重复读
P3：幻读
A5A：读偏差
P4：丢失跟新
A5B：写偏差

这五种异常有两种分类方式，第一可以按照隔离等级来区分。

P2，P3，A5A，P4是RC中会出现，RR不会出现的异常；A5B是RR中会出现，SR中不会出现的异常。

第二种分类方式是按照冲突类型来分类：只读事务与读写事务之间的冲突，以及读写事务之间的冲突。

P2，P3，A5A是读事务与写事务之间的并发异常，而P4与A5B则是读写事务之间的并发异常。

读-写异常

让我们先来考虑一种比较简单的情况：一个只读事务与一个读写事务之间的冲突。例如：

P2：不可重复读。
A5A：读偏差（一种常见的不可重复读问题）
P3：幻读

在PostgreSQL中，这三种异常都会在RC隔离等级中出现，但使用RR（实际为SI）隔离等级就不会有这些问题。

不可重复读 P2

假设我们有一张账户表，存储了用户的银行账户余额，id是用户标识，balance是账户余额，其定义如下

CREATE TABLE account(
    id 		INTEGER PRIMARY KEY,
    balance	INTEGER
);

譬如，在事务1中前后进行两次相同的查询，但两次查询间，事务2写入并提交，结果查询得到的结果不同。

START TRANSACTION ISOLATION LEVEL READ COMMITTED; -- T1, RC, 只读
START TRANSACTION ISOLATION LEVEL READ COMMITTED; -- T2, RC, 读写

SELECT * FROM account WHERE k = 'a';  -- T1, 查询账户a，看不到任何结果
INSERT INTO account VALUES('a', 500); -- T2, 插入记录(a,500)
COMMIT; -- T2, 提交

SELECT * FROM account WHERE id = 'a'; -- T1, 重复查询，得到结果(a,500)
COMMIT; -- T1陷入迷惑，为什么同样的查询结果不同？

对于事务1而言，在同一个事务中执行相同的查询，竟然会出现不一样的结果，也就是说读取的结果不可重复。这就是不可重复读的一个例子，即现象P2。在PostgreSQL的RC级别中是会出现的，但如果将事务T1的隔离等级设置为RR，就不会出现这种问题了：

START TRANSACTION ISOLATION LEVEL REPEATABLE READ; -- T1, RR, 只读
START TRANSACTION ISOLATION LEVEL READ COMMITTED;  -- T2, RC, 读写

SELECT * FROM counter WHERE k = 'x'; -- T1, 查询不到任何结果
INSERT INTO counter VALUES('x', 10); -- T2, 插入记录(x,10) @ RR
COMMIT; -- T2, 提交

SELECT * FROM counter WHERE k = 'x'; -- T1, 还是查询不到任何结果
COMMIT; -- T1, 在RR下，两次查询的结果保持一致。

不可重复读的形式化表示：

P2: r1[x]...w2[x]...((c1 or a1) and (c2 or a2) in any order)
A2: r1[x]...w2[x]...c2...r1[x]...c1

读偏差 A5A

另一类读-写异常是读偏差（A5A）：考虑一个直观的例子，假设用户有两个账户：a和b，各有500元。

-- 假设有一张账户表，用户有两个账户a，b，各有500元。
CREATE TABLE account(
    id 		INTEGER PRIMARY KEY,
    balance	INTEGER
);
INSERT INTO account VALUES('a', 500), ('b', 500);

现在用户向系统提交从账户b向账户a转账100元的请求，并从网页上并查看自己的账户余额。在RC隔离级别下，下列操作历史的结果可能会让用户感到困惑：

START TRANSACTION ISOLATION LEVEL READ COMMITTED; -- T1, RC, 只读，用户观察
START TRANSACTION ISOLATION LEVEL READ COMMITTED; -- T2, RC, 读写，系统转账

SELECT * FROM account WHERE id = 'a'; -- T1, 用户查询账户a, 500元

UPDATE account SET balance -= 100 WHERE id = 'b'; -- T2, 系统扣减账户b 100元
UPDATE account SET balance += 100 WHERE id = 'a'; -- T2, 系统添加账户a 100元
COMMIT; -- T2, 系统转账事务提交提交

SELECT * FROM account WHERE id = 'a'; -- T1, 用户查询账户b, 400元
COMMIT; -- T1, 用户陷入迷惑，为什么我总余额(400+500)少了100元？

这个例子中，只读事务读取到了系统的一个不一致的快照。这种现象称为读偏差（read skew），记作A5A。但其实说到底，读偏差的根本原因是不可重复读。只要避免了P2，自然能避免A5A。

但读偏差是很常见的一类问题，在一些场景中，我们希望获取一致的状态快照，读偏差是不能接受的。一个典型的场景就是备份。通常对于大型数据库，备份需要花费若干个小时。备份进程运行时，数据库仍然会接受写入操作。因此如果存在读偏差，备份可能会包含一些旧的部分和一些新的部分。如果从这样的备份中恢复，那么不一致（比如消失的钱）就会变成永久的。此外，一些长时间运行的分析查询通常也希望能在一个一致的快照上进行。如果一个查询在不同时间看见不同的东西，那么返回的结果可能毫无意义。

快照隔离是这个问题最常见的解决方案。PostgreSQL的RR隔离等级实际上就是快照隔离，提供了事务级一致性快照的功能。例如，如果我们将T1的隔离等级设置为可重复读，就不会有这个问题了。

START TRANSACTION ISOLATION LEVEL REPEATABLE READ; -- T1, RR, 只读，用户观察
START TRANSACTION ISOLATION LEVEL READ COMMITTED;  -- T2, RC, 读写，系统转账

SELECT * FROM account WHERE id = 'a'; -- T1 用户查询账户a, 500元

UPDATE account SET balance -= 100 WHERE id = 'b'; -- T2 系统扣减账户b 100元
UPDATE account SET balance += 100 WHERE id = 'a'; -- T2 系统添加账户a 100元
COMMIT; -- T2, 系统转账事务提交提交

SELECT * FROM account WHERE id = 'a'; -- T1 用户查询账户b, 500元
COMMIT; -- T1没有观察到T2的写入结果{a:600,b:400}，但它观察到的是一致性的快照。

读偏差的形式化表示：

A5A: r1[x]...w2[x]...w2[y]...c2...r1[y]...(c1 or a1)

幻读 P3

在ANSI SQL92中，幻读是用于区分RR和SR的现象，实际上它经常与不可重复读P2混为一谈。唯一的区别在于读取列时是否使用了谓词（predicate），也就是Where条件。将上一个例子中查询是否存在账户，变为满足特定条件账户的数目，就成了一个所谓的“幻读”问题。

START TRANSACTION ISOLATION LEVEL READ COMMITTED; -- T1, RC, 只读
START TRANSACTION ISOLATION LEVEL READ COMMITTED; -- T2, RC, 读写

SELECT count(*) FROM account WHERE balance > 0;  -- T1, 查询有存款的账户数目。0
INSERT INTO account VALUES('a', 500); -- T2, 插入记录(a,500)
COMMIT; -- T2, 提交

SELECT count(*) FROM account WHERE balance > 0;  -- T1, 查询有存款的账户数目。1
COMMIT; -- T1陷入迷惑，为什么冒出来一个人？

同理，事务1在使用PostgreSQL的RR隔离级别之后，事务1就不会看到满足谓词P的结果发生变化了。

START TRANSACTION ISOLATION LEVEL REPEATABLE READ; -- T1, RR, 只读
START TRANSACTION ISOLATION LEVEL READ COMMITTED;  -- T2, RC, 读写

SELECT count(*) FROM account WHERE balance > 0;  -- T1, 查询有存款的账户数目。0
INSERT INTO account VALUES('a', 500); -- T2, 插入记录(a,500)
COMMIT; -- T2, 提交

SELECT count(*) FROM account WHERE balance > 0;  -- T1, 查询有存款的账户数目。0
COMMIT; -- T1, 读取到了一致的快照（虽然不是最新鲜的）

之所以有这种相当Trivial的区分，因为基于锁的隔离等级实现往往需要额外的谓词锁机制来解决这类特殊的读-写冲突问题。但是基于MVCC的实现，以PostgreSQL的SI为例，就天然地一步到位解决了所有这些问题。

幻读的形式化表示：

P3: r1[P]...w2[y in P]...((c1 or a1) and (c2 or a2) any order)
A3: r1[P]...w2[y in P]...c2...r1[P]...c1

幻读会出现在MySQL的RC，RR隔离等级中，但不会出现在PostgreSQL的RR隔离等级（实际为SI）中。

写-写异常

上面几节讨论了只读事务在并发写入时可能发生的异常。通常这种读取异常可能只要稍后重试就会消失，但如果涉及到写入，问题就比较严重了，因为这种读取到的暂时不一致状态很可能经由写入变成永久性的不一致…。到目前为止我们只讨论了在并发写入发生时，只读事务可以看见什么。如果两个事务并发执行写入，还可能会有一种更有趣的写-写异常：

P4：丢失更新：PostgreSQL的RC级别存在，RR级别不存在（MySQL的RR会存在）。
A5B：写入偏差：PostgreSQL的RR隔离级别会存在。

其中，写偏差（A5B）可以视作丢失更新（P4）的泛化情况。快照隔离能够解决丢失更新的问题，却无法解决写入偏差的问题。解决写入偏差需要真正的可串行化隔离等级。

丢失更新-P4-例1

仍然以上文中的账户表为例，假设有一个账户x，余额500元。

CREATE TABLE account(
    id 		TEXT PRIMARY KEY,
    balance	INTEGER
);
INSERT INTO account VALUES('x', 500);

有两个事务T1，T2，分别希望向该账户打入两笔钱，比如一笔100，一笔200。从顺序执行的角度来看，无论两个事务谁先执行，最后的结果都应当是余额 = 500 + 200 + 100 = 800。

START TRANSACTION ISOLATION LEVEL READ COMMITTED; -- T1
START TRANSACTION ISOLATION LEVEL READ COMMITTED; -- T2

SELECT balance FROM account WHERE id = 'x'; -- T1, 查询当前余额=500
SELECT balance FROM account WHERE id = 'x'; -- T2, 查询当前余额也=500

UPDATE account SET balance = 500 + 100; -- T1, 在原余额基础上增加100元
UPDATE account SET balance = 500 + 200; -- T2, 在原余额基础上增加200元,被T1阻塞。

COMMIT; -- T1, 提交前可以看到余额为600。T1提交后解除对T2的阻塞，T2进行了更新。
COMMIT; -- T2, T2提交,提交前可以看到余额为700
-- 最终结果为700

但奇妙的时机导致了意想不到的结果，最后账户的余额为700元，事务1的转账更新丢失了！

但令人意外的是，两个事务都看到了UPDATE 1的更新结果，都检查了自己更新的结果无误，都收到了事务成功提交的确认。结果事务1的更新丢失了，这就很尴尬了。最起码事务应当知道这里可能出现问题，而不是当成什么事都没有就混过去了。

如果使用RR隔离等级（主要是T2，T1可以是RC，但出于对称性尽量都用RR），后执行更新的语句就会报错中止事务。这就允许应用知耻而后勇，进行重试。

START TRANSACTION ISOLATION LEVEL REPEATABLE READ;  -- T1, 这里RC也可以
START TRANSACTION ISOLATION LEVEL REPEATABLE READ;  -- T2, 关键是T2必须为RR

SELECT balance FROM account WHERE id = 'x'; -- T1, 查询当前余额=500
SELECT balance FROM account WHERE id = 'x'; -- T2, 查询当前余额也=500

UPDATE account SET balance = 500 + 100; -- T1, 在原余额基础上增加100元
UPDATE account SET balance = 500 + 200; -- T2, 在原余额基础上增加200元,被T1阻塞。

COMMIT; -- T1, 提交前可以看到余额为600。T1提交后解除对T2的阻塞
-- T2 Update报错：ERROR:  could not serialize access due to concurrent update

ROLLBACK; -- T2, T2只能回滚
-- 最终结果为600，但T2知道了错误可以重试，并在无竞争的环境中最终达成正确的结果800。

p4-8906213

当然我们可以看到，在RC隔离等级的情况中，T1提交，解除对T2的阻塞时，Update操作已经能够看到T1的变更了（balance=600）。但事务2还是用自己先前计算出的增量值覆盖了T1的写入。对于这种特殊情况，可以使用原子操作解决，例如：UPDATE account SET balance = balance + 100;。这样的语句在RC隔离级别中也能正确地并发更新账户。但并不是所有的问题都能简单到能用原子操作来解决的，让我们来看另一个例子。

丢失更新-P4-例2

让我们来看一个更微妙的例子：UPDATE与DELETE之间的冲突。

假设业务上每人最多有两个账户，用户最多能选择一个账号作为有效账号，管理员会定期删除无效账号。

账户表有一个字段valid表示该账户是否有效，定义如下所示：

CREATE TABLE account(
    id 		TEXT PRIMARY KEY,
    valid   BOOLEAN
);
INSERT INTO account VALUES('a', TRUE), ('b', FALSE);

现在考虑这样一种情况，用户要切换自己的有效账号，与此同时管理员要清理无效账号。

从顺序执行的角度来看，无论是用户先切换还是管理员先清理，最后结果的共同点是：总会有一个账号被删掉。

START TRANSACTION ISOLATION LEVEL READ COMMITTED;  -- T1, 用户更换有效账户
START TRANSACTION ISOLATION LEVEL READ COMMITTED;  -- T2, 管理员删除账户

UPDATE account SET valid = NOT valid; -- T1, 原子操作，将有效账户无效账户状态反转
DELETE FROM account WHERE NOT valid;  -- T2, 管理员删除无效账户。

COMMIT; -- T1, 提交，T1提交后解除对T2的阻塞
-- T2 DELETE执行完毕，返回DELETE 0

COMMIT; -- T2, T2能正常提交，但检查的话会发现自己没有删掉任何记录。
-- 无论T2选择提交还是回滚，最后的结果都是(a,f),(b,t)

从下图中可以看到，事务2的DELETE原本锁定了行(b,f)准备删除，但因为事务1的并发更新而阻塞。当T1提交解除T2的阻塞时，事务2看见了事务1的提交结果：自己锁定的那一行已经不满足删除条件了，因此只好放弃删除。

p4-2

相应的，改用RR隔离等级，至少给了T2知道错误的机会，在合适的时机重试就可以达到序列执行的效果。

START TRANSACTION ISOLATION LEVEL REPEATABLE READ;  -- T1, 用户更换有效账户
START TRANSACTION ISOLATION LEVEL REPEATABLE READ;  -- T2, 管理员删除账户

UPDATE account SET valid = NOT valid; -- T1, 原子操作，将有效账户无效账户状态反转
DELETE FROM account WHERE NOT valid;  -- T2, 管理员删除无效账户。

COMMIT; -- T1, 提交，T1提交后解除对T2的阻塞
-- T2 DELETE报错：ERROR:  could not serialize access due to concurrent update
ROLLBACK; -- T2, T2只能回滚

SI隔离级别小结

上面提到的异常，包括P2，P3，A5A，P4，都会在RC中出现，但却不会在SI中出现。特别需要注意的是，P3幻读问题会在RR中出现，却不会在SI中出现。从ANSI标准的意义上，SI可以算是可串行化了。SI解决的问题一言以蔽之，就是提供了真正的事务级别的快照。因而各种读-写异常（P2，P3，A5A）都不会再出现了。而且，SI还可以解决**丢失更新（P4）**的问题（MySQL的RR解决不了）。

丢失更新是一种非常常见的问题，因此也有不少应对的方法。典型的方式有三种：原子操作，显式锁定，冲突检测。原子操作通常是最好的解决方案，前提是你的逻辑可以用原子操作来表达。如果数据库的内置原子操作没有提供必要的功能，防止丢失更新的另一个选择是让应用显式地锁定将要更新的对象。然后应用程序可以执行读取-修改-写入序列，如果任何其他事务尝试同时读取同一个对象，则强制等待，直到第一个读取-修改-写入序列完成。（例如MySQL和PostgreSQL的SELECT FOR UPDATE子句）

另一种应对丢失更新的方法是自动冲突检测。如果事务管理器检测到丢失更新，则中止事务并强制它们重试其读取-修改-写入序列。这种方法的一个优点是，数据库可以结合快照隔离高效地执行此检查。事实上，PostgreSQL的可重复读，Oracle的可串行化和SQL Server的快照隔离级别，都会自动检测到丢失更新，并中止惹麻烦的事务。但是，MySQL/InnoDB的可重复读并不会检测丢失更新。一些专家认为，数据库必须能防止丢失更新才称得上是提供了快照隔离，所以在这个定义下，MySQL下没有提供快照隔离。

但正所谓成也快照败也快照，每个事务都能看到一致的快照，却带来了一些额外的问题。在SI等级中，一种称为写偏差（A5B）的问题仍然可能会发生：例如两个事务基于过时的快照更新了对方读取的数据，提交后才发现违反了约束。丢失更新其实是写偏差的一种特例：两个写入事务竞争写入同一条记录。竞争写入同一条数据能够被数据库的丢失更新检测机制发现，但如果两个事务基于各自的写入了不同的数据项，又怎么办呢？

写偏差 A5B

考虑一个运维值班的例子：互联网公司通常会要求几位运维同时值班，但底线是至少有一位运维在值班。运维可以翘班，只要至少有一个同事在值班就行：

CREATE TABLE duty (
  name   TEXT PRIMARY KEY,
  oncall BOOLEAN
);

-- Alice和Bob都在值班
INSERT INTO duty VALUES ('Alice', TRUE), ('Bob', True);

假如应用逻辑约束是：不允许无人值班。即：SELECT count(*) FROM duty WHERE oncall值必须大于0。现在假设A和B两位运维正在值班，两人都感觉不舒服决定请假。不幸的是两人同时按下了翘班按钮。则下列执行时序会导致异常的结果：

START TRANSACTION ISOLATION LEVEL REPEATABLE READ;  -- T1, Alice
START TRANSACTION ISOLATION LEVEL REPEATABLE READ;  -- T2, Bob

SELECT count(*) FROM duty WHERE oncall; -- T1, 查询当前值班人数, 2
SELECT count(*) FROM duty WHERE oncall; -- T2, 查询当前值班人数, 2

UPDATE duty SET oncall = FALSE WHERE name = 'Alice'; -- T1, 认为其他人在值班，Alice翘班
UPDATE duty SET oncall = FALSE WHERE name = 'Bob';   -- T2, 也认为其他人在值班，Bob翘班

COMMIT; -- T1
COMMIT; -- T2

SELECT count(*) FROM duty; -- 观察者, 结果为0, 没有人在值班了！

两个事务看到了同一个一致性快照，首先检查翘班条件，发现有两名运维在值班，那么自己翘班是ok的，于是更新自己的值班状态并提交。两个事务都提交之后，没有运维在值班了，违背了应用定义的一致性。

但如果两个事务并不是**同时（Concurrently）**执行的，而是分了先后次序，那么后一个事务在执行检查时就会发现不满足翘班条件而终止。因此，事务之间的并发导致了异常现象。

对事务而言，明明在执行翘班操作之前看到值班人数为2，执行翘班操作之后看到值班人数为1，但为啥提交之后看到的就是0了呢？这就好像看见幻象一样，但这与SQL92标准定义的幻读并不一样，标准定义的幻读是因为不可重复读的屁股没擦干净，读到了不该读的东西（对于谓词查询不可重复读取），而这里则是因为快照的存在，事务无法意识到自己读取的记录已经被改变。

问题的关键在于不同读写事务之间的读写依赖。如果某个事务读取了一些数据作为行动的前提，那么如果当该事务执行后续写入操作时，这些被读取的行已经被其他事务修改，这就意味着事务依赖的前提可能已经改变。

写偏差的形式化表示：

A5B: r1[x]...r2[y]...w1[y]...w2[x]...(c1 and c2 occur)

此类问题的共性

事务基于一个前提采取行动（事务开始时候的事实，例如：“目前有两名运维正在值班”）。之后当事务要提交时，原始数据可能已经改变——前提可能不再成立。

一个SELECT查询找出符合条件的行，并检查是否满足一些约束（至少有两个运维在值班）。
根据第一个查询的结果，应用代码决定是否继续。（可能会继续操作，也可能中止并报错）
如果应用决定继续操作，就执行写入（插入、更新或删除），并提交事务。

**这个写入的效果改变了步骤2 中的先决条件。**换句话说，如果在提交写入后，重复执行一次步骤1 的SELECT查询，将会得到不同的结果。因为写入改变符合搜索条件的行集（只有一个运维在值班）。

在SI中，每个事务都拥有自己的一致性快照。但SI是不提供**线性一致性（强一致性）**保证的。事务看到的快照副本可能因为其他事务的写入而变得陈旧，但事务中的写入无法意识到这一点。

与丢失更新的联系

作为一个特例，如果不同读写事务是对同一数据对象进行写入，这就成了丢失更新问题。通常会在RC中出现，在RR/SI隔离级别中避免。对于相同对象的并发写入可以被数据库检测出来，但如果是向不同数据对象写入，违背应用逻辑定义的约束，那RR/SI隔离等级下的数据库就无能为力了。

解决方案

有很多种方案能应对这些问题，可串行化当然是ok的，但也存在一些其他手段，例如锁

显式锁定

START TRANSACTION ISOLATION LEVEL REPEATABLE READ;  -- T1, 用户更换有效账户
START TRANSACTION ISOLATION LEVEL REPEATABLE READ;  -- T2, 管理员删除账户

SELECT count(*) FROM duty WHERE oncall FOR UPDATE; -- T1, 查询当前值班人数, 2
SELECT count(*) FROM duty WHERE oncall FOR UPDATE; -- T2, 查询当前值班人数, 2

WITH candidate AS (SELECT name FROM duty WHERE oncall FOR UPDATE)
SELECT count(*) FROM candidate; -- T1

WITH candidate AS (SELECT name FROM duty WHERE oncall FOR UPDATE)
SELECT count(*) FROM candidate; -- T2, 被T1阻塞

UPDATE duty SET oncall = FALSE WHERE name = 'Alice'; -- T1, 执行更新
COMMIT; -- T1, 解除T2的阻塞

-- T2报错：ERROR:  could not serialize access due to concurrent update
ROLLBACK; -- T2 只能回滚

使用SELECT FOR UPDATE语句，可以显式锁定待更新的行，这样，当后续事务想要获取相同的锁时就会被阻塞。这种方法在MySQL中称为悲观锁。这种方法本质上属于一种物化冲突，将写偏差的问题转换成了丢失更新的问题，因此允许在RR级别解决原本SR级别才能解决的问题。

在最极端的情况下（比如表没有唯一索引），显式锁定可能蜕化为表锁。无论如何，这种方式都有相对严重的性能问题，而且可能更频繁地导致死锁。因此也存一些基于谓词锁和索引范围锁的优化。

显式约束

如果应用逻辑定义的约束可以使用数据库约束表达，那是最方便的。因为事务会在提交时（或语句执行时）检查约束，违背了约束的事务会被中止。不幸的是，很多应用约束都难以表述为数据库约束，或者难以承受这种数据库约束表示的性能负担。

可串行化

使用可串行化隔离等级可以避免这一问题，这也是可串行化的定义：避免一切序列化异常。这可能是最简单的方法了，只需要使用SERIALIZABLE的事务隔离等级就可以了。

START TRANSACTION ISOLATION LEVEL SERIALIZABLE;  -- T1, Alice
START TRANSACTION ISOLATION LEVEL SERIALIZABLE;  -- T2, Bob

SELECT count(*) FROM duty WHERE oncall; -- T1, 查询当前值班人数, 2
SELECT count(*) FROM duty WHERE oncall; -- T2, 查询当前值班人数, 2

UPDATE duty SET oncall = FALSE WHERE name = 'Alice'; -- T1, 认为其他人在值班，Alice翘班
UPDATE duty SET oncall = FALSE WHERE name = 'Bob';   -- T2, 也认为其他人在值班，Bob翘班

COMMIT; -- T1
COMMIT; -- T2, 报错中止
-- ERROR:  could not serialize access due to read/write dependencies among transactions
-- DETAIL:  Reason code: Canceled on identification as a pivot, during commit attempt.
-- HINT:  The transaction might succeed if retried.

在事务2提交的时候，会发现自己读取的行已经被T1改变了，因此中止了事务。稍后重试很可能就不会有问题了。

PostgreSQL使用SSI实现可串行化隔离等级，这是一种乐观并发控制机制：如果有足够的备用容量，并且事务之间的争用不是太高，乐观并发控制技术往往表现比悲观的要好不少。

数据库约束，物化冲突在某些场景下是很方便的。如果应用约束能用数据库约束表示，那么事务在写入或提交时就会意识到冲突并中止冲突事务。但并不是所有的问题都能用这种方式解决的，可串行化的隔离等级是一种更为通用的方案。

0x06 并发控制技术

本文简要介绍了并发异常，这也是事务ACID中的“隔离性”所要解决的问题。本文简单讲述了ANSI SQL92标准定义的隔离等级以及其缺陷，并简单介绍了现代模型中的隔离等级（简化）。最后详细介绍了区分隔离等级的几种异常现象。当然，这篇文章只讲异常问题，不讲解决方案与实现原理，关于这些隔离等级背后的实现原理，将留到下一篇文章来陈述。但这里可以大概提一下：

从宽泛的意义来说，有两大类并发控制技术：多版本并发控制（MVCC），严格两阶段锁定（S2PL），每种技术都有多种变体。

在MVCC中，每个写操作都会创建数据项的一个新版本，同时保留旧版本。当事务读取数据对象时，系统会选择其中的一个版本，来确保各个事务间相互隔离。 MVCC的主要优势在于“读不会阻塞写，而写也不会阻塞读”。相反，基于S2PL的系统在写操作发生时必须阻塞读操作，因为因为写入者获取了对象的排他锁。

PostgreSQL、SQL Server、Oracle使用一种MVCC的变体，称为快照隔离（Snapshot Isolation，SI）。为了实现SI，一些RDBMS（例如Oracle）使用回滚段。当写入新的数据对象时，旧版本的对象先被写入回滚段，随后用新对象覆写至数据区域。 PostgreSQL使用更简单的方法：一个新数据对象被直接插入到相关的表页中。读取对象时，PostgreSQL通过可见性检查规则，为每个事物选择合适的对象版本作为响应。

但数据库技术发展至今，这两种技术已经不是那样泾渭分明，进入了一个你中有我我中有你的状态：例如在PostgreSQL中，DML操作使用SI/SSI，而DDL操作仍然会使用2PL。但具体的细节，就留到下一篇吧。

Reference

【1】Designing Data-Intensive Application，ch7

【2】Highly Available Transactions: Virtues and Limitations

【3】A Critique of ANSI SQL Isolation Levels

【4】Granularity of Locks and Degrees of Consistency in a Shared Data Base

【5】Hermitage: Testing the ‘I’ in ACID

KNN极致优化：从RDS到PostGIS

KNN问题极致优化，从传统关系型设计到PostGIS

著： 冯若航（@Vonng） | 2018-06-06

概述

灵活应用数据库的功能，可以轻松实现三万倍的性能提升。

Level	方法	性能/耗时(ms)	可维护性/可靠性	备注
1	暴力扫表	30,000	-	形式简单
2	经纬索引	35	复杂度/魔数问题	额外复杂度
3	联合索引	10	复杂度/魔数问题	额外复杂度
4	GIST	4	最简表达，完全精确	形式简单，距离更精确，PostgreSQL限定
5	`btree_gist`联合索引	1	最简表达，完全精确	形式简单，距离更精确，PostgreSQL限定

场景

互联网中的很多业务都涉及到地理相关的功能需求，最为普遍的需求莫过于最近邻查询了。

例如：

为用户推荐附近的POI（餐厅、加油站、公交站）
为用户推荐附近的用户（聊天匹配）
找到距离用户所处的地址（地理逆编码）
找到用户所处的商圈、省、市、区、县 (以点找面)

这些问题实质上都属于最近邻搜索或其变体。

有一些功能，它看上去和最近邻搜索无关，实际上剥了皮，也是最近邻搜索，典型的例如地理逆编码：

打车选择上车地点的时，点外卖选择送达位置时，都会将用户当前的经纬度坐标转换为文本地理位置，诸如：“某某小区几号楼”。实际上这也是最近邻搜索的问题：找到距离用户当前位置最近的一个坐标点。

最近邻（knn，k nearest neighiboor），顾名思义，就是找出距离某个中心点最近的K个对象。其问题满足这样一种形式：

找出满足某一条件的最近的K个对象（及其属性）。

最近邻搜索是如此常用的功能，优化的效益非常显著。

下面我们从一个具体问题出发，讲述这一功能实现方式的演化——如何实现超过三万倍的性能提升。

问题

我们选择推荐最近的餐厅，作为此类问题的代表。

问题很简单：给定包含中国所有POI点的表pois，及一个经纬度坐标点。在足够快的时间内找出距离该坐标点最近的10家餐馆。并返回这十家餐馆的名称和距离。

细节说明：

pois表包括一亿条记录，其中类型为餐馆的POI约占一千万。
给定的示例中心店：北京师范大学，116.3660 E, 39.9615 N。
足够快意味着在1毫秒内完成
距离意味着，以米计算的地球表面距离

pois表模式定义：

CREATE TABLE pois (
  id        CHAR(10) PRIMARY KEY,
  name      VARCHAR(100),
  position  GEOMETRY, -- PostGIS ST_Point
  longitude FLOAT,    -- Float64
  latitude  FLOAT,    -- Float64
  category  INTEGER   -- type of POI
);

餐馆的特征是WHERE category BETWEEN 50000 AND 51000

距离如何定义？

欲解此题，需明定义。距离的定义并没有看上去那样简单。

例如，对于导航软件而言，距离可能意味着路径长度而非直线距离。

在二维平面坐标系中，通常距离指的是欧氏距离：$d=\sqrt{(x_2-x_1)^2+(y_2-y_1)^2}$

但在GIS中，通常使用的坐标系是球面坐标系，即通过经纬度来标识一个点。

在球面上，两点之间的距离等于所在球面大圆上的弧长，也就是其球面角 x 半径。

这就引入了一个问题，每一纬度对应的距离是基本恒定的，差不多都是111公里。

然而，每一经度对应的距离，随着纬度不同而变化，在赤道上和一纬度差不多，也是111公里，然而随着纬度升高，到了北纬40°时，一经度对应的弧长只有85公里了，而到了北极点，一经度对应的弧长距离为0。

事实上，还会有其他更棘手的问题。例如，地球实际上是一个椭球体，而非正球体。

地球非球，乃不规则椭球。在最开始的时候，为了省事，我们可以设其为球计算距离。

CREATE OR REPLACE FUNCTION sphere_distance(lon_a FLOAT, lat_a FLOAT, lon_b FLOAT, lat_b FLOAT)
  RETURNS FLOAT AS $$
SELECT asin(
           sqrt(
               sin(0.5 * radians(lat_b - lat_a)) ^ 2 +
               sin(0.5 * radians(lon_b - lon_a)) ^ 2 * cos(radians(lat_a)) * cos(radians(lat_b))
           )
       ) * 127561999.961088 AS distance;
$$
LANGUAGE SQL IMMUTABLE COST 100;

将经纬度坐标当成平面坐标使用并不是不可以，但对于需要精准排序的场景，这样的近似可能会产生很大的问题：

每一经度对应的距离，随着纬度不同而变化，在赤道上一经度和一纬度代表的距离差不多都是111公里，然而随着纬度升高，到了北纬40°时，一经度对应的弧长只有85公里了，而到了极点，一经度对应的弧长距离为0。

因此，平面坐标系上的圆，在球面坐标系上可能只是一个瘦长的椭圆。计算距离时，纬度与经度方向上的距离权重不同会导致严重的正确性问题：一个正北100米处的商店可能比正东70m处的商店距离排序更靠前。对于高纬度地区，这一类问题会变得非常严重。

因此，暴力扫表之后，通常需要使用精确的距离计算公式再次计算并排序。

注意，这里的距离，量纲单位并不是米，而是°的平方，考虑到1经度和1纬度对应的实际距离在不同的地方存在巨大差异，这一结果并没有精确的实际意义。

经纬度是球面坐标系，而不是二维平面坐标系中的坐标。然而对于快速粗略圈选，这种方式是可以接受的。

对于需要精确排序的场景，必须使用地球表面球面距离的计算公式，而不是简单地求欧氏距离。

足够快又是多快？

天下武功，唯快不破，互联网强调的就是一个快，跑的也快，写的也快。

足够快又是多快呢？一毫秒，足够快了。这也是我们的优化目标

好了，开始进入干货环节。在PostGIS展现真正的实力之前，让我们来先看一看传统的关系型数据库，对解决这一问题，能走到多远。

0x02 方案

让我们从传统关系型数据库开始

LEVEL-1 暴力扫表

使用传统关系型数据库，此题有何解法？

暴力算法写起来是非常简单的，我们来看一下。

从POIS表中，首先找出所有的餐馆，拿出餐馆的名字，算出餐馆到我们这儿的距离，然后呢？再按距离排序，取距离最短的，也就是最近的10条记录。

新手拍拍脑袋，也可以很快写出这样Naive的SQL：

SELECT
  id,
  name,
  sphere_distance(longitude, latitude, 
                  116.3660 , 39.9615 ) AS d
FROM pois
WHERE category BETWEEN 50000 AND 51000
ORDER BY d
LIMIT 10;

为了简化问题，让我们暂时忽略经纬度其实是球面坐标，地球又是个椭球体的事实。

在这一前提下，这个SQL确实能正确完成工作。不过，谁要敢在生产环境这么用，DBA肯定得打死他。

让我们先考察其执行计划：

题外话：SQL内联

SQL内联有助于正确使用索引。

在真实环境执行，缓存充分预热，实际耗时30秒；开启PostgreSQL并行查询（2 worker）后实际执行时间16秒。

用时30秒，实际执行时间17秒。

用户对于响应时间是很敏感的，响应时间一上去，用户满意度立马就会掉下来。打王者荣耀的时候，100毫秒的延迟都已经很让人抓狂了。如果是一个实时性

对于几千条记录的表也许可以凑合工作，但对于1亿量级的表，暴力扫表不可取。

用户无法接受十几秒的等待时间，更罔论这样的设计能有任何扩展性可言。

存在的问题

开销离谱

这个查询每次都要计算目标点和所有记录点之间的距离，然后再按距离排序取TOP。

对于几千条记录的表也许可以凑合工作，但对于1亿量级的表，暴力扫表不可取。用户无法接受十几秒的等待时间，更罔论这样的设计能有任何扩展性可言。

正确性堪忧

将经纬度坐标当成平面坐标使用并不是不可以，但对于需要精准排序的场景，这样的近似可能会产生很大的问题：

因此，暴力扫表之后，通常需要使用精确的距离计算公式再次计算并排序。

题外话：错误的索引效果适得其反

有同学会说，这里POI类型字段，category出现在了查询的where条件中，可以通过索引来提高性能

这次他不直接扫表了，它先去扫描category上的索引，把属于餐厅的记录都过滤出来。

然后再按照索引，一个页面接一个页面地扫描。

结果顺序IO变成了随机IO。

那么索引的正确使用方式又是怎么样的呢？

LEVEL-2 经纬索引

索引是关系型数据库的吃饭家伙，既然顺序扫表不可取，我们自然会想到利用索引来加速查询。

朴素的思路是这样的，通过索引筛选出目标点周围一定范围内的候选点，再进一步计算距离并排序。

索引是关系型数据库的吃饭家伙，既然顺序扫表不可取，我们自然会想到利用索引来加速查询。

使用经纬度上的索引是基于这样一种思路：

北师在帝都繁华之地宇宙中心，如果我们用一个边长一公里的正方形（直径一公里的圆）

去地图上画个圈，那么别说十家餐厅了，一百家都有可能。

反过来说呢，既然最近的10家餐厅一定落在这么大的一个圆里，

这个表里的POI点包括了全中国的POI点，

筛选出目标点周围一定范围内的候选点，再进一步计算距离并排序。

CREATE INDEX ON pois1 USING btree(longitude);
CREATE INDEX ON pois1 USING btree(latitude);

同时，为了解决正确性的问题，假设我们已经有了一个从经纬度计算球面距离的SQL函数sphere_distance

CREATE FUNCTION sphere_distance(lon_a FLOAT, lat_a FLOAT, lon_b FLOAT, lat_b FLOAT) RETURNS FLOAT
IMMUTABLE LANGUAGE SQL COST 100 AS $$
SELECT asin(
           sqrt(
               sin(0.5 * radians(lat_b - lat_a)) ^ 2 +
               sin(0.5 * radians(lon_b - lon_a)) ^ 2 * cos(radians(lat_a)) *
               cos(radians(lat_b))
           )
       ) * 127561999.961088 AS distance;
$$;

$$ \Delta\sigma=\arccos\bigl(\sin\phi_1\cdot\sin\phi_2+\cos\phi_1\cdot\cos\phi_2\cdot\cos(\Delta\lambda)\bigr). $$

于是，如果使用以目标点为中心的边长为1公里的正方形来做初筛，这个查询可以写作：

SELECT 
  id, name, 
  sphere_distance(longitude, latitude, 116.365798, 39.966956) as d
FROM pois1
WHERE
  longitude BETWEEN 116.365798 - 0.5 / 85 AND 116.365798 + 0.5 / 85 AND
  latitude BETWEEN 39.966956 - 0.5 / 111 AND 39.966956 + 0.5 / 111  AND
  category = 60000
ORDER BY 3 LIMIT 10;

预热后，实际执行平均耗时35毫秒，相比暴力扫表有了近千倍的性能提高，一个巨大的进步。

对于比较简单粗糙的产品，这种方法已经达到了‘可用’的级别。但这一方法仍然存在许多问题。

存在的问题

这种方法最大的问题在于额外复杂度。它使用了一个（多个）魔数，来确定候选点的大致范围。

而这个魔数的选取，是有赖我们的先验知识的。我们清楚地知道，以繁华的宇宙中心五道口的商铺密度，一公里见方内，商铺个数绝对超过10个了。但对于极端的场景（实际可能很常见），比如在塔克拉玛干大沙漠或者羌塘无人区，最近的商铺，逻辑上是必定存在的，不过其距离可能超过几百公里。

这种方法的性能表现对魔数的选取极其敏感：距离选择的太大，性能会急剧恶化，距离选择的太小，对于乡下偏僻的地方又可能无法返回结果。让程序员头大的事情又多了一个。

用时35毫秒

千倍提升，不错哦，但不能高兴的太早

这么多奇怪的常数又是几个意思？

一千倍的性能提升，让我们来看一下查询执行计划，看看它是怎么做到的。

首先呢，经度上，走了一个索引扫描，生成了一个位图。

然后呢，纬度上，也走了一个索引扫描，又生成了一个位图。

接下来，两个位图做了一个位运算，生成了一个新位图，筛选出了满足经纬度条件的记录。

然后，才去扫描这些满足条件的候选点，计算距离，并排序。

我们这个边界值选的比较巧，所以实际参与距离计算和排序的记录，可能只有三十多条。

比起先前一千多万次的距离计算与排序，显然是要高明的多了。

题外话：超参数与额外复杂度

因为这个边界魔数凑的很好，所以性能比较理想。

这种方法最大的问题在于额外复杂度。它使用了一个（多个）魔数，来确定候选点的大致范围。

让我们先忽略这恼人的问题，看看传统关系型数据库还能不能再压榨压榨。

Bad Case

因为这个边界魔数凑的很好，所以性能比较理想。

这种方法最大的问题在于额外复杂度。它使用了一个（多个）魔数，来确定候选点的大致范围。

让我们先忽略这恼人的问题，看看传统关系型数据库还能不能再压榨压榨。

半径大了性能差	半径小了圈不着

繁荣的五道口，一公里圈10家小意思。	300公里外才有一家，新疆人民哭晕在厕所

LEVEL-3 联合索引与聚簇

抛开魔数带来的烦恼，我们来研究传统关系型数据库能在解决这个问题上走得有多远。

通过多列索引替换每一列上独自的索引，并将表按该索引聚簇。

仍然是一模一样的查询语句

从30毫秒提升到10毫秒，三倍的性能提升

对于传统关系型数据库，这差不多就是极限了

有没有优雅、正确、快速的解决方案呢？

mage-20180321221928

CREATE INDEX ON pois4 USING btree(longitude, latitude, category);
CLUSTER pois4 USING pois4_longitude_latitude_category_idx;

相应的查询保持不变

SELECT id, name,
	sphere_distance(longitude, latitude, 116.365798, 39.966956) as d FROM pois4
WHERE
  longitude BETWEEN 116.365798 - 0.5 / 85  AND 116.365798 + 0.5 / 85  AND
  latitude  BETWEEN  39.966956 - 0.5 / 111 AND 39.966956  + 0.5 / 111 AND
  category = 60000
ORDER BY sphere_distance(longitude, latitude, 116.365798, 39.966956)
LIMIT 10;

联合索引查询的执行计划，实际执行时间可以压缩至7毫秒。

mage-20180321221945

这差不多就是传统关系数据模型的极限了，对于大部分业务，这都是一个可以接受水平了。

因为这个边界魔数凑的很好，所以性能比较理想。

扩展变体：GeoHash

GeoHash是此类方式的变体，通过将二维经纬度编码为一维字符串，可以使用传统的字符串前缀匹配操作来对地理位置进行过滤。然而固定的粒度使得其灵活度有显著下降，采用联合索引还是特殊编码的冗余字段需要针对具体场景进行分析。

仍然是一模一样的查询语句

从30毫秒提升到10毫秒，三倍的性能提升

对于传统关系型数据库，这差不多就是极限了

有没有优雅、正确、快速的解决方案呢？

LEVEL-4 GIST

有没有一种办法，能够优雅，高效，简洁的完成这项工作呢？

PostGIS提出了非常优秀的解决方案，改用Geometry类型，并创建GIST索引。

CREATE TABLE pois5(
  id       CHAR(10) PRIMARY KEY,
  name     VARCHAR(100),
  position GEOGRAPHY(Point), -- PostGIS ST_Point
  category INTEGER   -- type of POI
);

CREATE INDEX ON pois5 USING GIST(position);

SELECT id, name FROM pois6 WHERE category = 60000
ORDER BY position <-> ST_GeogFromText('SRID=4326;POINT(116.365798 39.961576)') LIMIT 10;

R树

R树的核心思想是，聚合距离相近的节点，并在树结构的上一层，将其表示为这些节点的最小外接矩形，这个最小外接矩形就成为上一层的一个节点。因为所有节点都在它们的最小外接矩形中，所以跟某个矩形不相交的查询就一定跟这个矩形中的所有节点都不相交。

mage-20180321220143

实际查询中，该查询能在1.6毫秒完成，这是相当惊人的一个结果了。但要注意，这里position的类型是GEOMETRY，意味着它使用的是二维平面坐标，正确的计算距离需要使用Geography类型。

SELECT
  id,
  name,
  position <-> 
  ST_Point(116.3660, 39.9615)::GEOGRAPHY AS d
FROM pois5
WHERE category BETWEEN 50000 AND 51000
ORDER BY d
LIMIT 10;

因为球面距离的计算开销比平面距离要大很多，使用Geography替换Geometry产开销，约4.5ms。

一倍的性能损失相当可观，因此日常应用中需要仔细权衡精确性与性能之间的关系。

通常拓扑类的查询、粗略的圈人都适合用Geometry类型，而精确的计算与判断则必须使用Geography类型。这里，按照距离排序需要精确的距离，因此使用Geography。

Geometry: 1.6 ms	Geography: 3.4 ms

现在，我们来看看PostGIS交出的答卷。

PostGIS，使用了不一样的数据类型、索引、与查询方法。

首先，这里数据类型不再是两个浮点数，而变成一个Geography字段。里面存就是一对经纬度坐标。

然后，我们使用的索引，也不再是常见的Btree索引，而是GIST索引。

Generalized Search Tree. 通用搜索树，平衡树结构。对于空间几何类型而言，实现通常使用的是R树。

题外话：Geometry还是Geography？

因为球面距离的计算开销比平面距离要大很多，使用Geography替换Geometry产开销

拓扑关系，粗略估计使用Geometry，精确计算使用Geography

计算开销约为一倍，需要仔细权衡正确性/精确性与性能之间的关系。

现在，我们来看看PostGIS交出的答卷。

PostGIS，使用了不一样的数据类型、索引、与查询方法。

首先，这里数据类型不再是两个浮点数，而变成一个Geography字段。里面存就是一对经纬度坐标。

然后，我们使用的索引，也不再是常见的Btree索引，而是GIST索引。

Generalized Search Tree. 通用搜索树，平衡树结构。对于空间几何类型而言，实现通常使用的是R树。

LEVEL-5 btree_gist

还能更进一步否？

观察Leve-4中的执行计划，我们发现category上的条件并没有用到索引。

可不可以像Level-3中的优化方式一样，创建一个 position 与 category 的联合索引呢？

不幸的是，B树与R树是两种完全不同的数据结构，甚至连使用方式都不一样

于是我们有这样一个想法，能不能把category当成 position的第三维坐标，让R树直接在三维空间里面进行索引呢？

这个思路是正确的，但是完全不需要这么麻烦

GIST索引的一个问题在于，它的工作原理与B树不同，无法在不支持GIST索引方法的数据类型上创建GIST索引。

通常，几何类型，范围（range）类型支持GIST索引，但字符串，数值类型等都不支持GIST。这就导致了无法创建形如GIST(position, category)的多列索引。

PostgreSQL内置的btree_gist扩展解决了这一问题。

PostgreSQL内置的扩展 btree_gist，允许创建常规类型与几何类型的联合索引。

CREATE EXTENSION btree_gist;

CREATE INDEX ON pois6 USING GIST(position, category);

CLUSTER VERBOSE pois6 USING idx_pois6_position_category_gist;

同样的查询，可以简写为：

SELECT id, name, position <-> ST_Point(lon, lat) :: GEOGRAPHY AS distance
FROM pois6 WHERE category = 60000 ORDER BY 3 LIMIT 10;

Geometry: 0.85ms / Geography: 1.2ms

CREATE OR REPLACE FUNCTION get_random_nearby_store() RETURNS TEXT
AS $$
DECLARE
  lon FLOAT := 110 + (random() - 0.5) * 10;
  lat FLOAT := 30 + (random() - 0.5) * 10;
BEGIN
  RETURN (
    SELECT jsonb_pretty(jsonb_build_object('list', a.list, 'lon', lon, 'lat', lat)) :: TEXT
    FROM (
           SELECT json_agg(row_to_json(top10)) AS list
           FROM (
             SELECT id, name, position <-> ST_Point(lon, lat) :: GEOGRAPHY AS distance
             FROM pois6 WHERE category = 60000 ORDER BY 3 LIMIT 10 ) top10
         ) a);
END;
$$ LANGUAGE PlPgSQL;

import http, http.server, random, psycopg2

class GetHandler(http.server.BaseHTTPRequestHandler):
    conn = psycopg2.connect("postgres://localhost:5432/geo")
    def do_GET(self):
        self.send_response(http.HTTPStatus.OK)
        self.send_header('Content-type','application/json')
        with GetHandler.conn.cursor() as cursor:
            cursor.execute('SELECT get_random_nearby_store() as res;')
            res = cursor.fetchone()[0]
            self.wfile.write(res.encode('utf-8'))
        return

with http.server.HTTPServer(("localhost", 3001), GetHandler) as httpd: httpd.serve_forever()

案例小结

Level	方法	性能/耗时(ms)	可维护性/可靠性	备注
1	暴力扫表	30,000	-	形式简单
2	经纬索引	35	复杂度/魔数问题	额外复杂度
3	联合索引	10	复杂度/魔数问题	额外复杂度
4	GIST	4	最简表达，完全精确	形式简单，距离更精确，PostgreSQL限定
5	`btree_gist`联合索引	1	最简表达，完全精确	形式简单，距离更精确，PostgreSQL限定

那么好的，经过这么漫长的旅途，通过PostGIS与PostgreSQL，将原本需要3万毫秒的查询加速至1毫秒，三万倍的提升。相比传统关系型数据库，除了超过十倍以上的性能提升，还有很多优点：

SQL的形式非常简单，就是暴力扫表的SQL，不需要奇奇怪怪的额外复杂度。而且计算距离使用的是更精确的WGS84椭球球面距离。

那么从这个例子中我们可以得出什么结论呢？ PostGIS的性能表现是非常优秀的，那么它在实际生产环境里的表现又如何呢？

我们把这里的position，从餐厅的位置换为用户的位置，把poi的种类范围，换成候选人的年龄范围。这就是探探匹配功能所面临的场景。

实际场景中的表现

性能很重要。天下武功，唯快不破。

目前数据库总共用了220台机器，业务QPS近10万。数据库TPS峰值的时候差不多接近250W。其中核心数据库是1主19从的配置。

我厂对于数据库的SLA是：99.99%的普通数据库请求需要在1毫秒内完成，而单个数据库节点的QPS峰值在3万上下。这两者之间其实有着紧密的联系，如果一个请求能在1毫秒内完成，那么对于单个线程而言，每秒钟就可以处理1000个请求。我们使用的数据库物理机CPU为24核48线程，不过超线程的机器CPU利用率在60%~70%左右。可以近似折算为30个可用核。那么，所有核能够承载的QPS量就是30*1000=30000。以极限水位80% CPU算，QPS上限在38k 左右，也与现实压测结果吻合。

整理自本人在2018象形中国北京PostGIS专场所做分享，转载请保留出处。

PostGIS高效解决行政区划归属查询

如何高效解决典型地理逆编码问题：根据用户的经纬度坐标，定位用户的行政区划。

著： 冯若航（@Vonng） | 2018-06-06

在应用开发中，很多时候我们需要解决这样一个问题：根据用户的经纬度坐标，定位用户的行政区划。

我们收集到的是诸如28°00'00"N 100°00'00.000"E这样的经纬度坐标，但实际感兴趣的是这个点所属的行政区划：（中华人民共和国，云南省，迪庆藏族自治州，香格里拉市）。这种将地理坐标映射到某条记录的操作就称为地理编码（GeoEncode）。高效实现地理编码是一个很有趣的问题。

本文介绍了该问题的解决与优化方案：能在确保正确性的前提下，能用几兆的空间，110μs的执行时间完成一次地理编码。

0x01 正确至上

正确性是第一位的。我们不希望出现用户明明身处A地，却被划分到B地的尴尬情况。然而一个尴尬的现实是，很多地理编码服务的实现粗糙到令人无法直视，Vornoi方法就是一个典型的例子。

假设我们有一系列的坐标点，那么这些坐标点之间两两连线的中垂线就对整个坐标平面做了一个Vornoi划分。每一个细胞的中心点就是细胞核，而元胞内的任意一点到该细胞核的距离是最近的（与其他细胞核相比）。

当我们没有行政区划的边界数据，但有行政区划中心点的数据时，这也是一种能凑合管用办法。找到距离用户最近的某级行政区域中心，然后认为用户就位于该行政区域中心。这个功能实现起来非常简单。

不过，这种方法对于边界情况的处理很差：

最近邻搜索—Vornoi方法

vornoi

现实总是与理想情况相距甚远。也许对于国内而言，这种错误影响也许并不大。但涉及到国际主权边界时，这种粗糙的实现很可能会给自己带来不必要的麻烦：

还有一种思路，和编程中的“查表法”类似，预先计算好所有经纬度到行政区划的映射，使用时只要用经纬度坐标查表就好了。当然无论经度还是维度，都是一个连续的标量，理论上精度必然是有限的。

GeoHash就是这样一种方案：它将经度与维度交叉编码为单一字符串，字符串越长精度越高，每一个字符串都对应一个经纬度围成的“矩形”，只要精度足够，理论上是可以这么做的。当然，这种方案难以做到真正意义上的正确，存储开销也极为浪费。好处是实现很简单。只要有数据，一个KV服务就可以轻松搞定。

geohash

相比之下，基于地理边界多边形的解决方案在保证绝对正确的前提下，能在一毫秒内完成这种地理编码功能，而且可能只需要几兆的空间。唯一的难点可能在于如何获取数据上。

0x02 数据为王

地理编码属于典型的数据密集型应用，数据的质量直接决定了最终服务的效果。要想真正做好服务，优质数据必不可少。好在行政区划与地理边界数据也不算什么保密信息，有一些地方提供了公开获取的方式：

民政部信息查询平台与高德地图两者都提供了精确到县级区划的地理边界数据：

高德地图行政区域查询API

高德的数据更新更及时，形式简单，边界精度较高（点数多），但不够权威，有不少错漏之处。
民政部全国行政区划信息查询平台

民政部平台数据相对更加权威，而且采用的是拓扑编码，严格避免了边界重叠的问题，使用无偏的WGS84坐标，但边界精度较低（点数目较少）。

geohash

除了地理围栏数据之外，另一份重要的数据是行政区划代码数据。国家统计局使用的12位城乡统计用行政区划代码编制还是很科学的，具有层次包含关系，尤其适合作为行政区划的唯一标示。但问题是稍显过时，最新的版本是2016年8月发布的，2018年7月后可能会发布一份更新的数据。

笔者整理了一份连接国际统计局行政区划与高德区划边界的数据：https://github.com/Vonng/adcode

民政部的数据可以直接在该网站中打开浏览器的调试工具，从接口返回数据中直接获取。

0x03 牛刀小试

假设我们已经有一张表了，全国行政区划与地理围栏表：adcode_fences

create table adcode_fences
(
  code         bigint,
  parent       bigint,
  name         varchar(64),
  level        varchar(16),
  rank         integer,
  adcode       integer,
  post_code    varchar(8),
  area_code    varchar(4),
  ur_code      varchar(4),
  municipality boolean,
  virtual      boolean,
  dummy        boolean,
  longitude    double precision,
  latitude     double precision,
  center       geometry,
  province     varchar(64),
  city         varchar(64),
  county       varchar(64),
  town         varchar(64),
  village      varchar(64),
  fence        geometry
);

geohash

索引

为了高效执行空间查询，首先需要在表示地理边界的fence列上创建GIST索引。

中国县级行政区划的记录数据并不多（约3000条），但使用索引仍然能带来几十倍的性能提升。因为这个优化太基础太Trivial了，就不单独拎出来说了。（一百多毫秒到几毫秒）

CREATE INDEX ON adcode_fences USING GIST(fence);

查询

PostGIS提供了ST_Contains与ST_Within两个函数，用于判断多边形与点之间的包含关系，例如以下SQL就会找出表中所有包含该点(116,40)的行政区划：

SELECT
  code,
  name
FROM adcode_fences
WHERE ST_Contains(fence, ST_Point(116, 40))
ORDER BY rank;

结果是：

100000000000	中华人民共和国
110000000000	北京市
110100000000	市辖区
110109000000	门头沟区

再比如(100,28)的坐标点：

SELECT json_object_agg(level,name) 
FROM adcode_fences WHERE ST_Contains(fence, ST_Point(100, 28));

{
  "country": "中华人民共和国",
  "city": "迪庆藏族自治州",
  "county": "香格里拉市",
  "province": "云南省"
}

相当不可思议，数据就位之后，借力于PostgreSQL与PostGIS，实现这一功能所需的代码少的惊人：一行SQL。

在笔者的笔记本上，该查询执行用时6毫秒。6ms的平均查询时间，换算为48核机器上的QPS差不多就是6400。在我们以前的生产环境代码中基本上就是这么做的，但因为还有其他国家的数据，以及单核主频没有我的机器高，因此一次查询的平均执行时间可能在12毫秒左右。

看上去几毫秒似乎已经很快了，但还是没有达到我们生产环境的性能要求（1毫秒）。对于真实世界的生产业务而言，性能很重要，十倍的性能提升意味着省十倍的机器。还能不能再给力点？实际上通过简单的优化就可以达到百倍的性能提升。

0x04 性能优化

针对数据特性优化

导致上述查询慢的一个重要原因是不必要的相交判断。行政区划是有层级关系的，如果一个用户位于县级行政区划中，那么他一定位于该县级区划所处的省级区划中。因此，知道了最低级的行政区划，其高级区划归属已经自然而然地确定了；那么与省界，国界做相交判断就是没有必要的。实际上这可能是效果最明显的优化，单是中国地理边界与点做相交判断可能就需要几毫秒。

区域切分

R树索引的原理，能为我们带来优化的启发。R树是基于**AABB（Axis Aligned Bounding Box）**的索引。因此越是饱满的凸多边形，索引的效果就越好。而对于拥有遥远飞地的行政区划，效果则可能恶化的很厉害。因此，将区域切分为均匀饱满的小块，能有效提高查询的性能。

最基本的优化，就是将所有的ST_MultiPolygon拆分为ST_Polygon，并指向同一个行政区划。更进一步，可以将长得比较畸形的行政区划切分为形状饱满的小块（典型的比如甘肃这种）。当然，这样的代价就是让所有行政区划与地理围栏从一对一变成了一对多的关系。需要拆出一张单独的表。

实际操作中，如果已经有了县级行政区划的数据，通常只要将带有飞地的MultiPolygon拆为单独的几个Polygon，就已经能有很好的表现了。而县一级的行政区划通常边界也比较饱满，进一步拆分效果相当有限。

精确度

正确性是第一位的，然而有的时候我们宁愿牺牲一些准确性，换来性能的大幅提升。例如高德与民政部的数据对比，显然民政部要粗糙的多，但对于糙猛快的互联网场景，低精度的数据反而可能是更合适的。

高德	民政部

高德的全国行政区划数据约100M左右，而民政部的数据约为10M（以原始拓扑数据表示则为4M）。但实际使用中效果差别不大，因此推荐使用民政部的数据。

主键设计

行政区划有内在的层次关系，国家包含省，省包含城市，城市包含区县，区县包含乡镇，乡镇包含村庄街道。我国的行政区划代码就很好的体现了这种层次关系，十二位的城乡区划代码包含了很丰富的信息：

第1～2位，为省级代码；
第3～4 位，为地级代码；
第5～6位，为县级代码；
第7～9位，为乡级代码；
第10～12位，为村级代码。

因此这种12位的行政区划代码是很适合作为行政区划表的主键的。此外，当需要国际化支持时，这套区划代码体系还可以通过在前面添加国家代码来扩展（相应地中国行政区划对应地就是高位国家代码为0的特殊情况）。

另一方面，地理围栏表与行政区划表由一对一变为多对一，那么地理围栏表就不再适合用行政区划代码作为主键了。可能自增列是一个更合适的选择。

规范化与反规范化

数据模型设计的一个重要权衡就是规范化与反规范化。将地理围栏表从行政区划表中拆出来是一种规范化，而反规范化也可以用于优化：既然行政区划存在层次关系，那么在子行政区划中保留所有的祖先行政区划信息（或仅仅是代码与名称）是很合理的反规范化操作。这样，通过区划代码主键一次查询就可以取出所有的层次信息。

回溯支持

有时候我们想回溯到历史上某个特定时刻，查询该时刻的行政区划状态。

举个例子，行政区划变更并不会影响该区划内现有公民的身份证号码，只会影响新出生公民的身份证号。因此有时候用公民身份证号前6位去查现在的行政区划表可能一无所获，需要回溯到该公民出生的历史时间才能查询到正确的结果。可以参考PostgreSQL MVCC的实现方式，为行政区划表添加一对PostgreSQL提供的tstzrange类型字段，标识行政区划记录版本的有效时间段，并在查询时指明时间点作为筛选条件。PostgreSQL可以支持在范围类型与空间类型上建立联合GIST索引，提供高效查询支持。

不过，时序数据获取难度是很大的。而且一般这个需求也并不常见。所以这里就不展开了。

0x05 设计实现

既然已经将地理编码的功能从区划代码表拆分出来，本题对adcode中的结构就不甚关注了。我们只需要知道凭借code字段能从该表中快速查出我们感兴趣的东西，比如一连串的行政区划层次，行政区划的人口，面积，等级，行政中心等等。

create table adcode
(
  code         bigint PRIMARY KEY ,
  parent       bigint references adcode(code),
  name         text,
  rank         integer,
  path         text[],
        
  …… <other attrs>
);

相比之下，fences表才是我们需要关注的对象，因为这是性能损耗的关键路径。

CREATE TABLE fences (
  id    BIGSERIAL PRIMARY KEY,
  fence geometry(POLYGON),
  code  BIGINT
);

CREATE INDEX ON fences USING GiST(fence);
CREATE INDEX ON fences USING Btree(code);

CLUSTER TABLE fences USING fences_fence_idx;

不使用行政区划代码code作为主键，给予了我们更多的灵活性与优化空间。任何时候需要修正地理编码的逻辑时，只修改fences中的数据即可。你甚至可以添加冗余字段与条件索引，将不同来源的数据，不同等级的行政区划，相互重叠的地理围栏放在同一张表中，灵活地执行自定义的编码逻辑。

说句题外话：如果您能确保自己的数据不会重叠，则可以考虑使用PostgreSQL提供的Exclude约束确保数据完整性：

CREATE TABLE fences (
  id    BIGSERIAL PRIMARY KEY,
  fence geometry(POLYGON),
  code  BIGINT,
  EXCLUDE USING gist(fence WITH &&) 
     -- no need to create gist index for fence anymore
);

性能测试

那么优化完之后的性能表现又如何？让我们随机生成一些坐标点，检验一下性能。

\set	x	random(75,125)
\set	y	random(20,50)
SELECT code FROM fences2 WHERE ST_Contains(fence,ST_Point(:x,:y));

在笔者的机器上，现在一次查询只要0.1ms了，单进程9k TPS，折算为48核机器约为350kTPS

$ pgbench adcode -T 5 -f run.sql

number of clients: 1
number of threads: 1
duration: 5 s
number of transactions actually processed: 45710
latency average = 0.109 ms
tps = 9135.632484 (including connections establishing)
tps = 9143.947723 (excluding connections establishing)

当然拿到code之后还是需要去行政区划表里查一次，但一次索引扫描的开销是很小的。

总的来说，与优化之前的实现相比，性能提升了60倍。落实在生产环境中，可能就意味着省了百来万的成本。

微信公众号原文

PgSQL Distinct On

使用Distinct On扩展字句快速找出分组内具有最大最小值的记录

著： 冯若航（@Vonng） | 2018-04-06

Distinct On是PostgreSQL提供的特有语法，可以高效解决一些典型查询问题，例如，快速找出分组内具有最大最小值的记录。

前言

找出分组内具有最大最小值的记录，这是一个非常常见的需求。用传统SQL当然有办法解决，但是都不够优雅，PostgreSQL的SQL扩展语法Distinct ON能一步到位解决这一类问题。

DISTINCT ON 语法

SELECT DISTINCT ON (expression [, expression ...]) select_list ...

Here expression is an arbitrary value expression that is evaluated for all rows. A set of rows for which all the expressions are equal are considered duplicates, and only the first row of the set is kept in the output. Note that the “first row” of a set is unpredictable unless the query is sorted on enough columns to guarantee a unique ordering of the rows arriving at the DISTINCT filter. (DISTINCT ON processing occurs after ORDER BY sorting.)

Distinct On应用案例

例如，找出每台机器的最新日志在日志表中，取出按照机器node_id分组，时间戳ts最大的的日志记录。

CREATE TABLE nodes(node_id INTEGER, ts TIMESTAMP);

INSERT INTO test_data
SELECT (random() * 10)::INTEGER as node_id, t
FROM generate_series('2019-01-01'::TIMESTAMP, '2019-05-01'::TIMESTAMP, '1h'::INTERVAL) AS t;

这里可以制造一些随机数据

5	2019-01-01 00:00:00.000000
0	2019-01-01 01:00:00.000000
9	2019-01-01 02:00:00.000000
1	2019-01-01 03:00:00.000000
7	2019-01-01 04:00:00.000000
2	2019-01-01 05:00:00.000000
8	2019-01-01 06:00:00.000000
3	2019-01-01 07:00:00.000000
1	2019-01-01 08:00:00.000000
4	2019-01-01 09:00:00.000000
9	2019-01-01 10:00:00.000000
0	2019-01-01 11:00:00.000000
3	2019-01-01 12:00:00.000000
6	2019-01-01 13:00:00.000000
9	2019-01-01 14:00:00.000000
1	2019-01-01 15:00:00.000000
7	2019-01-01 16:00:00.000000
8	2019-01-01 17:00:00.000000
9	2019-01-01 18:00:00.000000
10	2019-01-01 19:00:00.000000
5	2019-01-01 20:00:00.000000
4	2019-01-01 21:00:00.000000

现在使用DistinctON，这里Distinct On后面的括号里代表了记录需要按哪一个键进行除重，在括号内的表达式列表上有着相同取值的记录会只保留一条记录。（当然保留哪一条是随机的，因为分组内哪一条记录先返回是不确定的）

SELECT DISTINCT ON (node_id) * FROM test_data

0	2019-04-30 17:00:00.000000
1	2019-04-30 22:00:00.000000
2	2019-04-30 23:00:00.000000
3	2019-04-30 13:00:00.000000
4	2019-05-01 00:00:00.000000
5	2019-04-30 20:00:00.000000
6	2019-04-30 11:00:00.000000
7	2019-04-30 15:00:00.000000
8	2019-04-30 16:00:00.000000
9	2019-04-30 21:00:00.000000
10	2019-04-29 18:00:00.000000

DistinctON有一个配套的ORDER BY子句，用于指明分组内哪一条记录将被保留，排序第一条记录会留下，因此如果我们想要每台机器上的最新日志，可以这样写。

SELECT DISTINCT ON (node_id) * FROM test_data ORDER BY node_id, ts DESC NULLS LAST

0	2019-04-30 17:00:00.000000
1	2019-04-30 22:00:00.000000
2	2019-04-30 23:00:00.000000
3	2019-04-30 13:00:00.000000
4	2019-05-01 00:00:00.000000
5	2019-04-30 20:00:00.000000
6	2019-04-30 11:00:00.000000
7	2019-04-30 15:00:00.000000
8	2019-04-30 16:00:00.000000
9	2019-04-30 21:00:00.000000
10	2019-04-29 18:00:00.000000

使用索引加速Distinct On查询

Distinct On查询当然可以被索引加速，例如以下索引就可以让上面的查询用上索引

CREATE INDEX ON test_data USING btree(node_id, ts DESC NULLS LAST);

set enable_seqscan = off;
explain SELECT DISTINCT ON (node_id) * FROM test_data ORDER BY node_id, ts DESC NULLS LAST;
Unique  (cost=0.28..170.43 rows=11 width=12)
  ->  Index Only Scan using test_data_node_id_ts_idx on test_data  (cost=0.28..163.23 rows=2881 width=12)

注意，排序的时候一定要确保NULLS FIRST|LAST与查询时实际使用的规则匹配。否则可能用不上索引。

PgSQL Exclude约束

Exclude约束是一个PostgreSQL扩展，它可以实现一些更高级，更巧妙的的数据库约束。

著： 冯若航（@Vonng） | 2018-04-06

Exclude约束是一个PostgreSQL扩展，它可以实现一些更高级，更巧妙的的数据库约束。

前言

数据完整性是极其重要的，但由应用保证的数据完整性并不总是那么靠谱：人会犯傻，程序会出错。如果能通过数据库约束来强制数据完整性那是再好不过了：后端程序员不用再担心竞态条件导致的微妙错误，数据分析师也可以对数据质量充满信心，不需要验证与清洗。

关系型数据库通常会提供PRIMARY KEY, FOREIGN KEY, UNIQUE, CHECK约束，然而并不是所有的业务约束都可以用这几种约束表达。一些约束会稍微复杂一些，例如确保IP网段表中的IP范围不发生重叠，确保同一个会议室不会出现预定时间重叠，确保地理区划表中各个城市的边界不会重叠。传统上要实现这种保证是相当困难的：譬如UNIQUE约束就无法表达这种语义，CHECK与存储过程或者触发器虽然可以实现这种检查，但也相当tricky。PostgreSQL提供的EXCLUDE约束可以优雅地解决这一类问题。

Eclude约束的语法

 EXCLUDE [ USING index_method ] ( exclude_element WITH operator [, ... ] ) index_parameters [ WHERE ( predicate ) ] |
 
exclude_element in an EXCLUDE constraint is:
{ column_name | ( expression ) } [ opclass ] [ ASC | DESC ] [ NULLS { FIRST | LAST } ]

EXCLUDE子句定一个排除约束，它保证如果任意两行在指定列或表达式上使用指定操作符进行比较，不是所有的比较都将会返回TRUE。如果所有指定的操作符都测试相等，这就等价于一个UNIQUE约束，尽管一个普通的唯一约束将更快。不过，排除约束能够指定比简单相等更通用的约束。例如，你可以使用&&操作符指定一个约束，要求表中没有两行包含相互覆盖的圆（见 Section 8.8）。

排除约束使用一个索引实现，这样每一个指定的操作符必须与用于索引访问方法index_method的一个适当的操作符类（见Section 11.9）相关联。操作符被要求是交换的。每一个exclude_element可以选择性地指定一个操作符类或者顺序选项，这些在???中有完整描述。

访问方法必须支持amgettuple（见Chapter 61），目前这意味着GIN无法使用。尽管允许，但是在一个排除约束中使用 B-树或哈希索引没有意义，因为它无法做得比一个普通唯一索引更出色。因此在实践中访问方法将总是GiST或SP-GiST。

predicate允许你在该表的一个子集上指定一个排除约束。在内部这会创建一个部分索引。注意在为此周围的圆括号是必须的。

应用案例：会议室预定

假设我们想要设计一个会议室预定系统，并希望在数据库层面确保不会有冲突的会议室预定出现：即，对于同一个会议室，不允许同时存在两条预定时间范围上存在重叠的记录。那么数据库表可以这样设计：

-- PostgreSQL自带扩展，为普通类型添加GIST索引运算符支持
CREATE EXTENSION btree_gist;

-- 会议室预定表
CREATE TABLE meeting_room
(
    id      SERIAL PRIMARY KEY,
    user_id INTEGER,
    room_id INTEGER,
    range   tsrange,
    EXCLUDE USING GIST(room_id WITH = , range WITH &&)
);

这里EXCLUDE USING GIST(room_id WITH = , range WITH &&)指明了一个排它约束：不允许存在room_id相等，且range相互重叠的多条记录。

-- 用户1预定了101号房间，从早上10点到下午6点
INSERT INTO meeting_room(user_id, room_id, range) 
VALUES (1,101, tsrange('2019-01-01 10:00', '2019-01-01 18:00'));

-- 用户2也尝试预定101号房间，下午4点到下午6点
INSERT INTO meeting_room(user_id, room_id, range) 
VALUES (2,101, tsrange('2019-01-01 16:00', '2019-01-01 18:00'));

-- 用户2的预定报错，违背了排它约束
ERROR:  conflicting key value violates exclusion constraint "meeting_room_room_id_range_excl"
DETAIL:  Key (room_id, range)=(101, ["2019-01-01 16:00:00","2019-01-01 18:00:00")) conflicts with existing key (room_id, range)=(101, ["2019-01-01 10:00:00","2019-01-01 18:00:00")).

这里的EXCLUDE约束会自动创建一个相应的GIST索引：

"meeting_room_room_id_range_excl" EXCLUDE USING gist (room_id WITH =, range WITH &&)

应用案例：确保IP网段不重复

有一些约束是相当复杂的，例如确保表中的IP范围不发生重叠，类似的，确保地理区划表中各个城市的边界不会重叠。传统上要实现这种保证是相当困难的：譬如UNIQUE约束就无法表达这种语义，CHECK与存储过程或者触发器虽然可以实现这种检查，但也相当tricky。PostgreSQL提供的EXCLUDE约束可以优雅地解决这个问题。修改我们的geoips表：

create table geoips
(
  ips          inetrange,
  geo          geometry(Point),
  country_code text,
  region_code  text,
  city_name    text,
  ad_code      text,
  postal_code  text,
  EXCLUDE USING gist (ips WITH &&) DEFERRABLE INITIALLY DEFERRED 
);

PgSQL 函数易变性等级分类

PgSQL中的函数默认有三种易变性等级，合理使用可以显著改善性能。

著： 冯若航（@Vonng） | 2018-04-06

PgSQL中的函数默认有三种易变性等级，合理使用可以显著改善性能。

核心种差

VOLATILE : 有副作用，不可被优化。
STABLE：执行了数据库查询。
IMMUTABLE : 纯函数，执行结果可能会在规划时被预求值并缓存。

什么时候用？

VOLATILE : 有任何写入，有任何副作用，需要看到外部命令所做的变更，或者调用了任何VOLATILE的函数
STABLE：有数据库查询，但没有写入，或者函数的结果依赖于配置参数（例如时区）
IMMUTABLE : 纯函数。

具体解释

每个函数都带有一个易变性（Volatility） 等级。可能的取值包括 VOLATILE、STABLE，以及IMMUTABLE。创建函数时如果没有指定易变性等级，则默认为 VOLATILE。易变性是函数对优化器的承诺：

VOLATILE函数可以做任何事情，包括修改数据库状态。在连续调用时即使使用相同的参数，也可能会返回不同的结果。优化器不会优化掉此类函数，每次调用都会重新求值。
STABLE函数不能修改数据库状态，且在单条语句中保证给定同样的参数一定能返回同样的结果，因而优化器可以将相同参数的多次调用优化成一次调用。在索引扫描条件中允许使用STABLE函数，但VOLATILE函数就不行。（一次索引扫描中只会对参与比较的值求值一次，而不是每行求值一次，因而在一个索引扫描条件中不能使用 VOLATILE函数）。
IMMUTABLE函数不能修改数据库状态，并且保证任何时候给定输入永远返回相同的结果。这种分类允许优化器在一个查询用常量参数调用该函数时提前计算该函数。例如，一个 SELECT ... WHERE x = 2 + 2这样的查询可以被简化为SELECT ... WHERE x = 4，因为整数加法操作符底层的函数被标记为IMMUTABLE。

STABLE与IMMUTABLE的区别

调用次数优化

以下面这个函数为例，它只是简单的返回常数2

CREATE OR REPLACE FUNCTION return2() RETURNS INTEGER AS
$$
BEGIN
RAISE NOTICE 'INVOKED';
RETURN 2;
END;
$$ LANGUAGE PLPGSQL STABLE;

当使用STABLE标签时，它会真的调用10次，而当使用IMMUTABLE标签时，它会被优化为一次调用。

vonng=# select return2() from generate_series(1,10);
NOTICE:  INVOKED
NOTICE:  INVOKED
NOTICE:  INVOKED
NOTICE:  INVOKED
NOTICE:  INVOKED
NOTICE:  INVOKED
NOTICE:  INVOKED
NOTICE:  INVOKED
NOTICE:  INVOKED
NOTICE:  INVOKED
 return2
---------
       2
       2
       2
       2
       2
       2
       2
       2
       2
       2
(10 rows)

这里将函数的标签改为IMMUTABLE

CREATE OR REPLACE FUNCTION return2() RETURNS INTEGER AS
$$
BEGIN
RAISE NOTICE 'INVOKED';
RETURN 2;
END;
$$ LANGUAGE PLPGSQL IMMUTABLE;

再执行同样的查询，这次函数只被调用了一次

vonng=# select return2() from generate_series(1,10);
NOTICE:  INVOKED
 return2
---------
       2
       2
       2
       2
       2
       2
       2
       2
       2
       2
(10 rows)

执行计划缓存

第二个例子是有关索引条件中的函数调用，假设我们有这么一张表，包含从1到1000的整数：

create table demo as select * from generate_series(1,1000) as id;
create index idx_id on demo(id);

现在创建一个IMMUTABLE的函数mymax

CREATE OR REPLACE FUNCTION mymax(int, int)
RETURNS int
AS $$
BEGIN
     RETURN CASE WHEN $1 > $2 THEN $1 ELSE $2 END;
END;
$$ LANGUAGE 'plpgsql' IMMUTABLE;

我们会发现，当我们在索引条件中直接使用该函数时，执行计划中的索引条件被直接求值缓存并固化为了id=2

vonng=# EXPLAIN SELECT * FROM demo WHERE id = mymax(1,2);
                               QUERY PLAN
------------------------------------------------------------------------
 Index Only Scan using idx_id on demo  (cost=0.28..2.29 rows=1 width=4)
   Index Cond: (id = 2)
(2 rows)

而如果将其改为STABLE函数，则结果变为运行时求值：

vonng=# EXPLAIN SELECT * FROM demo WHERE id = mymax(1,2);
                               QUERY PLAN
------------------------------------------------------------------------
 Index Only Scan using idx_id on demo  (cost=0.53..2.54 rows=1 width=4)
   Index Cond: (id = mymax(1, 2))
(2 rows)

架构成熟度模型

架构，特别是互联网服务的架构，按照组织的典型特征与负载数量级，可以简单地分为以下九个阶段。

著： 冯若航（@Vonng） | 2018-03-12

架构，特别是互联网服务的架构，按照组织的典型特征与负载数量级，可以分为以下九个阶段。

这种划分方式虽然简单粗暴，但是很有效果。

1~3为简单系统，4-6为中等系统，7-9为复杂系统。

Go数据库接口教程

同JDBC类似，Go也有标准的数据库访问接口。本文详细介绍了database/sql的使用方法和注意事项。

著： 冯若航（@Vonng） | 2017-08-24

Go数据库教程: database/sql

Go使用SQL与类SQL数据库的惯例是通过标准库database/sql。这是一个对关系型数据库的通用抽象，它提供了标准的、轻量的、面向行的接口。不过database/sql的包文档只讲它做了什么，却对如何使用只字未提。快速指南远比堆砌事实有用，本文讲述了database/sql的使用方法及其注意事项。

1. 顶层抽象

在Go中访问数据库需要用到sql.DB接口：它可以创建语句(statement)和事务(transaction)，执行查询，获取结果。

sql.DB并不是数据库连接，也并未在概念上映射到特定的数据库(Database)或模式(schema)。它只是一个抽象的接口，不同的具体驱动有着不同的实现方式。通常而言，sql.DB会处理一些重要而麻烦的事情，例如操作具体的驱动打开/关闭实际底层数据库的连接，按需管理连接池。

sql.DB这一抽象让用户不必考虑如何管理并发访问底层数据库的问题。当一个连接在执行任务时会被标记为正在使用。用完之后会放回连接池中。不过用户如果用完连接后忘记释放，就会产生大量的连接，极可能导致资源耗尽（建立太多连接，打开太多文件，缺少可用网络端口）。

2. 导入驱动

使用数据库时，除了database/sql包本身，还需要引入想使用的特定数据库驱动。

尽管有时候一些数据库特有的功能必需通过驱动的Ad Hoc接口来实现，但通常只要有可能，还是应当尽量只用database/sql中定义的类型。这可以减小用户代码与驱动的耦合，使切换驱动时代码改动最小化，也尽可能地使用户遵循Go的惯用法。本文使用PostgreSQL为例，PostgreSQL的著名的驱动有：

这里以pgx为例，它性能表现不俗，并对PostgreSQL诸多特性与类型有着良好的支持。既可使用Ad-Hoc API，也提供了标准数据库接口的实现：github.com/jackc/pgx/stdlib。

import (
	"database/sql"
	_ "github.com/jackx/pgx/stdlib"
)

使用_别名来匿名导入驱动，驱动的导出名字不会出现在当前作用域中。导入时，驱动的初始化函数会调用sql.Register将自己注册在database/sql包的全局变量sql.drivers中，以便以后通过sql.Open访问。

3. 访问数据

加载驱动包后，需要使用sql.Open()来创建sql.DB：

func main() {
	db, err := sql.Open("pgx","postgres://localhost:5432/postgres")
	if err != nil {
		log.Fatal(err)
	}
	defer db.Close()
}

sql.Open有两个参数：

第一个参数是驱动名称，字符串类型。为避免混淆，一般与包名相同，这里是pgx。
第二个参数也是字符串，内容依赖于特定驱动的语法。通常是URL的形式，例如postgres://localhost:5432。
绝大多数情况下都应当检查database/sql操作所返回的错误。
一般而言，程序需要在退出时通过sql.DB的Close()方法释放数据库连接资源。如果其生命周期不超过函数的范围，则应当使用defer db.Close()

执行sql.Open()并未实际建立起到数据库的连接，也不会验证驱动参数。第一个实际的连接会惰性求值，延迟到第一次需要时建立。用户应该通过db.Ping()来检查数据库是否实际可用。

if err = db.Ping(); err != nil {
	// do something about db error
}

sql.DB对象是为了长连接而设计的，不要频繁Open()和Close()数据库。而应该为每个待访问的数据库创建一个sql.DB实例，并在用完前一直保留它。需要时可将其作为参数传递，或注册为全局对象。

如果没有按照database/sql设计的意图，不把sql.DB当成长期对象来用而频繁开关启停，就可能遭遇各式各样的错误：无法复用和共享连接，耗尽网络资源，由于TCP连接保持在TIME_WAIT状态而间断性的失败等……

4. 获取结果

有了sql.DB实例之后就可以开始执行查询语句了。

Go将数据库操作分为两类：Query与Exec。两者的区别在于前者会返回结果，而后者不会。

Query表示查询，它会从数据库获取查询结果（一系列行，可能为空）。
Exec表示执行语句，它不会返回行。

此外还有两种常见的数据库操作模式：

QueryRow表示只返回一行的查询，作为Query的一个常见特例。
Prepare表示准备一个需要多次使用的语句，供后续执行用。

4.1 获取数据

让我们看一个如何查询数据库并且处理结果的例子：利用数据库计算从1到10的自然数之和。

func example() {
	var sum, n int32

	// invoke query
	rows, err := db.Query("SELECT generate_series(1,$1)", 10)
    // handle query error
	if err != nil {
		fmt.Println(err)
	}
    // defer close result set
	defer rows.Close()

	// Iter results
	for rows.Next() {
		if err = rows.Scan(&n); err != nil {
			fmt.Println(err)	// Handle scan error
		}
		sum += n				// Use result
	}

	// check iteration error
	if rows.Err() != nil {
		fmt.Println(err)
	}

	fmt.Println(sum)
}

整体工作流程如下：
1. 使用db.Query()来发送查询到数据库，获取结果集Rows，并检查错误。
2. 使用rows.Next()作为循环条件，迭代读取结果集。
3. 使用rows.Scan从结果集中获取一行结果。
4. 使用rows.Err()在退出迭代后检查错误。
5. 使用rows.Close()关闭结果集，释放连接。
一些需要详细说明的地方：
1. db.Query会返回结果集*Rows和错误。每个驱动返回的错误都不一样，用错误字符串来判断错误类型并不是明智的做法，更好的方法是对抽象的错误做Type Assertion，利用驱动提供的更具体的信息来处理错误。当然类型断言也可能产生错误，这也是需要处理的。
```
if err.(pgx.PgError).Code == "0A000" {
// Do something with that type or error
}
```
  ``
2. rows.Next()会指明是否还有未读取的数据记录，通常用于迭代结果集。迭代中的错误会导致rows.Next()返回false。
3. rows.Scan()用于在迭代中获取一行结果。数据库会使用wire protocal通过TCP/UnixSocket传输数据，对Pg而言，每一行实际上对应一条DataRow消息。Scan接受变量地址，解析DataRow消息并填入相应变量中。因为Go语言是强类型的，所以用户需要创建相应类型的变量并在rows.Scan中传入其指针，Scan函数会根据目标变量的类型执行相应转换。例如某查询返回一个单列string结果集，用户可以传入[]byte或string类型变量的地址，Go会将原始二进制数据或其字符串形式填入其中。但如果用户知道这一列始终存储着数字字面值，那么相比传入string地址后手动使用strconv.ParseInt()解析，更推荐的做法是直接传入一个整型变量的地址（如上面所示），Go会替用户完成解析工作。如果解析出错，Scan会返回相应的错误。
4. rows.Err()用于在退出迭代后检查错误。正常情况下迭代退出是因为内部产生的EOF错误，使得下一次rows.Next() == false，从而终止循环；在迭代结束后要检查错误，以确保迭代是因为数据读取完毕，而非其他“真正”错误而结束的。遍历结果集的过程实际上是网络IO的过程，可能出现各种错误。健壮的程序应当考虑这些可能，而不能总是假设一切正常。
5. rows.Close()用于关闭结果集。结果集引用了数据库连接，并会从中读取结果。读取完之后必须关闭它才能避免资源泄露。只要结果集仍然打开着，相应的底层连接就处于忙碌状态，不能被其他查询使用。
6. 因错误(包括EOF)导致的迭代退出会自动调用rows.Close()关闭结果集（和释放底层连接）。但如果程序自行意外地退出了循环，例如中途break & return，结果集就不会被关闭，产生资源泄露。rows.Close方法是幂等的，重复调用不会产生副作用，因此建议使用 defer rows.Close()来关闭结果集。

以上就是在Go中使用数据库的标准方式。

4.2 单行查询

如果一个查询每次最多返回一行，那么可以用快捷的单行查询来替代冗长的标准查询，例如上例可改写为：

var sum int
err := db.QueryRow("SELECT sum(n) FROM (SELECT generate_series(1,$1) as n) a;", 10).Scan(&sum)
if err != nil {
	fmt.Println(err)
}
fmt.Println(sum)

不同于Query，如果查询发生错误，错误会延迟到调用Scan()时统一返回，减少了一次错误处理判断。同时QueryRow也避免了手动操作结果集的麻烦。

需要注意的是，对于单行查询，Go将没有结果的情况视为错误。sql包中定义了一个特殊的错误常量ErrNoRows，当结果为空时，QueryRow().Scan()会返回它。

4.3 修改数据

什么时候用Exec，什么时候用Query，这是一个问题。通常DDL和增删改使用Exec，返回结果集的查询使用Query。但这不是绝对的，这完全取决于用户是否希望想要获取返回结果。例如在PostgreSQL中：INSERT ... RETURNING *;虽然是一条插入语句，但它也有返回结果集，故应当使用Query而不是Exec。

Query和Exec返回的结果不同，两者的签名分别是：

func (s *Stmt) Query(args ...interface{}) (*Rows, error)
func (s *Stmt) Exec(args ...interface{}) (Result, error)

Exec不需要返回数据集，返回的结果是Result，Result接口允许获取执行结果的元数据

type Result interface {
	// 用于返回自增ID，并不是所有的关系型数据库都有这个功能。
	LastInsertId() (int64, error)
	// 返回受影响的行数。
	RowsAffected() (int64, error)
}

Exec的用法如下所示：

db.Exec(`CREATE TABLE test_users(id INTEGER PRIMARY KEY ,name TEXT);`)
db.Exec(`TRUNCATE test_users;`)
stmt, err := db.Prepare(`INSERT INTO test_users(id,name) VALUES ($1,$2) RETURNING id`)
if err != nil {
	fmt.Println(err.Error())
}
res, err := stmt.Exec(1, "Alice")

if err != nil {
	fmt.Println(err)
} else {
	fmt.Println(res.RowsAffected())
	fmt.Println(res.LastInsertId())
}

相比之下Query则会返回结果集对象*Rows，使用方式见上节。其特例QueryRow使用方式如下：

db.Exec(`CREATE TABLE test_users(id INTEGER PRIMARY KEY ,name TEXT);`)
db.Exec(`TRUNCATE test_users;`)
stmt, err := db.Prepare(`INSERT INTO test_users(id,name) VALUES ($1,$2) RETURNING id`)
if err != nil {
	fmt.Println(err.Error())
}
var returnID int
err = stmt.QueryRow(4, "Alice").Scan(&returnID)
if err != nil {
	fmt.Println(err)
} else {
	fmt.Println(returnID)
}

同样的语句使用Exec和Query执行有巨大的差别。如上文所述，Query会返回结果集Rows，而存在未读取数据的Rows其实会占用底层连接直到rows.Close()为止。因此，使用Query但不读取返回结果，会导致底层连接永远无法释放。database/sql期望用户能够用完就把连接还回来，所以这样的用法很快就会导致资源耗尽（连接过多）。所以，应该用Exec的语句绝不可用Query来执行。

4.4 准备查询

在上一节的两个例子中，没有直接使用数据库的Query和Exec方法，而是首先执行了db.Prepare获取准备好的语句(prepared statement)。准备好的语句Stmt和sql.DB一样，都可以执行Query、Exec等方法。

4.4.1 准备语句的优势

在查询前进行准备是Go语言中的惯用法，多次使用的查询语句应当进行准备（Prepare）。准备查询的结果是一个准备好的语句（prepared statement），语句中可以包含执行时所需参数的占位符（即绑定值）。准备查询比拼字符串的方式好很多，它可以转义参数，避免SQL注入。同时，准备查询对于一些数据库也省去了解析和生成执行计划的开销，有利于性能。

4.4.2 占位符

PostgreSQL使用$N作为占位符，N是一个从1开始递增的整数，代表参数的位置，方便参数的重复使用。MySQL使用?作为占位符，SQLite两种占位符都可以，而Oracle则使用:param1的形式。

MySQL               PostgreSQL            Oracle
=====               ==========            ======
WHERE col = ?       WHERE col = $1        WHERE col = :col
VALUES(?, ?, ?)     VALUES($1, $2, $3)    VALUES(:val1, :val2, :val3)

以PostgreSQL为例，在上面的例子中："SELECT generate_series(1,$1)" 就用到了$N的占位符形式，并在后面提供了与占位符数目匹配的参数个数。

4.4.3 底层内幕

准备语句有着各种优点：安全，高效，方便。但Go中实现它的方式可能和用户所设想的有轻微不同，尤其是关于和database/sql内部其他对象交互的部分。

在数据库层面，准备语句Stmt是与单个数据库连接绑定的。通常的流程是：客户端向服务器发送带有占位符的查询语句用于准备，服务器返回一个语句ID，客户端在实际执行时，只需要传输语句ID和相应的参数即可。因此准备语句无法在连接之间共享，当使用新的数据库连接时，必须重新准备。

database/sql并没有直接暴露出数据库连接。用户是在DB或Tx上执行Prepare，而不是Conn。因此database/sql提供了一些便利处理，例如自动重试。这些机制隐藏在Driver中实现，而不会暴露在用户代码中。其工作原理是：当用户准备一条语句时，它在连接池中的一个连接上进行准备。Stmt对象会引用它实际使用的连接。当执行Stmt时，它会尝试会用引用的连接。如果那个连接忙碌或已经被关闭，它会获取一个新的连接，并在连接上重新准备，然后再执行。

因为当原有连接忙时，Stmt会在其他连接上重新准备。因此当高并发地访问数据库时，大量的连接处于忙碌状态，这会导致Stmt不断获取新的连接并执行准备，最终导致资源泄露，甚至超出服务端允许的语句数目上限。所以通常应尽量采用扇入的方式减小数据库访问并发数。

4.4.4 查询的微妙之处

数据库连接其实是实现了Begin,Close,Prepare方法的接口。

type Conn interface {
        Prepare(query string) (Stmt, error)
        Close() error
        Begin() (Tx, error)
}

所以连接接口上实际并没有Exec，Query方法，这些方法其实定义在Prepare返回的Stmt上。对于Go而言，这意味着db.Query()实际上执行了三个操作：首先对查询语句做了准备，然后执行查询语句，最后关闭准备好的语句。这对数据库而言，其实是3个来回。设计粗糙的程序与简陋实现驱动可能会让应用与数据库交互的次数增至3倍。好在绝大多数数据库驱动对于这种情况有优化，如果驱动实现sql.Queryer接口：

type Queryer interface {
        Query(query string, args []Value) (Rows, error)
}

那么database/sql就不会再进行Prepare-Execute-Close的查询模式，而是直接使用驱动实现的Query方法向数据库发送查询。对于查询都是即拼即用，也不担心安全问题的情况下，直接Query可以有效减少性能开销。

5. 使用事务

事物是关系型数据库的核心特性。Go中事务（Tx）是一个持有数据库连接的对象，它允许用户在同一个连接上执行上面提到的各类操作。

5.1 事务基本操作

通过db.Begin()来开启一个事务，Begin方法会返回一个事务对象Tx。在结果变量Tx上调用Commit()或者Rollback()方法会提交或回滚变更，并关闭事务。在底层，Tx会从连接池中获得一个连接并在事务过程中保持对它的独占。事务对象Tx上的方法与数据库对象sql.DB的方法一一对应，例如Query,Exec等。事务对象也可以准备(prepare)查询，由事务创建的准备语句会显式绑定到创建它的事务。

5.2 事务注意事项

使用事务对象时，不应再执行事务相关的SQL语句，例如BEGIN,COMMIT等。这可能产生一些副作用：

Tx对象一直保持打开状态，从而占用了连接。
数据库状态不再与Go中相关变量的状态保持同步。
事务提前终止会导致一些本应属于事务内的查询语句不再属于事务的一部分，这些被排除的语句有可能会由别的数据库连接而非原有的事务专属连接执行。

当处于事务内部时，应当使用Tx对象的方法而非DB的方法，DB对象并不是事务的一部分，直接调用数据库对象的方法时，所执行的查询并不属于事务的一部分，有可能由其他连接执行。

5.3 Tx的其他应用场景

如果需要修改连接的状态，也需要用到Tx对象，即使用户并不需要事务。例如：

创建仅连接可见的临时表
设置变量，例如SET @var := somevalue
修改连接选项，例如字符集，超时设置。

在Tx上执行的方法都保证同一个底层连接执行，这使得对连接状态的修改对后续操作起效。这是Go中实现这种功能的标准方式。

5.4 在事务中准备语句

调用Tx.Prepare会创建一个与事务绑定的准备语句。在事务中使用准备语句，有一个特殊问题需要关注：一定要在事务结束前关闭准备语句。

在事务中使用defer stmt.Close()是相当危险的。因为当事务结束后，它会释放自己持有的数据库连接，但事务创建的未关闭Stmt仍然保留着对事务连接的引用。在事务结束后执行stmt.Close()，如果原来释放的连接已经被其他查询获取并使用，就会产生竞争，极有可能破坏连接的状态。

6. 处理空值

可空列（Nullable Column）非常的恼人，容易导致代码变得丑陋。如果可以，在设计时就应当尽量避免。因为：

Go语言的每一个变量都有着默认零值，当数据的零值没有意义时，可以用零值来表示空值。但很多情况下，数据的零值和空值实际上有着不同的语义。单独的原子类型无法表示这种情况。
标准库只提供了有限的四种Nullable type：：NullInt64, NullFloat64, NullString, NullBool。并没有诸如NullUint64，NullYourFavoriteType，用户需要自己实现。
空值有很多麻烦的地方。例如用户认为某一列不会出现空值而采用基本类型接收时却遇到了空值，程序就会崩溃。这种错误非常稀少，难以捕捉、侦测、处理，甚至意识到。

6.1 使用额外的标记字段

database\sql提供了四种基本可空数据类型：使用基本类型和一个布尔标记的复合结构体表示可空值。例如：

type NullInt64 struct {
        Int64 int64
        Valid bool // Valid is true if Int64 is not NULL
}

可空类型的使用方法与基本类型一致：

for rows.Next() {
	var s sql.NullString
	err := rows.Scan(&s)
	// check err
	if s.Valid {
	   // use s.String
	} else {
	   // handle NULL case
	}
}

6.2 使用指针

在Java中通过装箱（boxing）处理可空类型，即把基本类型包装成一个类，并通过指针引用。于是，空值语义可以通过指针为空来表示。Go当然也可以采用这种办法，不过标准库中并没有提供这种实现方式。pgx提供了这种形式的可空类型支持。

6.3 使用零值表示空值

如果数据本身从语义上就不会出现零值，或者根本不区分零值和空值，那么最简便的方法就是使用零值来表示空值。驱动go-pg提供了这种形式的支持。

6.4 自定义处理逻辑

任何实现了Scanner接口的类型，都可以作为Scan传入的地址参数类型。这就允许用户自己定制复杂的解析逻辑，实现更丰富的类型支持。

type Scanner interface {
  		// Scan 从数据库驱动中扫描出一个值，当不能无损地转换时，应当返回错误
  		// src可能是int64, float64, bool, []byte, string, time.Time，也可能是nil，表示空值。
        Scan(src interface{}) error
}

6.5 在数据库层面解决

通过对列添加NOT NULL约束，可以确保任何结果都不会为空。或者，通过在SQL中使用COALESCE来为NULL设定默认值。

7. 处理动态列

Scan()函数要求传递给它的目标变量的数目，与结果集中的列数正好匹配，否则就会出错。

但总有一些情况，用户事先并不知道返回的结果到底有多少列，例如调用一个返回表的存储过程时。

在这种情况下，使用rows.Columns()来获取列名列表。在不知道列类型情况下，应当使用sql.RawBytes作为接受变量的类型。获取结果后自行解析。

cols, err := rows.Columns()
if err != nil {
	// handle this....
}

// 目标列是一个动态生成的数组
dest := []interface{}{
	new(string),
	new(uint32),
	new(sql.RawBytes),
}

// 将数组作为可变参数传入Scan中。
err = rows.Scan(dest...)
// ...

8. 连接池

database/sql包里实现了一个通用的连接池，它只提供了非常简单的接口，除了限制连接数、设置生命周期基本没有什么定制选项。但了解它的一些特性也是很有帮助的。

连接池意味着：同一个数据库上的连续两条查询可能会打开两个连接，在各自的连接上执行。这可能导致一些让人困惑的错误，例如程序员希望锁表插入时连续执行了两条命令：LOCK TABLE和INSERT，结果却会阻塞。因为执行插入时，连接池创建了一个新的连接，而这条连接并没有持有表锁。
在需要时，而且连接池中没有可用的连接时，连接才被创建。
默认情况下连接数量没有限制，想创建多少就有多少。但服务器允许的连接数往往是有限的。
用db.SetMaxIdleConns(N)来限制连接池中空闲连接的数量，但是这并不会限制连接池的大小。连接回收(recycle)的很快，通过设置一个较大的N，可以在连接池中保留一些空闲连接，供快速复用(reuse)。但保持连接空闲时间过久可能会引发其他问题，比如超时。设置N=0则可以避免连接空闲太久。
用db.SetMaxOpenConns(N)来限制连接池中打开的连接数量。
用db.SetConnMaxLifetime(d time.Duration)来限制连接的生命周期。连接超时后，会在需要时惰性回收复用。

9. 微妙行为

database/sql并不复杂，但某些情况下它的微妙表现仍然会出人意料。

9.1 资源耗尽

不谨慎地使用database/sql会给自己挖许多坑，最常见的问题就是资源枯竭（resource exhaustion）：

打开和关闭数据库（sql.DB）可能会导致资源枯竭；
结果集没有读取完毕，或者调用rows.Close()失败，结果集会一直占用池里的连接；
使用Query()执行一些不返回结果集的语句，返回的未读取结果集会一直占用池里的连接；
不了解准备语句（Prepared Statement）的工作原理会产生许多额外的数据库访问。

9.2 Uint64

Go底层使用int64来表示整型，使用uint64时应当极其小心。使用超出int64表示范围的整数作为参数，会产生一个溢出错误：

// Error: constant 18446744073709551615 overflows int
_, err := db.Exec("INSERT INTO users(id) VALUES", math.MaxUint64)

这种类型的错误非常不容易发现，它可能一开始表现的很正常，但是溢出之后问题就来了。

9.3 不合预期的连接状态

连接的状态，例如是否处于事务中，所连接的数据库，设置的变量等，应该通过Go的相关类型来处理，而不是通过SQL语句。用户不应当对自己的查询在哪条连接上执行作任何假设，如果需要在同一条连接上执行，需要使用Tx。

举个例子，通过USE DATABASE改变连接的数据库对于不少人是习以为常的操作，执行这条语句，只影响当前连接的状态，其他连接仍然访问的是原来的数据库。如果没有使用事务Tx，后续的查询并不能保证仍然由当前的连接执行，所以这些查询很可能并不像用户预期的那样工作。

更糟糕的是，如果用户改变了连接的状态，用完之后它成为空连接又回到了连接池，这会污染其他代码的状态。尤其是直接在SQL中执行诸如BEGIN或COMMIT这样的语句。

9.4 驱动的特殊语法

尽管database/sql是一个通用的抽象，但不同的数据库，不同的驱动仍然会有不同的语法和行为。参数占位符就是一个例子。

9.5 批量操作

出乎意料的是，标准库没有提供对批量操作的支持。即INSERT INTO xxx VALUES (1),(2),...;这种一条语句插入多条数据的形式。目前实现这个功能还需要自己手动拼SQL。

9.6 执行多条语句

database/sql并没有对在一次查询中执行多条SQL语句的显式支持，具体的行为以驱动的实现为准。所以对于

_, err := db.Exec("DELETE FROM tbl1; DELETE FROM tbl2") // Error/unpredictable result

这样的查询，怎样执行完全由驱动说了算，用户并无法确定驱动到底执行了什么，又返回了什么。

9.7 事务中的多条语句

因为事务保证在它上面执行的查询都由同一个连接来执行，因此事务中的语句必需按顺序一条一条执行。对于返回结果集的查询，结果集必须Close()之后才能进行下一次查询。用户如果尝试在前一条语句的结果还没读完前就执行新的查询，连接就会失去同步。这意味着事务中返回结果集的语句都会占用一次单独的网络往返。

10. 其他

本文主体基于[[Go database/sql tutorial]]([Go database/sql tutorial])，由我翻译并进行一些增删改，修正过时错误的内容。转载保留出处。

GO与PG实现缓存同步

巧妙运用Pg的Notify功能，可以方便地通知应用元数据变更，实现基于触发器的逻辑复制。

著： 冯若航（@Vonng） | 2017-08-03

Parallel与Hierarchy是架构设计的两大法宝，缓存是Hierarchy在IO领域的体现。单线程场景下缓存机制的实现可以简单到不可思议，但很难想象成熟的应用会只有一个实例。在使用缓存的同时引入并发，就不得不考虑一个问题：如何保证每个实例的缓存与底层数据副本的数据一致性（和实时性）。

PostgreSQL在版本9引入了流式复制，在版本10引入了逻辑复制，但这些都是针对PostgreSQL数据库而言的。如果希望PostgreSQL中某张表的部分数据与应用内存中的状态保持一致，我们还是需要自己实现一种逻辑复制的机制。对于关键的少量元数据而言，使用触发器与Notify-Listen就是一个不错的选择。

传统方法

最简单粗暴的办法就是定时重新拉取，例如每个整点，所有应用一起去数据库拉取一次最新版本的数据。很多应用都是这么做的。当然问题也很多：拉的间隔长了，变更不能及时应用，用户体验差；拉的频繁了，IO压力大。而且实例数目和数据大小一旦膨胀起来，对于宝贵的IO资源是很大的浪费。

异步通知是一种更好的办法，尤其是在读请求远多于写请求的情况下。接受到写请求的实例，通过发送广播的方式通知其他实例。Redis的PubSub就可以很好地实现这个功能。如果原本下层存储就是Redis自然是再方便不过，但如果下层存储是关系型数据库的话，为这样一个功能引入一个新的组件似乎有些得不偿失。况且考虑到后台管理程序或者其他应用如果在修改了数据库后也要去redis发布通知，实在太麻烦了。一种可行的办法是通过数据库中间件来监听RDS变动并广播通知，淘宝不少东西就是这么做的。但如果DB本身就能搞定的事情，为什么需要额外的组件呢？通过PostgreSQL的Notfiy-Listen机制，可以方便地实现这种功能。

目标

无论从任何渠道产生的数据库记录变更（增删改）都能被所有相关应用实时感知，用于维护自身缓存与数据库内容的一致性。

原理

PostgreSQL行级触发器 + Notify机制 + 自定义协议 + Smart Client

行级触发器：通过为我们感兴趣的表建立一个行级别的写触发器，对数据表中的每一行记录的Update,Delete,Insert都会出发自定义函数的执行。
Notify：通过PostgreSQL内建的异步通知机制向指定的Channel发送通知
自定义协议：协商消息格式，传递操作的类型与变更记录的标识
Smart Client：客户端监听消息变更，根据消息对缓存执行相应的操作。

实际上这样一套东西就是一个超简易的WAL（Write After Log）实现，从而使应用内部的缓存状态能与数据库保持实时一致（compare to poll）。

实现

DDL

这里以一个最简单的表作为示例，一张以主键标识的users表。

-- 用户表
CREATE TABLE users (
  id   TEXT,
  name TEXT,
  PRIMARY KEY (id)
);

触发器

-- 通知触发器
CREATE OR REPLACE FUNCTION notify_change() RETURNS TRIGGER AS $$
BEGIN
  IF    (TG_OP = 'INSERT') THEN 
	PERFORM pg_notify(TG_RELNAME || '_chan', 'I' || NEW.id); RETURN NEW;
  ELSIF (TG_OP = 'UPDATE') THEN 
	PERFORM pg_notify(TG_RELNAME || '_chan', 'U' || NEW.id); RETURN NEW;
  ELSIF (TG_OP = 'DELETE') THEN 
	PERFORM pg_notify(TG_RELNAME || '_chan', 'D' || OLD.id); RETURN OLD;
  END IF;
END; $$ LANGUAGE plpgsql SECURITY DEFINER;

这里创建了一个触发器函数，通过内置变量TG_OP获取操作的名称，TG_RELNAME获取表名。每当触发器执行时，它会向名为<table_name>_chan的通道发送指定格式的消息：[I|U|D]<id>

题外话：通过行级触发器，还可以实现一些很实用的功能，例如In-DB Audit，自动更新字段值，统计信息，自定义备份策略与回滚逻辑等。

-- 为用户表创建行级触发器，监听INSERT UPDATE DELETE 操作。
CREATE TRIGGER t_user_notify AFTER INSERT OR UPDATE OR DELETE ON users
FOR EACH ROW EXECUTE PROCEDURE notify_change();

创建触发器也很简单，表级触发器对每次表变更执行一次，而行级触发器对每条记录都会执行一次。这样，数据库的里的工作就算全部完成了。

消息格式

通知需要传达出两个信息：变更的操作类型，变更的实体标记。

变更的操作类型就是增删改：INSERT,DELETE,UPDATE。通过一个打头的字符'[I|U|D]‘就可以标识。
变更的对象可以通过实体主键来标识。如果不是字符串类型，还需要确定一种无歧义的序列化方式。

这里为了省事直接使用字符串类型作为ID，那么插入一条id=1的记录，对应的消息就是I1，更新一条id=5的记录消息就是U5，删除id=3的记录消息就是D3。

完全可以通过更复杂的消息协议实现更强大的功能。

SmartClient

数据库的机制需要客户端的配合才能生效，客户端需要监听数据库的变更通知，才能将变更实时应用到自己的缓存副本中。对于插入和更新，客户端需要根据ID重新拉取相应实体，对于删除，客户端需要删除自己缓存副本的相应实体。以Go语言为例，编写了一个简单的客户端模块。

本例中使用一个以User.ID作为键，User对象作为值的并发安全字典Users sync.Map作为缓存。

作为演示，启动了另一个goroutine对数据库写入了一些变更。

package main

import "sync"
import "strings"
import "github.com/go-pg/pg"
import . "github.com/Vonng/gopher/db/pg"
import log "github.com/Sirupsen/logrus"

type User struct {
	ID   string `sql:",pk"`
	Name string
}

var Users sync.Map // Users 内部数据缓存

func LoadAllUser() {
	var users []User
	Pg.Query(&users, `SELECT ID,name FROM users;`)
	for _, user := range users {
		Users.Store(user.ID, user)
	}
}

func LoadUser(id string) {
	user := User{ID: id}
	Pg.Select(&user)
	Users.Store(user.ID, user)
}

func PrintUsers() string {
	var buf []string
	Users.Range(func(key, value interface{}) bool {
		buf = append(buf, key.(string));
		return true
	})
	return strings.Join(buf, ",")
}

// ListenUserChange 会监听PostgreSQL users数据表中的变动通知
func ListenUserChange() {
	go func(c <-chan *pg.Notification) {
		for notify := range c {
			action, id := notify.Payload[0], notify.Payload[1:]
			switch action {
			case 'I':
				fallthrough
			case 'U':
				LoadUser(id);
			case 'D':
				Users.Delete(id)
			}
			log.Infof("[NOTIFY] Action:%c ID:%s Users: %s", action, id, PrintUsers())
		}
	}(Pg.Listen("users_chan").Channel())
}

// MakeSomeChange 会向数据库写入一些变更
func MakeSomeChange() {
	go func() {
		Pg.Insert(&User{"001", "张三"})
		Pg.Insert(&User{"002", "李四"})
		Pg.Insert(&User{"003", "王五"})  // 插入
		Pg.Update(&User{"003", "王麻子"}) // 改名
		Pg.Delete(&User{ID: "002"})    // 删除
	}()
}

func main() {
	Pg = NewPg("postgres://localhost:5432/postgres")
	Pg.Exec(`TRUNCATE TABLE users;`)
	LoadAllUser()
	ListenUserChange()
	MakeSomeChange()
	<-make(chan struct{})
}

运行结果如下：

[NOTIFY] Action:I ID:001 Users: 001          
[NOTIFY] Action:I ID:002 Users: 001,002      
[NOTIFY] Action:I ID:003 Users: 002,003,001  
[NOTIFY] Action:U ID:003 Users: 001,002,003  
[NOTIFY] Action:D ID:002 Users: 001,003

可以看出，缓存确是与数据库保持了同样的状态。

应用场景

小数据量下这种做法是相当可靠的，大数据量下尚未进行充分的测试。

其实，对于上例中缓存同步的场景，完全不需要自定义消息格式，只要发送发生变更的记录ID，由应用直接拉取，然后覆盖或删除缓存中的记录即可。

PgSQL审计触发器

有时候，我们希望记录一些重要的元数据变更，以便事后审计之用。PostgreSQL的触发器就可以很方便地自动解决这一需求。

著： 冯若航（@Vonng） | 2017-06-09

有时候，我们希望记录一些重要的元数据变更，以便事后审计之用。

PostgreSQL的触发器就可以很方便地自动解决这一需求。

-- 创建一个审计专用schema，并废除所有非superuser的权限。
DROP SCHEMA IF EXISTS audit CASCADE;
CREATE SCHEMA IF NOT EXISTS audit;
REVOKE CREATE ON SCHEMA audit FROM PUBLIC;

-- 审计表
CREATE TABLE audit.action_log (
  schema_name   TEXT                     NOT NULL,
  table_name    TEXT                     NOT NULL,
  user_name     TEXT,
  time          TIMESTAMP WITH TIME ZONE NOT NULL DEFAULT CURRENT_TIMESTAMP,
  action        TEXT                     NOT NULL CHECK (action IN ('I', 'D', 'U')),
  original_data TEXT,
  new_data      TEXT,
  query         TEXT
) WITH (FILLFACTOR = 100
);

-- 审计表权限
REVOKE ALL ON audit.action_log FROM PUBLIC;
GRANT SELECT ON audit.action_log TO PUBLIC;


-- 索引
CREATE INDEX logged_actions_schema_table_idx
  ON audit.action_log (((schema_name || '.' || table_name) :: TEXT));

CREATE INDEX logged_actions_time_idx
  ON audit.action_log (time);

CREATE INDEX logged_actions_action_idx
  ON audit.action_log (action);
---------------------------------------------------------------


---------------------------------------------------------------
-- 创建审计触发器函数
---------------------------------------------------------------
CREATE OR REPLACE FUNCTION audit.logger()
  RETURNS TRIGGER AS $body$
DECLARE
  v_old_data TEXT;
  v_new_data TEXT;
BEGIN
  IF (TG_OP = 'UPDATE')
  THEN
    v_old_data := ROW (OLD.*);
    v_new_data := ROW (NEW.*);
    INSERT INTO audit.action_log (schema_name, table_name, user_name, action, original_data, new_data, query)
    VALUES (TG_TABLE_SCHEMA :: TEXT, TG_TABLE_NAME :: TEXT, session_user :: TEXT, substring(TG_OP, 1, 1), v_old_data,
            v_new_data, current_query());
    RETURN NEW;
  ELSIF (TG_OP = 'DELETE')
    THEN
      v_old_data := ROW (OLD.*);
      INSERT INTO audit.action_log (schema_name, table_name, user_name, action, original_data, query)
      VALUES (TG_TABLE_SCHEMA :: TEXT, TG_TABLE_NAME :: TEXT, session_user :: TEXT, substring(TG_OP, 1, 1), v_old_data,
              current_query());
      RETURN OLD;
  ELSIF (TG_OP = 'INSERT')
    THEN
      v_new_data := ROW (NEW.*);
      INSERT INTO audit.action_log (schema_name, table_name, user_name, action, new_data, query)
      VALUES (TG_TABLE_SCHEMA :: TEXT, TG_TABLE_NAME :: TEXT, session_user :: TEXT, substring(TG_OP, 1, 1), v_new_data,
              current_query());
      RETURN NEW;
  ELSE
    RAISE WARNING '[AUDIT.IF_MODIFIED_FUNC] - Other action occurred: %, at %', TG_OP, now();
    RETURN NULL;
  END IF;

  EXCEPTION
  WHEN data_exception
    THEN
      RAISE WARNING '[AUDIT.IF_MODIFIED_FUNC] - UDF ERROR [DATA EXCEPTION] - SQLSTATE: %, SQLERRM: %', SQLSTATE, SQLERRM;
      RETURN NULL;
  WHEN unique_violation
    THEN
      RAISE WARNING '[AUDIT.IF_MODIFIED_FUNC] - UDF ERROR [UNIQUE] - SQLSTATE: %, SQLERRM: %', SQLSTATE, SQLERRM;
      RETURN NULL;
  WHEN OTHERS
    THEN
      RAISE WARNING '[AUDIT.IF_MODIFIED_FUNC] - UDF ERROR [OTHER] - SQLSTATE: %, SQLERRM: %', SQLSTATE, SQLERRM;
      RETURN NULL;
END;
$body$
LANGUAGE plpgsql
SECURITY DEFINER
SET search_path = pg_catalog, audit;

COMMENT ON FUNCTION audit.logger() IS '记录特定表上的插入、修改、删除行为';
---------------------------------------------------------------


---------------------------------------------------------------
-- 最后修改时间审计触发器函数
---------------------------------------------------------------
-- 当记录发生变更前，记录修改时间。
CREATE OR REPLACE FUNCTION audit.update_mtime()
  RETURNS TRIGGER AS $$
BEGIN
  NEW.mtime = now();
  RETURN NEW;
END;
$$ LANGUAGE 'plpgsql';

COMMENT ON FUNCTION audit.update_mtime() IS '更新记录mtime';
---------------------------------------------------------------


---------------------------------------------------------------
-- 元数据变动事件触发器函数
-- 向'change'信道发送数据变动的表名
---------------------------------------------------------------
CREATE OR REPLACE FUNCTION audit.notify_change()
  RETURNS TRIGGER AS $$
BEGIN
  PERFORM pg_notify('change', TG_RELNAME);
  RETURN NULL;
END;
$$ LANGUAGE 'plpgsql';

COMMENT ON FUNCTION audit.notify_change() IS '数据变动事件触发器函数，向`change`信道发送数据变动的表名';
---------------------------------------------------------------

PgSQL 5分钟实现推荐系统

用PostgreSQL 5分钟实现一个最简单ItemCF推荐系统

著： 冯若航（@Vonng） | 2017-04-05

推荐系统大家都熟悉，猜你喜欢，淘宝个性化什么的，前年双十一搞了个大新闻，还拿了CEO特别贡献奖。

今天就来说说怎么用PostgreSQL 5分钟实现一个最简单ItemCF推荐系统，以推荐系统最喜闻乐见的movielens数据集为例。

原理

ItemCF的原理可以看项亮的《推荐系统实战》，不过还是稍微提一下吧，了解的直接跳过就好。

Item CF，全称Item Collaboration Filter，即基于物品的协同过滤，是目前业界应用最多的推荐算法。ItemCF不需要物品与用户的标签、属性，只要有用户对物品的行为日志就可以了，同时具有很好的可解释性。所以无论是亚马逊，Hulu，YouTube，balabala用的都是该算法。

ItemCF算法的核心思想是：给用户推荐那些和他们之前喜欢的物品相似的物品。

这里有两个要点：

用户喜欢物品怎么表示？
物品的相似度怎样表示？

用户评分表

可以通过用户评分表来判断用户对物品的喜爱程度，例如电影数据的5分制：5分表示非常喜欢，1分表示不喜欢。

用户评分表有三个核心字段：user_id, movie_id, rating，分别是用户ID，物品ID，用户对物品的评分。

怎样得到这个表呢？如果本来就是评论打分网站在做推荐系统，直接有用户对电影，音乐，小说的评分记录那是最好不过。其他的场景，比如电商，社交网络，则可以通过用户对物品的行为日志生成这张评分表。例如可以为“浏览”，“点击”，“收藏”，“购买”，点击“我不喜欢”按钮这些行为分别设一个喜好权重：0.1, 0.2, 0.3, 0.4, -100。将所有行为评分加权求和，最终得到这张用户对物品的评分表来，事就成了一半了。

物品相似度

还需要解决的一个问题是物品相似度的计算与表示。

假设一共有$N$个物品，则物品相似度数据可以表示为一个$N \times N$的矩阵，第$i$行$j$列的值表示物品$i$与物品$j$之间的相似度。这样相似度表示的问题就解决了。

第二个问题是物品相似度矩阵的计算。

但在计算前，首先必须定义，什么是物品的相似度？

两个物品之间的相似度有很多种定义与计算方式，如果我们有物品的各种属性数据(类型，大小，价格，风格，标签)的话，就可以在属性空间定义各式各样的“距离”，来定义相似度。但ItemCF的亮点就在于，不需要物品的属性标签数据也可以计算其相似度来。其核心思想是：如果一对物品被很多人同时喜欢，则认为这一对物品更为相似。

令$N(i)$为喜欢物品$i$的用户集合，$|N(i)|$为喜欢物品$i$的人数，$|N(i) \cap N(j)|$为同时喜欢物品$i,j$的人数，则物品$i,j$之间的相似度$_{ij}$可w以表示为：

$$ w_{ij} = \frac{|N(i) \cap N(j)|}{ \sqrt{ |N(i)| * |N(j)|}} $$

即：同时喜欢物品$i,j$的人数，除以喜爱物品$i$人数和喜爱物品$j$人数的几何平均数。

这样，就可以通过用户对物品的行为日志，导出一份物品之间的相似矩阵数据来。

实践

说了这么多废话，赶紧燥起来。

第一步：准备数据

下载Movielens数据集，开发测试的话选小规模的(100k)就可以。对于ItemCF来说，有用的数据就是用户行为日志，即文件ratings.csv：地址

-- movielens 用户评分数据集
CREATE TABLE mls_ratings (
  user_id   INTEGER,
  movie_id  INTEGER,
  rating    TEXT,
  timestamp INTEGER,
  PRIMARY KEY (user_id, movie_id)
);

-- 从CSV导入数据，并将评分乘以2变为2~10的整数便于处理，将Unix时间戳转换为日期类型
COPY mls_ratings FROM '/Users/vonng/Dev/recsys/ml-latest-small/ratings.csv' DELIMITER ',' CSV HEADER;
ALTER TABLE mls_ratings
  ALTER COLUMN rating SET DATA TYPE INTEGER USING (rating :: DECIMAL * 2) :: INTEGER;
ALTER TABLE mls_ratings
  ALTER COLUMN timestamp SET DATA TYPE TIMESTAMPTZ USING to_timestamp(timestamp :: DOUBLE PRECISION);

得到的数据长这样：第一列用户ID列表，第二列电影ID列表，第三列是评分，最后是时间戳。一共十万条

movielens=# select * from mls_ratings limit 10;
 user_id | movie_id | rating |       timestamp
---------+----------+--------+------------------------
       1 |       31 |      5 | 2009-12-14 10:52:24+08
       1 |     1029 |      6 | 2009-12-14 10:52:59+08
       1 |     1061 |      6 | 2009-12-14 10:53:02+08
       1 |     1129 |      4 | 2009-12-14 10:53:05+08

第二步：计算物品相似度

物品相似度的DDL

-- 物品相似度表，这是把矩阵用<i,j,M_ij>的方式在数据库中表示。
CREATE TABLE mls_similarity (
  i INTEGER,
  j INTEGER,
  p FLOAT,
  PRIMARY KEY (i, j)
);

物品相似度是一个矩阵，虽说PostgreSQL里提供了数组，多维数组，自定义数据结构，不过这里为了方便起见还是使用了最传统的矩阵表示方法：坐标索引法$(i,j,m_{ij})$。其中前两个元素为矩阵下标，各自表示物品的ID。最后一个元素存储了这一对物品的相似度。

物品相似度的计算

计算物品相似度，要计算两个中间数据：

每个物品被用户喜欢的次数：$|N(i)|$
每对物品共同被同一个用户喜欢的次数 $|N(i) \cap N(j)|$

如果是用编程语言，那自然可以一趟(One-Pass)解决两个问题。不过SQL就要稍微麻烦点了，好处是不用操心撑爆内存的问题。

这里可以使用PostgreSQL的With子句功能，计算两个临时结果供后续使用，一条SQL就搞定相似矩阵计算：

-- 计算物品相似度矩阵: 3m 53s
WITH mls_occur AS ( -- 中间表：计算每个电影被用户看过的次数
    SELECT
      movie_id,     -- 电影ID: i
      count(*) AS n -- 看过电影i的人数: |N(i)|
    FROM mls_ratings
    GROUP BY movie_id
),
    mls_common AS ( -- 中间表：计算每对电影被用户同时看过的次数
      SELECT
        a.movie_id AS i, -- 电影ID: i
        b.movie_id AS j, -- 电影ID: j
        count(*)   AS n  -- 同时看过电影i和j的人数: |N(i) ∩ N(j)|
      FROM mls_ratings a INNER JOIN mls_ratings b ON a.user_id = b.user_id
      GROUP BY i, j
  )
INSERT INTO mls_similarity
  SELECT
    i,
    j,
    n / sqrt(n1 * n2) AS p  -- 距离公式
  FROM
    mls_common c,
    LATERAL (SELECT n AS n1 FROM mls_occur WHERE movie_id = i) n1,
    LATERAL (SELECT n AS n2 FROM mls_occur WHERE movie_id = j) n2;

物品相似度表大概长这样：

movielens=# SELECT * FROM mls_similarity LIMIT 10;
   i    | j |         p
--------+---+--------------------
 140267 | 1 |  0.110207753755597
   2707 | 1 |  0.180280682843137
 140174 | 1 |  0.113822078644894
   7482 | 1 | 0.0636284762975778

实际上还可以修剪修剪，比如计算时非常小的相似度干脆可以直接删掉。也可以用整个表中相似度的最大值作为单位1，进行归一化。这里都不弄了。

第三步：进行推荐！

现在假设我们为ID为10的用户推荐10部他没看过的电影，该怎么做呢？

WITH seed AS	-- 10号用户评分过的影片作为种子集合
  (SELECT movie_id,rating FROM mls_ratings WHERE user_id = 10)
SELECT
  j as movie_id,	-- 所有待预测评分的电影ID
  sum(seed.rating * p) AS score -- 预测加权分，按此字段降序排序取TopN
FROM
  seed LEFT JOIN mls_similarity s ON seed.movie_id = s.i 
  WHERE j not in (SELECT DISTINCT movie_id FROM seed) -- 去除已经看过的电影(可选)
GROUP BY j ORDER BY score DESC LIMIT 10; -- 聚合，排序，取TOP

推荐结果如下：

 movie_id |      score
----------+------------------
     1270 | 121.487735902517
     1214 | 116.146138947698
     1580 | 116.015331936539
     2797 | 115.144083402858
     1265 | 114.959033115913
      260 | 114.313571128143
     2716 | 113.087151014987
     1097 |  113.07771922959
     1387 | 112.869891345883
     2916 |  112.84326997566

可以进一步包装一下，把它变成一个存储过程get_recommendation

CREATE OR REPLACE FUNCTION get_recommendation(userid INTEGER)
  RETURNS JSONB AS $$ BEGIN
  RETURN (SELECT jsonb_agg(movie_id)
          FROM (WITH seed AS
          (SELECT movie_id,rating FROM mls_ratings WHERE user_id = userid)
                SELECT
                  j as movie_id,
                  sum(seed.rating * p) AS score
                FROM
                  seed LEFT JOIN mls_similarity s ON seed.movie_id = s.i
                WHERE j not in (SELECT DISTINCT movie_id FROM seed)
                GROUP BY j ORDER BY score DESC LIMIT 10) res);
END $$ LANGUAGE plpgsql STABLE;

这样用起来更方便啦，同时也可以在这里加入一些其他的处理逻辑：比如过滤掉禁片黄片，去除用户明确表示过不喜欢的电影，加入一些热门电影，引入一些随机惊喜，打点小广告之类的。

movielens=# SELECT get_recommendation(11) as res;
                                  res
-----------------------------------------------------------------------
 [80489, 96079, 79132, 59315, 91529, 69122, 58559, 59369, 1682, 71535]

最后写个应用把这个存储过程作为OpenAPI开放出去，事就这样成了。

关于这一步可以参考前一篇：当PostgreSQL遇上GraphQL：Postgraphql中的做法，直接由存储过程生成GraphQL API，啥都不用操心了。

What’s more

几行SQL一条龙执行下来，加上下载数据的时间，总共也就五分钟吧。一个简单的推荐系统就这样搭建起来了。

但一个真正的生产系统还需要考虑许许多多其他问题，例如，性能。

这里比如说计算相似度矩阵的时候，才100k条记录花了三四分钟，不太给力。而且这么多SQL写起来，管理起来也麻烦，有没有更好的方案？

这儿有个基于PostgreSQL源码魔改的推荐数据库：RecDB，直接用C实现了推荐系统相关的功能扩展，性能看起来杠杠地；同时还包装了SQL语法糖，一行SQL建立推荐系统！再一行SQL就开始使用啦。

-- 计算推荐所需的信息
CREATE RECOMMENDER MovieRec ON ml_ratings
USERS FROM userid
ITEMS FROM itemid
EVENTS FROM ratingval
USING ItemCosCF

-- 进行推荐！
SELECT * FROM ml_ratings R
RECOMMEND R.itemid TO R.userid ON R.ratingval USING ItemCosCF
WHERE R.userid = 1
ORDER BY R.ratingval
LIMIT 10

PostgreSQL能干的事情太多了，最先进的开源关系数据库确实不是吹的，其实真的可以试一试。

UUID性质原理与应用

UUID性质原理与应用，以及如何利用PostgreSQL的存储过程操作UUID。

著： 冯若航（@Vonng） | 2016-11-06

最近一个项目需要生成业务流水号，需求如下：

ID必须是分布式生成的，不能依赖中心节点分配并保证全局唯一。
ID必须包含时间戳并尽量依时序递增。（方便阅读，提高索引效率）
ID尽量散列。（分片，与HBase日志存储需要）

在造轮子之前，首先要看一下有没有现成的解决方案。

Serial

传统实践上业务流水号经常通过数据库自增序列或者发码服务来实现。 MySQL的Auto Increment,Postgres的Serial,或者Redis+lua写个小发码服务都是方便快捷的解决方案。这种方案可以保证全局唯一，但会出现中心节点依赖：每个节点需要访问一次数据库才能拿到序列号。这就产生了可用性问题：如果能在本地生成流水号并直接返回响应，那为什么非要用一次网络访问拿ID呢？如果数据库挂了，节点也GG了。所以这并不是一个理想的方案。

SnowflakeID

然后就是twitter的SnowflakeID了，SnowflakeID是一个BIGINT，第一位不用，41bit的时间戳，10bit的节点ID，12bit的毫秒内序列号。时间戳，工作机器ID，序列号占用的位域长度是可以根据业务需求不同而变化的。

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |x|                    41-bit timestamp                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       timestamp   |10-bit machine node|    12-bit serial      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

SnowflakeID可以说基本满足了这四个需求，首先，通过不同的时间戳(精确到毫秒)，节点ID(工作机器ID)，以及毫秒内的序列号，某种意义上确实可以做到唯一。一个比较讨喜的特性是所有ID是依时序递增的，所以索引起来或者拉取数据会非常方便，长整形的索引和存储效率也很高，生成效率也没得说。

但我认为SnowflakeId存在两个致命问题：

虽然ID生成不需要中心节点分配，但工作机器ID还是需要手工分配或者提供中心节点协调的，本质上是改善而不是解决问题。
无法解决时间回溯的问题，一旦服务器时间发生调整，几乎一定会生成出重复ID。

UUID (Universally Unique IDentifier)

其实这种问题早就有经典的解决方案了，譬如：UUID by RFC 4122 。著名的IDFA就是一种UUID

UUID是一种格式，共有5个版本，最后我选择了v1作为最终方案。下面详细简单介绍一下UUID v1的性质。

可以分布式本地生成。
保证全局唯一，且可以应对时间回溯或网卡变化导致ID重复生成的问题。
时间戳(60bit)，精确至0.1微秒(1e-7 s)。蕴含在ID中。
在一个连续的时间片段(2^32/1e7 s约7min)内，ID单调递增。
连续生成的ID会被均匀散列，（所以分片起来不要太方便，放在HBase里也可以直接当Rowkey）
有现成的标准，不需要任何事先配置与参数输入，各个语言均有实现，开箱即用。
可以直接通过UUID字面值得知大概的业务时间戳。
PostgreSQL直接内建UUID支持(ver>9.0)。

综合考虑，这确实是我能找到的最完美的解决方案了。

UUID概览

# Shell中生成一个随机UUID的简单方式
$ python -c 'import uuid;print(uuid.uuid4())'
8d6d1986-5ab8-41eb-8e9f-3ae007836a71

我们通常见到的UUID如上所示，通常用'-'分隔的五组十六进制数字表示。但这个字符串只不过是UUID的字符串表示，即所谓的UUID Literal。实际上UUID是一个128bit的整数。也就是16个字节，两个长整形的宽度。

因为每个字节用2个hex字符表示，所以UUID通常可以表示为32个十六进制数字，按照8-4-4-4-12的形式进行分组。为什么采用这种分组形式？因为最原始版本的UUID v1采用了这种位域划分方式，后面其他版本的UUID虽然可能位域划分跟这个结构已经不同了，依然采用此种字面值表示方法。UUID1是最经典的UUID，所以我着重介绍UUID1。

下面是UUID版本1的位域划分：

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          time_low                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       time_mid                |         time_hi_and_version   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |clk_seq_hi_res |  clk_seq_low  |         node (0-1)            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         node (2-5)                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   
 typedef struct {
    unsigned32  time_low;
    unsigned16  time_mid;
    unsigned16  time_hi_and_version;
    unsigned8   clock_seq_hi_and_reserved;
    unsigned8   clock_seq_low;
    byte        node[6];
} uuid_t;

但位域划分是按照C结构体的表示方便来划分的，从逻辑上UUID1包括五个部分：

时间戳 :time_low(32), time_mid(16),time_high(12)，共60bit。
UUID版本:version(4)
UUID类型: variant(2)
时钟序列:clock_seq(14)
节点: node(48)，UUID1中为MAC地址。

这五个部分实际占用的位域如下图所示：

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          time_low                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       time_mid                |  ver  |      time_high        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |var|       clock_seq           |         node (0-1)            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         node (2-5)                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

在UUID中：

version固定等于0b0001,即版本号固定为1。

反应在字面值上就是：一个合法的UUID v1第三个分组的第一个hex一定是1:
- 6b54058a-a413-11e6-b501-a0999b048337
当然，如果这个值是2,3,4,5，也代表着这就是一个版本2,3,4,5的UUID。
varient是用来和其他类型UUID(如GUID)进行区分的字段，指明了UUID的位域解释方法。这里固定为0b10。

反应在字面值上，一个合法的UUID v1第四个分组的第一个hex一定是8,9,A,B之一：
- 6b54058a-a413-11e6-b501-a0999b048337
timestamp由系统时钟获得，形式为60bit的整数，内容是：Coordinated Universal Time (UTC) as a count of 100- nanosecond intervals since 00:00:00.00, 15 October 1582 (the date of Gregorian reform to the Christian calendar).

即从1582/10/15 00:00:00至今经过的百纳秒数（100 ns= 1e-7 s）。这么蛋疼的设计是为了让产生良好的散列，让输出ID分布的熵最大化。

将unix timestamp换算为所需时间戳的公式为:ts * 10000000 + 122192928000000000

time_low = (long long)timestamp [32:64) ，将时间戳的最低位的32bit按照同样的顺序填入UUID前32bit

time_mid = (long long)timestamp [16:32) ，将时间戳中间的16bit按照同样的顺序填入UUID的time_mid

time_high = (long long)timestamp [4:16) ，将时间戳的最高的12bit按照同样的顺序生成time_hi。

不过time_hi和version是共享一个short int的，所以其生成方法为：

time_hi_and_version = (long long)timestamp[0:16) & 0x0111 | 0x1000
clock_seq是为了防止网卡变更与时间回溯导致的ID重复问题，当系统时间回溯或网卡状态变更时，clock_seq会自动重置，从而避免ID重复问题。其形式为14个bit，换算成整数即0~16383，一般的UUID库都会自动处理，不在乎的话也可以随机生成或者设为固定值提高性能。
node字段在UUID1中的涵义等同于机器网卡MAC。48bit正好与MAC地址等长。一般UUID库会自动获取，但因为MAC地址泄露出去可能会有一些安全隐患，所以也有一些库是按照IP地址生成的，或者因为拿不到MAC就用一些系统指纹来生成，总之也不用操心。

所以，其实UUIDv1的所有字段都可以自动获取，压根不用人操心。其实是很方便的。

阅读UUID v1时也有一些经验和技巧。

UUID的第一个分组位域宽度为32bit，以百纳秒表示时间的话，也就是(2 ^ 32 / 1e7 s = 429.5 s = 7.1 min)。即每7分钟，第一个分组经历一次重置循环。所以对于随机到达的请求，生成的ID哈希分布应该是很均匀的。

UUID的第二个分组位域宽度为16bit，也就是2^48 / 1e7 s = 326 Day，也就是说，第二个分组基本上每年循环一次。可以近似的看做年内的业务日期。

当然，最靠谱的方法还是用程序直接从UUID v1中提取出时间戳来。这也是非常方便的。

一些问题

前几天需要合并老的业务日志，老的系统里面日志压根没有流水号这个概念，这就让人蛋疼了。新老日志合并需要为老日志补充生成业务流水ID。

UUID v1生成起来是非常方便的，但要手工构造一个UUID去补数据就比较蛋疼了。我在中英文互联网,StackOverflow找了很久都没发现现成的python,Node,Go,pl/pgsql库或者函数能完成这个功能，这些包大抵就是提供一个uuid.v1()给外面用，压根没想到还会有回溯生成ID这种功能吧……

所以我自己写了一个pl/pgsql的存储过程，可以根据业务时间戳和当初工作机器的MAC重新生成UUID1。编写这个函数让我对UUID的实现细节与原理有了更深的了解，还是不错的。

根据时间戳，时钟序列(非必须)，MAC生成UUID的存储过程，其他语言同理：

-- Build UUIDv1 via RFC 4122. 
-- clock_seq is a random 14bit unsigned int with range [0,16384)
CREATE OR REPLACE FUNCTION form_uuid_v1(ts TIMESTAMPTZ, clock_seq INTEGER, mac MACADDR)
  RETURNS UUID AS $$
DECLARE
  t       BIT(60) := (extract(EPOCH FROM ts) * 10000000 + 122192928000000000) :: BIGINT :: BIT(60);
  uuid_hi BIT(64) := substring(t FROM 29 FOR 32) || substring(t FROM 13 FOR 16) || b'0001' ||
                     substring(t FROM 1 FOR 12);
BEGIN
  RETURN lpad(to_hex(uuid_hi :: BIGINT) :: TEXT, 16, '0') ||
         (to_hex((b'10' || clock_seq :: BIT(14)) :: BIT(16) :: INTEGER)) :: TEXT ||
         replace(mac :: TEXT, ':', '');
END
$$ LANGUAGE plpgsql;

-- Usage: SELECT form_uuid_v1(time, 666, '44:88:99:36:57:32');

从UUID1中提取时间戳的存储过程

CREATE OR REPLACE FUNCTION uuid_v1_timestamp(_uuid UUID)
  RETURNS TIMESTAMP WITH TIME ZONE AS $$
SELECT to_timestamp(
    (
      ('x' || lpad(h, 16, '0')) :: BIT(64) :: BIGINT :: DOUBLE PRECISION -
      122192928000000000
    ) / 10000000
)
FROM (
       SELECT substring(u FROM 16 FOR 3) ||
              substring(u FROM 10 FOR 4) ||
              substring(u FROM 1 FOR 8) AS h
       FROM (VALUES (_uuid :: TEXT)) s (u)
     ) s;
$$ LANGUAGE SQL IMMUTABLE;

管理

关于PostgreSQL管理运维的经验文章

Postgres逻辑复制详解

本文介绍PostgreSQL 13中逻辑复制的相关原理，以及最佳实践。

2021-03-03

逻辑复制

逻辑复制（Logical Replication），是一种根据数据对象的 复制标识（Replica Identity）（通常是主键）复制数据对象及其变化的方法。

逻辑复制 这个术语与 物理复制相对应，物理复制使用精确的块地址与逐字节复制，而逻辑复制则允许对复制过程进行精细的控制。

逻辑复制基于 发布（Publication） 与订阅（Subscription）模型：

一个 发布者（Publisher） 上可以有多个发布，一个 订阅者（Subscriber） 上可以有多个订阅。
一个发布可被多个订阅者订阅，一个订阅只能订阅一个发布者，但可订阅同发布者上的多个不同发布。

针对一张表的逻辑复制通常是这样的：订阅者获取发布者数据库上的一个快照，并拷贝表中的存量数据。一旦完成数据拷贝，发布者上的变更（增删改清）就会实时发送到订阅者上。订阅者会按照相同的顺序应用这些变更，因此可以保证逻辑复制的事务一致性。这种方式有时候又称为 事务性复制（transactional replication）。

逻辑复制的典型用途是：

迁移，跨PostgreSQL大版本，跨操作系统平台进行复制。
CDC，收集数据库（或数据库的一个子集）中的增量变更，在订阅者上为增量变更触发触发器执行定制逻辑。
分拆，将多个数据库集成为一个，或者将一个数据库拆分为多个，进行精细的分拆集成与访问控制。

逻辑订阅者的行为就是一个普通的PostgreSQL实例（主库），逻辑订阅者也可以创建自己的发布，拥有自己的订阅者。

如果逻辑订阅者只读，那么不会有冲突。如果会写入逻辑订阅者的订阅集，那么就可能会出现冲突。

发布（Publication）

一个 发布（Publication） 可以在物理复制主库上定义。创建发布的节点被称为 发布者（Publisher） 。

一个发布是 由一组表构成的变更集合。也可以被视作一个 变更集（change set） 或 复制集（Replication Set） 。每个发布都只能在一个 数据库（Database） 中存在。

发布不同于模式（Schema），不会影响表的访问方式。（表纳不纳入发布，自身访问不受影响）

发布目前只能包含表（即：索引，序列号，物化视图这些不会被发布），每个表可以添加到多个发布中。

除非针对ALL TABLES创建发布，否则发布中的对象（表）只能（通过ALTER PUBLICATION ADD TABLE）被显式添加。

发布可以筛选所需的变更类型：包括INSERT、UPDATE、DELETE 和TRUNCATE的任意组合，类似触发器事件，默认所有变更都会被发布。

复制标识

一个被纳入发布中的表，必须带有 复制标识（Replica Identity），只有这样才可以在订阅者一侧定位到需要更新的行，完成UPDATE与DELETE操作的复制。

默认情况下，主键（Primary Key）是表的复制标识，非空列上的唯一索引 （UNIQUE NOT NULL）也可以用作复制标识。

如果没有任何复制标识，可以将复制标识设置为FULL，也就是把整个行当作复制标识。（一种有趣的情况，表中存在多条完全相同的记录，也可以被正确处理，见后续案例）使用FULL模式的复制标识效率很低（因为每一行修改都需要在订阅者上执行全表扫描，很容易把订阅者拖垮），所以这种配置只能是保底方案。使用FULL模式的复制标识还有一个限制，订阅端的表上的复制身份所包含的列，要么与发布者一致，要么比发布者更少。

INSERT操作总是可以无视复制标识直接进行（因为插入一条新记录，在订阅者上并不需要定位任何现有记录；而删除和更新则需要通过复制标识 定位到需要操作的记录）。如果一个没有复制标识的表被加入到带有UPDATE和DELETE的发布中，后续的UPDATE和DELETE会导致发布者上报错。

表的复制标识模式可以查阅pg_class.relreplident获取，可以通过ALTER TABLE进行修改。

ALTER TABLE tbl REPLICA IDENTITY 
{ DEFAULT | USING INDEX index_name | FULL | NOTHING };

尽管各种排列组合都是可能的，然而在实际使用中，只有三种可行的情况。

表上有主键，使用默认的 default 复制标识
表上没有主键，但是有非空唯一索引，显式配置 index 复制标识
表上既没有主键，也没有非空唯一索引，显式配置full复制标识（运行效率非常低，仅能作为兜底方案）
其他所有情况，都无法正常完成逻辑复制功能。输出的信息不足，可能会报错，也可能不会。
特别需要注意：如果nothing复制标识的表纳入到逻辑复制中，对其进行删改会导致发布端报错！

复制身份模式\表上的约束	主键(p)	非空唯一索引(u)	两者皆无(n)
default	有效	x	x
index	x	有效	x
full	低效	低效	低效
nothing	xxxx	xxxx	xxxx

管理发布

CREATE PUBLICATION用于创建发布，DROP PUBLICATION用于移除发布，ALTER PUBLICATION用于修改发布。

发布创建之后，可以通过ALTER PUBLICATION动态地向发布中添加或移除表，这些操作都是事务性的。

CREATE PUBLICATION name
    [ FOR TABLE [ ONLY ] table_name [ * ] [, ...]
      | FOR ALL TABLES ]
    [ WITH ( publication_parameter [= value] [, ... ] ) ]

ALTER PUBLICATION name ADD TABLE [ ONLY ] table_name [ * ] [, ...]
ALTER PUBLICATION name SET TABLE [ ONLY ] table_name [ * ] [, ...]
ALTER PUBLICATION name DROP TABLE [ ONLY ] table_name [ * ] [, ...]
ALTER PUBLICATION name SET ( publication_parameter [= value] [, ... ] )
ALTER PUBLICATION name OWNER TO { new_owner | CURRENT_USER | SESSION_USER }
ALTER PUBLICATION name RENAME TO new_name

DROP PUBLICATION [ IF EXISTS ] name [, ...];

publication_parameter 主要包括两个选项：

publish：定义要发布的变更操作类型，逗号分隔的字符串，默认为insert, update, delete, truncate。
publish_via_partition_root：13后的新选项，如果为真，分区表将使用根分区的复制标识进行逻辑复制。

查询发布

发布可以使用psql元命令\dRp查询。

# \dRp
  Owner   | All tables | Inserts | Updates | Deletes | Truncates | Via root
----------+------------+---------+---------+---------+-----------+----------
 postgres | t          | t       | t       | t       | t         | f

`pg_publication` 发布定义表

``pg_publication` 包含了发布的原始定义，每一条记录对应一个发布。

# table pg_publication;
oid          | 20453
pubname      | pg_meta_pub
pubowner     | 10
puballtables | t
pubinsert    | t
pubupdate    | t
pubdelete    | t
pubtruncate  | t
pubviaroot   | f

puballtables：是否包含所有的表
pubinsert|update|delete|truncate 是否发布这些操作
pubviaroot：如果设置了该选项，任何分区表（叶表）都会使用最顶层的（被）分区表的复制身份。所以可以把整个分区表当成一个表，而不是一系列表进行发布。

`pg_publication_tables` 发布内容表

pg_publication_tables是由pg_publication，pg_class和pg_namespace拼合而成的视图，记录了发布中包含的表信息。

postgres@meta:5432/meta=# table pg_publication_tables;
   pubname   | schemaname |    tablename
-------------+------------+-----------------
 pg_meta_pub | public     | spatial_ref_sys
 pg_meta_pub | public     | t_normal
 pg_meta_pub | public     | t_unique
 pg_meta_pub | public     | t_tricky

使用pg_get_publication_tables可以根据订阅的名字获取订阅表的OID

SELECT * FROM pg_get_publication_tables('pg_meta_pub');
SELECT p.pubname,
       n.nspname AS schemaname,
       c.relname AS tablename
FROM pg_publication p,
     LATERAL pg_get_publication_tables(p.pubname::text) gpt(relid),
     pg_class c
         JOIN pg_namespace n ON n.oid = c.relnamespace
WHERE c.oid = gpt.relid;

同时，pg_publication_rel 也提供类似的信息，但采用的是多对多的OID对应视角，包含的是原始数据。

  oid  | prpubid | prrelid
-------+---------+---------
 20414 |   20413 |   20397
 20415 |   20413 |   20400
 20416 |   20413 |   20391
 20417 |   20413 |   20394

这两者的区别特别需要注意：当针对ALL TABLES发布时，pg_publication_rel中不会有具体表的OID，但是在pg_publication_tables中可以查询到实际纳入逻辑复制的表列表。所以通常应当以pg_publication_tables为准。

创建订阅时，数据库会先修改pg_publication目录，然后将发布表的信息填入pg_publication_rel。

发布与订阅端的表的列也是通过名称匹配的。列的顺序无关紧要，数据类型也不一定非得一致，只要两个列的文本表示兼容即可，即数据的文本表示可以转换为目标列的类型。订阅端的表可以包含有发布端没有的列，这些新列都会使用默认值填充。

管理订阅

CREATE SUBSCRIPTION用于创建订阅，DROP SUBSCRIPTION用于移除订阅，ALTER SUBSCRIPTION用于修改订阅。

订阅创建之后，可以通过ALTER SUBSCRIPTION 随时暂停与恢复订阅。

移除并重建订阅会导致同步信息丢失，这意味着相关数据需要重新进行同步。

CREATE SUBSCRIPTION subscription_name
    CONNECTION 'conninfo'
    PUBLICATION publication_name [, ...]
    [ WITH ( subscription_parameter [= value] [, ... ] ) ]

ALTER SUBSCRIPTION name CONNECTION 'conninfo'
ALTER SUBSCRIPTION name SET PUBLICATION publication_name [, ...] [ WITH ( set_publication_option [= value] [, ... ] ) ]
ALTER SUBSCRIPTION name REFRESH PUBLICATION [ WITH ( refresh_option [= value] [, ... ] ) ]
ALTER SUBSCRIPTION name ENABLE
ALTER SUBSCRIPTION name DISABLE
ALTER SUBSCRIPTION name SET ( subscription_parameter [= value] [, ... ] )
ALTER SUBSCRIPTION name OWNER TO { new_owner | CURRENT_USER | SESSION_USER }
ALTER SUBSCRIPTION name RENAME TO new_name

DROP SUBSCRIPTION [ IF EXISTS ] name;

subscription_parameter定义了订阅的一些选项，包括：

copy_data(bool)：复制开始后，是否拷贝数据，默认为真
create_slot(bool)：是否在发布者上创建复制槽，默认为真
enabled(bool)：是否启用该订阅，默认为真
connect(bool)：是否尝试连接到发布者，默认为真，置为假会把上面几个选项强制设置为假。
synchronous_commit(bool)：是否启用同步提交，向主库上报自己的进度信息。
slot_name：订阅所关联的复制槽名称，设置为空会取消订阅与复制槽的关联。

管理复制槽

每个活跃的订阅都会通过复制槽 从远程发布者接受变更。

通常这个远端的复制槽是自动管理的，在CREATE SUBSCRIPTION时自动创建，在DROP SUBSCRIPTION时自动删除。

在特定场景下，可能需要分别操作订阅与底层的复制槽：

创建订阅时，所需的复制槽已经存在。则可以通过create_slot = false关联已有复制槽。
创建订阅时，远端不可达或状态不明朗，则可以通过connect = false不访问远程主机，pg_dump就是这么做的。这种情况下，您必须在远端手工创建复制槽后，才能在本地启用该订阅。
移除订阅时，需要保留复制槽。这种情况通常是订阅者要搬到另一台机器上去，希望在那里重新开始订阅。这种情况下需要先通过ALTER SUBSCRIPTION解除订阅与复制槽点关联
移除订阅时，远端不可达。这种情况下，需要在删除订阅之前使用ALTER SUBSCRIPTION解除复制槽与订阅的关联。

如果远端实例不再使用那么没事，然而如果远端实例只是暂时不可达，那就应该手动删除其上的复制槽；否则它将继续保留WAL，并可能导致磁盘撑爆。

订阅查询

订阅可以使用psql元命令\dRs查询。

# \dRs
     Name     |  Owner   | Enabled |  Publication
--------------+----------+---------+----------------
 pg_bench_sub | postgres | t       | {pg_bench_pub}

`pg_subscription` 订阅定义表

每一个逻辑订阅都会有一条记录，注意这个视图是跨数据库集簇范畴的，每个数据库中都可以看到整个集簇中的订阅信息。

只有超级用户才可以访问此视图，因为里面包含有明文密码（连接信息）。

oid             | 20421
subdbid         | 19356
subname         | pg_test_sub
subowner        | 10
subenabled      | t
subconninfo     | host=10.10.10.10 user=replicator password=DBUser.Replicator dbname=meta
subslotname     | pg_test_sub
subsynccommit   | off
subpublications | {pg_meta_pub}

subenabled：订阅是否启用
subconninfo ：因为包含敏感信息，会针对普通用户进行隐藏。
subslotname：订阅使用的复制槽名称，也会被用作逻辑复制的源名称（Origin Name），用于除重。
subpublications：订阅的发布名称列表。
其他状态信息：是否启用同步提交等等。

`pg_subscription_rel` 订阅内容表

pg_subscription_rel 记录了每张处于订阅中的表的相关信息，包括状态与进度。

srrelid 订阅中关系的OID
srsubstate，订阅中关系的状态：i 初始化中，d 拷贝数据中，s 同步已完成，r 正常复制中。
srsublsn，当处于i|d状态时为空，当处于s|r状态时，远端的LSN位置。

创建订阅时

当一个新的订阅创建时，会依次执行以下操作：

将发布的信息存入 pg_subscription 目录中，包括连接信息，复制槽，发布名称，一些配置选项等。
连接至发布者，检查复制权限，（注意这里不会检查对应发布是否存在），
创建逻辑复制槽：pg_create_logical_replication_slot(name, 'pgoutput')
将复制集中的表注册到订阅端的 pg_subscription_rel 目录中。
执行初始快照同步，注意订阅测表中的原有数据不会被删除。

复制冲突

逻辑复制的行为类似于正常的DML操作，即使数据在用户节点上的本地发生了变化，数据也会被更新。如果复制来的数据违反了任何约束，复制就会停止，这种现象被称为 冲突（Conflict） 。

当复制UPDATE或DELETE操作时，缺失数据（即要更新/删除的数据已经不存在）不会产生冲突，此类操作直接跳过。

冲突会导致错误，并中止逻辑复制，逻辑复制管理进程会以5秒为间隔不断重试。冲突不会阻塞订阅端对复制集中表上的SQL。关于冲突的细节可以在用户的服务器日志中找到，冲突必须由用户手动解决。

日志中可能出现的冲突

冲突模式	复制进程	输出日志
缺少UPDATE/DELETE对象	继续	不输出
表/行锁等待	等待	不输出
违背主键/唯一/Check约束	中止	输出
目标表不存在/目标列不存在	中止	输出
无法将数据转换为目标列类型	中止	输出

解决冲突的方法，可以是改变订阅侧的数据，使其不与进入的变更相冲突，或者跳过与现有数据冲突的事务。

使用订阅对应的node_name与LSN位置调用函数pg_replication_origin_advance()可以跳过事务，pg_replication_origin_status系统视图中可以看到当前ORIGIN的位置。

局限性

逻辑复制目前有以下限制，或者说功能缺失。这些问题可能会在未来的版本中解决。

数据库模式和DDL命令不会被复制。存量模式可以通过pg_dump --schema-only手动复制，增量模式变更需要手动保持同步（发布订阅两边的模式不需要绝对相同不需要两边的模式绝对相同)。逻辑复制对于对在线DDL变更仍然可靠：在发布数据库中执行DDL变更后，复制的数据到达订阅者但因为表模式不匹配而导致复制出错停止，订阅者的模式更新后复制会继续。在许多情况下，先在订阅者上执行变更可以避免中间的错误。

序列号数据不会被复制。序列号所服务的标识列与SERIAL类型里面的数据作为表的一部分当然会被复制，但序列号本身仍会在订阅者上保持为初始值。如果订阅者被当成只读库使用，那么通常没事。然而如果打算进行某种形式的切换或Failover到订阅者数据库，那么需要将序列号更新为最新的值，要么通过从发布者复制当前数据（也许可以使用pg_dump -t *seq*），要么从表本身的数据内容确定一个足够高的值（例如max(id)+1000000）。否则如果在新库执行获取序列号作为身份的操作时，很可能会产生冲突。

逻辑复制支持复制TRUNCATE命令，但是在TRUNCATE由外键关联的一组表时需要特别小心。当执行TRUNCATE操作时，发布者上与之关联的一组表（通过显式列举或级连关联）都会被TRUNCATE，但是在订阅者上，不在订阅集中的表不会被TRUNCATE。这样的操作在逻辑上是合理的，因为逻辑复制不应该影响到复制集之外的表。但如果有一些不在订阅集中的表通过外键引用订阅集中被TRUNCATE的表，那么TRUNCATE操作就会失败。

大对象不会被复制

只有表能被复制（包括分区表），尝试复制其他类型的表会导致错误（视图，物化视图，外部表，Unlogged表）。具体来说，只有在pg_class.relkind = 'r'的表才可以参与逻辑复制。

复制分区表时默认按子表进行复制。默认情况下，变更是按照分区表的叶子分区触发的，这意味着发布上的每一个分区子表都需要在订阅上存在（当然，订阅者上的这个分区子表不一定是一个分区子表，也可能本身就是一个分区母表，或者一个普通表）。发布可以声明要不要使用分区根表上的复制标识取代分区叶表上的复制标识，这是PG13提供的新功能，可以在创建发布时通过publish_via_partition_root 选项指定。

触发器的行为表现有所不同。行级触发器会触发，但UPDATE OF cols类型的触发器不触发。而语句级触发器只会在初始数据拷贝时触发。

日志行为不同。即使设置log_statement = 'all'，日志中也不会记录由复制产生的SQL语句。

双向复制需要极其小心：互为发布与订阅是可行的，只要两遍的表集合不相交即可。但一旦出现表的交集，就会出现WAL无限循环。

同一实例内的复制：同一个实例内的逻辑复制需要特别小心，必须手工创建逻辑复制槽，并在创建订阅时使用已有的逻辑复制槽，否则会卡死。

只能在主库上进行：目前不支持从物理复制的从库上进行逻辑解码，也无法在从库上创建复制槽，所以从库无法作为发布者。但这个问题可能会在未来解决。

架构

逻辑复制始于获取发布者数据库上的快照，基于此快照拷贝表上的存量数据。一旦拷贝完成，发布者上的变更（增删改等）就会实时发送到订阅者上。

逻辑复制采用与物理复制类似的架构，是通过一个walsender和apply进程实现的。发布端端walsender进程会加载逻辑解码插件（pgoutput），并开始逻辑解码WAL日志。逻辑解码插件（Logical Decoding Plugin） 会读取WAL中的变更，按照发布的定义筛选变更，将变更转变为特定的形式，以逻辑复制协议传输出去。数据会按照流复制协议传输至订阅者一侧的apply进程，该进程会在接收到变更时，将变更映射至本地表上，然后按照事务顺序重新应用这些变更。

初始快照

订阅侧的表在初始化与拷贝数据期间，会由一种特殊的apply进程负责。这个进程会创建它自己的临时复制槽，并拷贝表中的存量数据。

一旦数据拷贝完成，这张表会进入到同步模式（pg_subscription_rel.srsubstate = 's'），同步模式确保了 主apply进程 可以使用标准的逻辑复制方式应用拷贝数据期间发生的变更。一旦完成同步，表复制的控制权会转交回 主apply进程，恢复正常的复制模式。

进程结构

逻辑复制的发布端会针对来自订阅端端每一条连接，创建一个对应的 walsender 进程，发送解码的WAL日志。在订阅测，则会

复制槽

当创建订阅时，

一条逻辑复制

逻辑解码

同步提交

逻辑复制的同步提交是通过Backend与Walsender之间的SIGUSR1通信完成的。

临时数据

逻辑解码的临时数据会落盘为本地日志快照。当walsender接收到walwriter发送的SIGUSR1信号时，就会读取WAL日志并生成相应的逻辑解码快照。当传输结束时会删除这些快照。

文件地址为：$PGDATA/pg_logical/snapshots/{LSN Upper}-{LSN Lower}.snap

监控

逻辑复制采用与物理流复制类似的架构，所以监控一个逻辑复制的发布者节点与监控一个物理复制主库差别不大。

订阅者的监控信息可以通过pg_stat_subscription视图获取。

`pg_stat_subscription` 订阅统计表

每个活跃订阅都会在这个视图中有至少一条 记录，即Main Worker（负责应用逻辑日志）。

Main Worker的relid = NULL，如果有负责初始数据拷贝的进程，也会在这里有一行记录，relid为负责拷贝数据的表。

subid                 | 20421
subname               | pg_test_sub
pid                   | 5261
relid                 | NULL
received_lsn          | 0/2A4F6B8
last_msg_send_time    | 2021-02-22 17:05:06.578574+08
last_msg_receipt_time | 2021-02-22 17:05:06.583326+08
latest_end_lsn        | 0/2A4F6B8
latest_end_time       | 2021-02-22 17:05:06.578574+08

received_lsn ：最近收到的日志位置。
lastest_end_lsn：最后向walsender回报的LSN位置，即主库上的confirmed_flush_lsn。不过这个值更新不太勤快，

通常情况下一个活跃的订阅会有一个apply进程在运行，被禁用的订阅或崩溃的订阅则在此视图中没有记录。在初始同步期间，被同步的表会有额外的工作进程记录。

`pg_replication_slot` 复制槽

postgres@meta:5432/meta=# table pg_replication_slots ;
-[ RECORD 1 ]-------+------------
slot_name           | pg_test_sub
plugin              | pgoutput
slot_type           | logical
datoid              | 19355
database            | meta
temporary           | f
active              | t
active_pid          | 89367
xmin                | NULL
catalog_xmin        | 1524
restart_lsn         | 0/2A08D40
confirmed_flush_lsn | 0/2A097F8
wal_status          | reserved
safe_wal_size       | NULL

复制槽视图中同时包含了逻辑复制槽与物理复制槽。逻辑复制槽点主要特点是：

plugin字段不为空，标识了使用的逻辑解码插件，逻辑复制默认使用pgoutput插件。
slot_type = logical，物理复制的槽类型为physical。
datoid与database字段不为空，因为物理复制与集簇关联，而逻辑复制与数据库关联。

逻辑订阅者也会作为一个标准的 复制从库 ，出现于 pg_stat_replication 视图中。

`pg_replication_origin` 复制源

复制源

table pg_replication_origin_status;
-[ RECORD 1 ]-----------
local_id    | 1
external_id | pg_19378
remote_lsn  | 0/0
local_lsn   | 0/6BB53640

local_id：复制源在本地的ID，2字节高效表示。
external_id：复制源的ID，可以跨节点引用。
remote_lsn：源端最近的提交位点。
local_lsn：本地已经持久化提交记录的LSN

检测复制冲突

最稳妥的检测方法总是从发布与订阅两侧的日志中检测。当出现复制冲突时，发布测上可以看见复制连接中断

LOG:  terminating walsender process due to replication timeout
LOG:  starting logical decoding for slot "pg_test_sub"
DETAIL:  streaming transactions committing after 0/xxxxx, reading WAL from 0/xxxx

而订阅端则可以看到复制冲突的具体原因，例如：

logical replication worker PID 4585 exited with exit code 1
ERROR: duplicate key value violates unique constraint "pgbench_tellers_pkey","Key (tid)=(9) already exists.",,,,"COPY pgbench_tellers, line 31",,,,"","logical replication worker"

此外，一些监控指标也可以反映逻辑复制的状态：

例如：pg_replication_slots.confirmed_flush_lsn 长期落后于pg_cureent_wal_lsn。或者pg_stat_replication.flush_ag/write_lag 有显著增长。

安全

参与订阅的表，其Ownership与Trigger权限必须控制在超级用户所信任的角色手中（否则修改这些表可能导致逻辑复制中断）。

在发布节点上，如果不受信任的用户具有建表权限，那么创建发布时应当显式指定表名而非通配ALL TABLES。也就是说，只有当超级用户信任所有可以在发布或订阅侧具有建表（非临时表）权限的用户时，才可以使用FOR ALL TABLES。

用于复制连接的用户必须具有REPLICATION权限（或者为SUPERUSER）。如果该角色缺少SUPERUSER与BYPASSRLS，发布者上的行安全策略可能会被执行。如果表的属主在复制启动之后设置了行级安全策略，这个配置可能会导致复制直接中断，而不是策略生效。该用户必须拥有LOGIN权限，而且HBA规则允许其访问。

为了能够复制初始表数据，用于复制连接的角色必须在已发布的表上拥有SELECT权限（或者属于超级用户）。

创建发布，需要在数据库中的CREATE权限，创建一个FOR ALL TABLES的发布，需要超级用户权限。

将表加入到发布中，用户需要具有表的属主权限。

创建订阅需要超级用户权限，因为订阅的apply进程在本地数据库中以超级用户的权限运行。

权限只会在建立复制连接时检查，不会在发布端读取每条变更记录时重复检查，也不会在订阅端应用每条记录时检查。

配置选项

逻辑复制需要一些配置选项才能正常工作。

在发布者一侧，wal_level 必须设置为logical，max_replication_slots最少需要设为订阅的数量+用于表数据同步的数量。max_wal_senders最少需要设置为max_replication_slots + 为物理复制保留的数量，

在订阅者一侧，也需要设置max_replication_slots，max_replication_slots，最少需要设为订阅数。

max_logical_replication_workers最少需要配置为订阅的数量，再加上一些用于数据同步的工作进程数。

此外，max_worker_processes需要相应调整，至少应当为max_logical_replication_worker + 1。注意一些扩展插件和并行查询也会从工作进程的池子中获取连接使用。

配置参数样例

64核机器，1～2个发布与订阅，最多6个同步工作进程，最多8个物理从库的场景，一种样例配置如下所示：

首先决定Slot数量，2个订阅，6个同步工作进程，8个物理从库，所以配置为16。Sender = Slot + Physical Replica = 24。

同步工作进程限制为6，2个订阅，所以逻辑复制的总工作进程设置为8。

wal_level: logical                      # logical	
max_worker_processes: 64                # default 8 -> 64, set to CPU CORE 64
max_parallel_workers: 32                # default 8 -> 32, limit by max_worker_processes
max_parallel_maintenance_workers: 16    # default 2 -> 16, limit by parallel worker
max_parallel_workers_per_gather: 0      # default 2 -> 0,  disable parallel query on OLTP instance
# max_parallel_workers_per_gather: 16   # default 2 -> 16, enable parallel query on OLAP instance

max_wal_senders: 24                     # 10 -> 24
max_replication_slots: 16               # 10 -> 16 
max_logical_replication_workers: 8      # 4 -> 8, 6 sync worker + 1~2 apply worker
max_sync_workers_per_subscription: 6    # 2 -> 6, 6 sync worker

快速配置

首先设置发布侧的配置选项 wal_level = logical，该参数需要重启方可生效，其他参数的默认值都不影响使用。

然后创建复制用户，添加pg_hba.conf配置项，允许外部访问，一种典型配置是：

CREATE USER replicator REPLICATION BYPASSRLS PASSWORD 'DBUser.Replicator';

注意，逻辑复制的用户需要具有SELECT权限，在Pigsty中replicator已经被授予了dbrole_readonly角色。

host     all          replicator     0.0.0.0/0     md5
host     replicator   replicator     0.0.0.0/0     md5

然后在发布侧的数据库中执行：

CREATE PUBLICATION mypub FOR TABLE <tablename>;

然后在订阅测数据库中执行：

CREATE SUBSCRIPTION mysub CONNECTION 'dbname=<pub_db> host=<pub_host> user=replicator' PUBLICATION mypub;

以上配置即会开始复制，首先复制表的初始数据，然后开始同步增量变更。

沙箱样例

以Pigsty标准4节点两集群沙箱为例，有两套数据库集群pg-meta与pg-test。现在将pg-meta-1作为发布者，pg-test-1作为订阅者。

PGSRC='postgres://dbuser_admin@meta-1/meta'           # 发布者
PGDST='postgres://dbuser_admin@node-1/test'           # 订阅者
pgbench -is100 ${PGSRC}                               # 在发布端初始化Pgbench
pg_dump -Oscx -t pgbench* -s ${PGSRC} | psql ${PGDST} # 在订阅端同步表结构

# 在发布者上创建**发布**，将默认的`pgbench`相关表加入到发布集中。
psql ${PGSRC} -AXwt <<-'EOF'
CREATE PUBLICATION "pg_meta_pub" FOR TABLE
  pgbench_accounts,pgbench_branches,pgbench_history,pgbench_tellers;
EOF

# 在订阅者上创建**订阅**，订阅发布者上的发布。
psql ${PGDST} <<-'EOF'
CREATE SUBSCRIPTION pg_test_sub
  CONNECTION 'host=10.10.10.10 dbname=meta user=replicator' 
  PUBLICATION pg_meta_pub;
EOF

复制流程

逻辑复制的订阅创建后，如果一切正常，逻辑复制会自动开始，针对每张订阅中的表执行复制状态机逻辑。

如下图所示。

stateDiagram-v2 [*] --> init : 表被加入到订阅集中 init --> data : 开始同步表的初始快照 data --> sync : 存量数据同步完成 sync --> ready : 同步期间的增量变更应用完毕，进入就绪状态

当所有的表都完成复制，进入r（ready）状态时，逻辑复制的存量同步阶段便完成了，发布端与订阅端整体进入同步状态。

因此从逻辑上讲，存在两种状态机：表级复制小状态机与全局复制大状态机。每一个Sync Worker负责一张表上的小状态机，而一个Apply Worker负责一条逻辑复制的大状态机。

逻辑复制状态机

逻辑复制有两种Worker：Sync与Apply。Sync

因此，逻辑复制在逻辑上分为两个部分：每张表独自进行复制，当复制进度追赶至最新位置时，由

当创建或刷新订阅时，表会被加入到订阅集中，每一张订阅集中的表都会在pg_subscription_rel视图中有一条对应纪录，展示这张表当前的复制状态。刚加入订阅集的表初始状态为i，即initialize，初始状态。

如果订阅的copy_data选项为真（默认情况），且工作进程池中有空闲的Worker，PostgreSQL会为这张表分配一个同步工作进程，同步这张表上的存量数据，此时表的状态进入d，即拷贝数据中。对表做数据同步类似于对数据库集群进行basebackup，Sync Worker会在发布端创建临时的复制槽，获取表上的快照并通过COPY完成基础数据同步。

当表上的基础数据拷贝完成后，表会进入sync模式，即数据同步，同步进程会追赶同步过程中发生的增量变更。当追赶完成时，同步进程会将这张表标记为r（ready）状态，转交逻辑复制主Apply进程管理变更，表示这张表已经处于正常复制中。

2.4 等待逻辑复制同步

创建订阅后，首先必须监控发布端与订阅端两侧的数据库日志，确保没有错误产生。

2.4.1 逻辑复制状态机

2.4.2 同步进度跟踪

数据同步（d）阶段可能需要花费一些时间，取决于网卡，网络，磁盘，表的大小与分布，逻辑复制的同步worker数量等因素。

作为参考，1TB的数据库，20张表，包含有250GB的大表，双万兆网卡，在6个数据同步worker的负责下大约需要6~8小时完成复制。

在数据同步过程中，每个表同步任务都会源端库上创建临时的复制槽。请确保逻辑复制初始同步期间不要给源端主库施加过大的不必要写入压力，以免WAL撑爆磁盘。

发布侧的 pg_stat_replication，pg_replication_slots，订阅端的pg_stat_subscription，pg_subscription_rel提供了逻辑复制状态的相关信息，需要关注。

psql ${PGDST} -Xxw <<-'EOF'
    SELECT subname, json_object_agg(srsubstate, cnt) FROM
    pg_subscription s JOIN
      (SELECT srsubid, srsubstate, count(*) AS cnt FROM pg_subscription_rel 
       GROUP BY srsubid, srsubstate) sr
    ON s.oid = sr.srsubid GROUP BY subname;
EOF

可以使用以下SQL确认订阅中表的状态，如果所有表的状态都显示为r，则表示逻辑复制已经成功建立，订阅端可以用于切换。

   subname   | json_object_agg
-------------+-----------------
 pg_test_sub | { "r" : 5 }

当然，最好的方式始终是通过监控系统来跟踪复制状态。

沙箱样例

以Pigsty标准4节点两集群沙箱为例，有两套数据库集群pg-meta与pg-test。现在将pg-meta-1作为发布者，pg-test-1作为订阅者。

通常逻辑复制的前提是，发布者上设置有wal_level = logical，并且有一个可以正常访问，具有正确权限的复制用户。

Pigsty的默认配置已经符合要求，且带有满足条件的复制用户replicator，以下命令均从元节点以postgres用户发起，数据库用户dbuser_admin，带有SUPERUSER权限。

PGSRC='postgres://dbuser_admin@meta-1/meta'        # 发布者
PGDST='postgres://dbuser_admin@node-1/test'        # 订阅者

准备逻辑复制

使用pgbench工具，在pg-meta集群的meta数据库中初始化表结构。

pgbench -is100 ${PGSRC}

使用pg_dump与psql 同步 pgbench* 相关表的定义。

pg_dump -Oscx -t pgbench* -s ${PGSRC} | psql ${PGDST}

创建发布订阅

在发布者上创建发布，将默认的pgbench相关表加入到发布集中。

psql ${PGSRC} -AXwt <<-'EOF'
CREATE PUBLICATION "pg_meta_pub" FOR TABLE
  pgbench_accounts,pgbench_branches,pgbench_history,pgbench_tellers;
EOF

在订阅者上创建订阅，订阅发布者上的发布。

psql ${PGDST} <<-'EOF'
CREATE SUBSCRIPTION pg_test_sub
  CONNECTION 'host=10.10.10.10 dbname=meta user=replicator' 
  PUBLICATION pg_meta_pub;
EOF

观察复制状态

当pg_subscription_rel.srsubstate全部变为r （准备就绪）状态后，逻辑复制就建立起来了。

$ psql ${PGDST} -c 'TABLE pg_subscription_rel;'
 srsubid | srrelid | srsubstate |  srsublsn
---------+---------+------------+------------
   20451 |   20433 | d          | NULL
   20451 |   20442 | r          | 0/4ECCDB78
   20451 |   20436 | r          | 0/4ECCDB78
   20451 |   20439 | r          | 0/4ECCDBB0

校验复制数据

可以简单地比较发布与订阅端两侧的表记录条数，与复制标识列的最大最小值来校验数据是否完整地复制。

function compare_relation(){
	local relname=$1
	local identity=${2-'id'}
	psql ${3-${PGPUB}} -AXtwc "SELECT count(*) AS cnt, max($identity) AS max, min($identity) AS min FROM ${relname};"
	psql ${4-${PGSUB}} -AXtwc "SELECT count(*) AS cnt, max($identity) AS max, min($identity) AS min FROM ${relname};"
}
compare_relation pgbench_accounts aid
compare_relation pgbench_branches bid
compare_relation pgbench_history  tid
compare_relation pgbench_tellers  tid

更近一步的验证可以通过在发布者上手工创建一条记录，再从订阅者上读取出来。

$ psql ${PGPUB} -AXtwc 'INSERT INTO pgbench_accounts(aid,bid,abalance) VALUES (99999999,1,0);'
INSERT 0 1
$ psql ${PGSUB} -AXtwc 'SELECT * FROM pgbench_accounts WHERE aid = 99999999;'
99999999|1|0|

现在已经拥有一个正常工作的逻辑复制了。下面让我们来通过一系列实验来掌握逻辑复制的使用与管理，探索可能遇到的各种离奇问题。

逻辑复制实验

将表加入已有发布

CREATE TABLE t_normal(id BIGSERIAL PRIMARY KEY,v  TIMESTAMP); -- 常规表，带有主键
ALTER PUBLICATION pg_meta_pub ADD TABLE t_normal; -- 将新创建的表加入到发布中

如果这张表在订阅端已经存在，那么即可进入正常的逻辑复制流程：i -> d -> s -> r。

如果向发布加入一张订阅端不存在的表？那么新订阅将会无法创建。已有订阅无法刷新，但可以保持原有复制继续进行。

如果订阅还不存在，那么创建的时候会报错无法进行：在订阅端找不到这张表。如果订阅已经存在，无法执行刷新命令：

ALTER SUBSCRIPTION pg_test_sub REFRESH PUBLICATION;

如果新加入的表没有任何写入，已有的复制关系不会发生变化，一旦新加入的表发生变更，会立即产生复制冲突。

将表从发布中移除

ALTER PUBLICATION pg_meta_pub ADD TABLE t_normal;

从发布移除后，订阅端不会有影响。效果上就是这张表的变更似乎消失了。执行订阅刷新后，这张表会从订阅集中被移除。

另一种情况是重命名发布/订阅中的表，在发布端执行表重命名时，发布端的发布集会立刻随之更新。尽管订阅集中的表名不会立刻更新，但只要重命名后的表发生任何变更，而订阅端没有对应的表，那么会立刻出现复制冲突。

同理，在订阅端重命名表时，订阅的关系集也会刷新，但因为发布端的表没有对应物了。如果这张表没有变更，那么一切照旧，一旦发生变更，立刻出现复制冲突。

直接在发布端DROP此表，会顺带将该表从发布中移除，不会有报错或影响。但直接在订阅端DROP表则可能出现问题，DROP TABLE时该表也会从订阅集中被移除。如果发布端此时这张表上仍有变更产生，则会导致复制冲突。

所以，删表应当先在发布端进行，再在订阅端进行。

两端列定义不一致

发布与订阅端的表的列通过名称匹配，列的顺序无关紧要。

订阅端表的列更多，通常不会有什么影响。多出来的列会被填充为默认值（通常是NULL）。

特别需要注意的是，如果要为多出来的列添加NOT NULL约束，那么一定要配置一个默认值，否则变更发生时违反约束会导致复制冲突。

订阅端如果列要比发布端更少，会产生复制冲突。在发布端添加一个新列并不会立刻导致复制冲突，随后的第一条变更将导致复制冲突。

所以在执行加列DDL变更时，可以先在订阅者上先执行，然后在发布端进行。

列的数据类型不需要完全一致，只要两个列的文本表示兼容即可，即数据的文本表示可以转换为目标列的类型。

这意味着任何类型都能转换成TEXT类型，BIGINT 只要不出错，也可以转换成INT，不过一旦溢出，还是会出现复制冲突。

复制身份与索引的正确配置

表上的复制标识配置，与表上有没有索引是两件独立的事。尽管各种排列组合都是可能的，然而在实际使用中只有三种可行的情况，其他情况都无法正常完成逻辑复制的功能（如果不报错，通常也是侥幸）

表上有主键，使用默认的 default 复制标识，不需要额外配置。
表上没有主键，但是有非空唯一索引，显式配置 index 复制标识。
表上既没有主键也没有非空唯一索引，显式配置full复制标识（运行效率低，仅作为兜底方案）

复制身份模式\表上的约束	主键(p)	非空唯一索引(u)	两者皆无(n)
default	有效	x	x
index	x	有效	x
full	低效	低效	低效
nothing	x	x	x

在所有情况下，INSERT都可以被正常复制。x代表DELETE|UPDATE所需关键信息缺失无法正常完成。

最好的方式当然是事前修复，为所有的表指定主键，以下查询可以用于找出缺失主键或非空唯一索引的表：

SELECT quote_ident(nspname) || '.' || quote_ident(relname) AS name, con.ri AS keys,
       CASE relreplident WHEN 'd' THEN 'default' WHEN 'n' THEN 'nothing' WHEN 'f' THEN 'full' WHEN 'i' THEN 'index' END AS replica_identity
FROM pg_class c JOIN pg_namespace n ON c.relnamespace = n.oid, LATERAL (SELECT array_agg(contype) AS ri FROM pg_constraint WHERE conrelid = c.oid) con
WHERE relkind = 'r' AND nspname NOT IN ('pg_catalog', 'information_schema', 'monitor', 'repack', 'pg_toast')
ORDER BY 2,3;

注意，复制身份为nothing的表可以加入到发布中，但在发布者上对其执行UPDATE|DELETE会直接导致报错。

其他问题

Q：逻辑复制准备工作

Q：什么样的表可以逻辑复制？

Q：监控逻辑复制状态

Q：将新表加入发布

Q：没有主键的表加入发布？

Q：没有复制身份的表如何处理？

Q：ALTER PUB的生效方式

Q：在同一对发布者-订阅者上如果存在多对订阅，且发布包含的表重叠？

Q：订阅者和发布者的表定义有什么限制？

Q：pg_dump是如何处理订阅的

Q：什么情况下需要手工管理订阅复制槽？

PG中的本地化排序规则

什么？不知道COLLATTION是什么，那记住一件事，用C COLLATE准没错！

著： 冯若航（@Vonng） | 2021-03-05

为什么Pigsty在初始化Postgres数据库时默认指定了locale=C与encoding=UTF8

答案其实很简单，除非真的明确知道自己会用到LOCALE相关功能，否则就根本不应该配置C.UTF8之外的任何字符编码与本地化排序规则选项。特别是`

关于字符编码的部分，之前写过一篇文章专门介绍，这里表过不提。今天专门说一下LOCALE（本地化）的配置问题。

如果说服务端字符编码配置因为某些原因配置为UTF8之外的值也许还情有可原，那么LOCALE配置为C之外的任何选就是无可救药了。因为对于PostgreSQL来说，LOCALE不仅仅是控制日期和钱怎么显示这一类无伤大雅的东西，而是会影响到某些关键功能的使用。

错误的LOCALE配置可能导致几倍到十几倍的性能损失，还会导致LIKE查询无法在普通索引上使用。而设置LOCALE=C一点也不会影响真正需要本地化规则的使用场景。所以官方文档给出的指导是：“如果你真正需要LOCALE，才去使用它”。

不幸的是，在PostgreSQLlocale与encoding的默认配置取决于操作系统的配置，因此C.UTF8可能并不是默认的配置，这就导致了很多人误用LOCALE而不自知，白白折损了大量性能，也导致了某些数据库特性无法正常使用。

太长；不看

强制使用UTF8字符编码，强制数据库使用C的本地化规则。
使用非C本地化规则，可能导致涉及字符串比较的操作开销增大几倍到几十倍，对性能产生显著负面影响
使用非C本地化规则，会导致LIKE查询无法使用普通索引，容易踩坑雪崩。
使用非C本地化规则的实例，可以通过text_ops COLLATE "C"或text_pattern_ops建立索引，支持LIKE查询。

LOCALE是什么

我们经常能在操作系统和各种软件中看到 LOCALE（区域） 的相关配置，但LOCALE到底是什么呢？

LOCALE支持指的是应用遵守文化偏好的问题，包括字母表、排序、数字格式等。LOCALE由很多规则与定义组成，包括：

`LC_COLLATE`	字符串排序顺序
`LC_CTYPE`	字符分类（什么是一个字符？它的大写形式是否等效？）
`LC_MESSAGES`	消息使用的语言Language of messages
`LC_MONETARY`	货币数量使用的格式
`LC_NUMERIC`	数字的格式
`LC_TIME`	日期和时间的格式
……	其他……

一个LOCALE就是一组规则，LOCALE通常会用语言代码 + 国家代码的方式来命名。例如中国大陆使用的LOCALE zh_CN就分为两个部分：zh是语言代码，CN 是国家代码。现实世界中，一种语言可能有多个国家在用，一个国家内也可能存在多种语言。还是以中文和中国为例：

中国（COUNTRY=CN）相关的语言LOCALE有：

zh：汉语：zh_CN
bo：藏语：bo_CN
ug：维语：ug_CN

讲中文（LANG=zh）的国家或地区相关的LOCAL有：

CN 中国：zh_CN
HK 香港：zh_HK
MO 澳门：zh_MO
TW 台湾：zh_TW
SG 新加坡：zh_SG

LOCALE的例子

我们可以参考一个典型的Locale定义文件：Glibc提供的 zh_CN

这里截取一小部分展示，看上去好像都是些鸡零狗碎的格式定义，月份星期怎么叫啊，钱和小数点怎么显示啊之类的东西。

但这里有一个非常关键的东西，叫做LC_COLLATE，即排序方式（Collation），会对数据库行为有显著影响。

LC_CTYPE
copy "i18n"
translit_start
include  "translit_combining";""
translit_end
class	"hanzi"; /
<U4E00>..<U9FA5>;/
<UF92C>;<UF979>;<UF995>;<UF9E7>;<UF9F1>;<UFA0C>;<UFA0D>;<UFA0E>;/
<UFA0F>;<UFA11>;<UFA13>;<UFA14>;<UFA18>;<UFA1F>;<UFA20>;<UFA21>;/
<UFA23>;<UFA24>;<UFA27>;<UFA28>;<UFA29>
END LC_CTYPE

LC_COLLATE
copy "iso14651_t1_pinyin"
END LC_COLLATE

LC_TIME
% 一月, 二月, 三月, 四月, 五月, 六月, 七月, 八月, 九月, 十月, 十一月, 十二月
mon           "<U4E00><U6708>";/
     "<U4E8C><U6708>";/
     "<U4E09><U6708>";/
     "<U56DB><U6708>";/
...
% 星期日, 星期一, 星期二, 星期三, 星期四, 星期五, 星期六
day           "<U661F><U671F><U65E5>";/
     "<U661F><U671F><U4E00>";/
     "<U661F><U671F><U4E8C>";/
...
week          7;19971130;1
first_weekday 2
% %Y年%m月%d日 %A %H时%M分%S秒
d_t_fmt       "%Y<U5E74>%m<U6708>%d<U65E5> %A %H<U65F6>%M<U5206>%S<U79D2>"
% %Y年%m月%d日
d_fmt         "%Y<U5E74>%m<U6708>%d<U65E5>"
% %H时%M分%S秒
t_fmt         "%H<U65F6>%M<U5206>%S<U79D2>"
% 上午, 下午
am_pm         "<U4E0A><U5348>";"<U4E0B><U5348>"
% %p %I时%M分%S秒
t_fmt_ampm    "%p %I<U65F6>%M<U5206>%S<U79D2>"
% %Y年 %m月 %d日 %A %H:%M:%S %Z
date_fmt      "%Y<U5E74> %m<U6708> %d<U65E5> %A %H:%M:%S %Z"
END LC_TIME

LC_NUMERIC
decimal_point "."
thousands_sep ","
grouping      3
END LC_NUMERIC

LC_MONETARY
% ￥
currency_symbol    "<UFFE5>"
int_curr_symbol    "CNY "

比如zh_CN提供的LC_COLLATE使用了iso14651_t1_pinyin排序规则，这是一个基于拼音的排序规则。

下面通过一个例子来介绍LOCALE中的COLLATION如何影响Postgres的行为。

排序规则一例

创建一张包含7个汉字的表，然后执行排序操作。

CREATE TABLE some_chinese(
    name TEXT PRIMARY KEY
);
INSERT INTO some_chinese VALUES 
('阿'),('波'),('磁'),('得'),('饿'),('佛'),('割');

SELECT * FROM some_chinese ORDER BY name;

执行以下SQL，按照默认的C排序规则对表中的记录排序。可以看到，这里实际上是按照字符的ascii|unicode 码位进行排序的。

vonng=# SELECT name, ascii(name) FROM some_chinese ORDER BY name COLLATE "C";
 name | ascii
------+-------
 佛   | 20315
 割   | 21106
 得   | 24471
 波   | 27874
 磁   | 30913
 阿   | 38463
 饿   | 39295

但这样基于码位的排序对于中国人来说可能没有任何意义。例如新华字典在收录汉字时，就不会使用这种排序方式。而是采用zh_CN 所使用的 拼音排序 规则，按照拼音比大小。如下所示：

 SELECT * FROM some_chinese ORDER BY name COLLATE "zh_CN";
 name
------
 阿
 波
 磁
 得
 饿
 佛
 割

可以看到，按照zh_CN排序规则排序得到的结果，就是拼音顺序abcdefg，而不再是不知所云的Unicode码位排序。

当然这个查询结果取决于zh_CN 排序规则的具体定义，像这样的排序规则并不是数据库本身定义的，数据库本身提供的排序规则就是C（或者其别名POSIX）。COLLATION的来源，通常要么是操作系统，要么是glibc，要么是第三方的本地化库（例如icu），所以可能因为不同的实质定义出现不同的效果。

但代价是什么？

PostgreSQL中使用非C或非POSIX LOCALE的最大负面影响是：

特定排序规则对涉及字符串大小比较的操作有巨大的性能影响，同时它还会导致无法在LIKE查询子句中使用普通索引。

另外，C LOCALE是由数据库本身确保在任何操作系统与平台上使用的，而其他的LOCALE则不然，所以使用非C Locale的可移植性更差。

性能损失

接下来让我们考虑一个使用LOCALE排序规则的例子，我们有Apple Store 150万款应用的名称，现在希望按照不同的区域规则进行排序。

-- 创建一张应用名称表，里面有中文也有英文。
CREATE TABLE app(
    name TEXT PRIMARY KEY
);
COPY app FROM '/tmp/app.csv';

-- 查看表上的统计信息
SELECT
    correlation , -- 相关系数 0.03542578 基本随机分布
    avg_width ,   -- 平均长度25字节
    n_distinct    -- -1，意味着1508076个记录没有重复
FROM pg_stats WHERE tablename = 'app';

-- 使用不同的排序规则进行一系列的实验
SELECT * FROM app;
SELECT * FROM app order by name; 
SELECT * FROM app order by name COLLATE "C";
SELECT * FROM app order by name COLLATE "en_US";
SELECT * FROM app order by name COLLATE "zh_CN";

相当令人震惊的结果，使用C和zh_CN的结果能相差十倍之多：

序号	场景	耗时(ms)	说明
1	不排序	180	使用索引
2	`order by name`	969	使用索引
3	`order by name COLLATE "C"`	1430	顺序扫描，外部排序
4	`order by name COLLATE "en_US"`	10463	顺序扫描，外部排序
5	`order by name COLLATE "zh_CN"`	14852	顺序扫描，外部排序

下面是实验5对应的详细执行计划，即使配置了足够大的内存，依然会溢出到磁盘执行外部排序。尽管如此，显式指定LOCALE的实验都出现了此情况，因此可以横向对比出C与zh_CN的性能差距来。

另一个更有对比性的例子是比大小。

这里，表中的所有的字符串都会和World比一下大小，相当于在表上进行150万次特定规则比大小，而且也不涉及到磁盘IO。

SELECT count(*) FROM app WHERE name > 'World';
SELECT count(*) FROM app WHERE name > 'World' COLLATE "C";
SELECT count(*) FROM app WHERE name > 'World' COLLATE "en_US";
SELECT count(*) FROM app WHERE name > 'World' COLLATE "zh_CN";

尽管如此，比起C LOCALE来，zh_CN 还是费了接近3倍的时长。

序号	场景	耗时(ms)
1	默认	120
2	C	145
3	en_US	351
4	zh_CN	441

如果说排序可能是O(n2)次比较操作有10倍损耗，那么这里的O(n)次比较3倍开销也基本能对应上。我们可以得出一个初步的粗略结论：

比起C Locale来，使用zh_CN或其他Locale可能导致几倍的额外性能开销。

除此之外，错误的Locale不仅仅会带来性能损失，还会导致功能损失。

功能缺失

除了性能表现糟糕外，另一个令人难以接受的问题是，使用非C的LOCALE，LIKE查询走不了普通索引。

还是以刚才的实验为例，我们分别在使用C和en_US作为默认LOCALE创建的数据库实例上执行以下查询：

SELECT * FROM app WHERE name LIKE '中国%';

找出所有以“中国”两字开头的应用。

在使用C的库上

该查询能正常使用app_pkey索引，利用主键B树的有序性加速查询，约2毫秒内执行完毕。

postgres@meta:5432/meta=# show lc_collate;
 C

postgres@meta:5432/meta=# EXPLAIN SELECT * FROM app WHERE name LIKE '中国%';
                                 QUERY PLAN
-----------------------------------------------------------------------------
 Index Only Scan using app_pkey on app  (cost=0.43..2.65 rows=1510 width=25)
   Index Cond: ((name >= '中国'::text) AND (name < '中图'::text))
   Filter: (name ~~ '中国%'::text)
(3 rows)

在使用en_US的库上

我们发现，这个查询无法利用索引，走了全表扫描。查询劣化至70毫秒，性能恶化了三四十倍。

vonng=# show lc_collate;
 en_US.UTF-8

vonng=# EXPLAIN SELECT * FROM app WHERE name LIKE '中国%';
                        QUERY PLAN
----------------------------------------------------------
 Seq Scan on app  (cost=0.00..29454.95 rows=151 width=25)
   Filter: (name ~~ '中国%'::text)

为什么？

因为索引（B树索引）的构建，也是建立在序的基础上，也就是等值和比大小这两个操作。

然而，LOCALE关于字符串的等价规则有一套自己的定义，例如在Unicode标准中就定义了很多匪夷所思的等价规则（毕竟是万国语言，比如多个字符复合而成的字符串等价于另一个单体字符，详情参考 现代字符编码 一文）。

因此，只有最朴素的C LOCALE，才能够正常地进行模式匹配。C LOCALE的比较规则非常简单，就是挨个比较字符码位，不玩那一套花里胡哨虚头巴脑的东西。所以，如果您的数据库不幸使用了非C的LOCALE，那么在执行LIKE查询时就没有办法使用默认的索引了。

解决办法

对于非C LOCALE的实例，只有建立特殊类型的索引，才能支持此类查询：

CREATE INDEX ON app(name COLLATE "C");
CREATE INDEX ON app(name text_pattern_ops);

这里使用 text_pattern_ops运算符族来创建索引也可以用来支持LIKE查询，这是专门用于支持模式匹配的运算符族，从原理上讲它会无视 LOCALE，直接基于 逐个字符 比较的方式执行模式匹配，也就是使用C LOCALE的方式。

因此在这种情况下，只有基于text_pattern_ops操作符族建立的索引，或者基于默认的text_ops但使用COLLATE "C"' 的索引，才可以用于支持LIKE查询。

vonng=# EXPLAIN ANALYZE SELECT * FROM app WHERE name LIKE '中国%';

Index Only Scan using app_name_idx on app  (cost=0.43..1.45 rows=151 width=25) (actual time=0.053..0.731 rows=2360 loops=1)
   Index Cond: ((name ~>=~ '中国'::text) AND (name ~<~ '中图'::text))
   Filter: (name ~~ '中国%'::text COLLATE "en_US.UTF-8")

建立完索引后，我们可以看到原来的LIKE查询可以走索引了。

LIKE无法使用普通索引这个问题，看上去似乎可以通过额外创建一个text_pattern_ops索引来曲线解决。但这也意味着原本可以直接利用现成的PRIMARY KEY或UNIQUE约束自带索引解决的问题，现在需要额外的维护成本与存储空间。

对于不熟悉这一问题的开发者来说，很有可能因为错误的LOCALE配置，导致本地没问题的模式结果在线上因为没有走索引而雪崩。（例如本地使用C，但生产环境用了非C LOCALE）。

兼容性

假设您在接手时数据库已经使用了非C的LOCALE（这种事相当常见），现在您在知道了使用非C LOCALE的危害后，决定找个机会改回来。

那么有哪些地方需要注意呢？具体来讲，Locale的配置影响PostgreSQL以下功能：

使用LIKE子句的查询。
任何依赖特定LOCALE排序规则的查询，例如依赖拼音排序作为结果排序依据。
使用大小写转换相关功能的查询，函数upper、lower和initcap
to_char函数家族，涉及到格式化为本地时间时。
正则表达式中的大小写不敏感匹配模式（SIMILAR TO ,~）。

如果不放心，可以通过pg_stat_statements列出所有涉及到以下关键词的查询语句进行手工排查：

LIKE|ILIKE                   -- 是否使用了模式匹配
SIMILAR TO | ~ | regexp_xxx  -- 是否使用了 i 选项
upper, lower, initcap        -- 是否针对其他带有大小写模式的语言使用（西欧字符之类）
ORDER BY col                 -- 按文本类型列排序时，是否依赖特定排序规则？（例如按照拼音）

兼容性修改

通常来说，C LOCALE在功能上是其他LOCALE配置的超集，总是可以从其他LOCALE切换为C。如果您的业务没有使用这些功能，通常什么都不需要做。如果使用本地化规则特性，则总是可以通过**显式指定COLLATE**的方式，在C LOCALE下实现相同的效果。

SELECT upper('a' COLLATE "zh_CN");  -- 基于zh_CN规则执行大小写转换
SELECT  '阿' < '波';                 -- false, 在默认排序规则下  阿(38463) > 波(27874)
SELECT  '阿' < '波' COLLATE "zh_CN"; -- true, 显式使用中文拼音排序规则： 阿(a) < 波(bo)

目前唯一已知的问题出现在扩展pg_trgm上。

PG复制标识详解（Replica Identity）

复制标识很重要，它关系到逻辑复制的成败

著： 冯若航（@Vonng） | 2021-03-03

引子：土法逻辑复制

复制身份的概念，服务于 逻辑复制。

逻辑复制的基本工作原理是，将逻辑发布相关表上对行的增删改事件解码，复制到逻辑订阅者上执行。

逻辑复制的工作方式有点类似于行级触发器，在事务执行后对变更的元组逐行触发。

假设您需要自己通过触发器实现逻辑复制，将一章表A上的变更复制到另一张表B中。通常情况下，这个触发器的函数逻辑通常会长这样：

-- 通知触发器
CREATE OR REPLACE FUNCTION replicate_change() RETURNS TRIGGER AS $$
BEGIN
  IF    (TG_OP = 'INSERT') THEN 
  -- INSERT INTO tbl_b VALUES (NEW.col);
  ELSIF (TG_OP = 'DELETE') THEN 
	-- DELETE tbl_b WHERE id = OLD.id;
  ELSIF (TG_OP = 'UPDATE') THEN 
	-- UPDATE tbl_b SET col = NEW.col,... WHERE id = OLD.id;
  END IF;
END; $$ LANGUAGE plpgsql;

触发器中会有两个变量OLD与NEW，分别包含了变更记录的旧值与新值。

INSERT操作只有NEW变量，因为它是新插入的，我们直接将其插入到另一张表即可。
DELETE操作只有OLD变量，因为它只是删除已有记录，我们 根据ID 在目标表B上。
UPDATE操作同时存在OLD变量与NEW变量，我们需要通过 OLD.id 定位目标表B中的记录，将其更新为新值NEW。

这样的基于触发器的“逻辑复制”可以完美达到我们的目的，在逻辑复制中与之类似，表A上带有主键字段id。那么当我们删除表A上的记录时，例如：删除id = 1的记录时，我们只需要告诉订阅方id = 1，而不是把整个被删除的元组传递给订阅方。那么这里主键列id就是逻辑复制的复制标识。

但上面的例子中隐含着一个工作假设：表A和表B模式相同，上面有一个名为 id 的主键。

对于生产级的逻辑复制方案，即PostgreSQL 10.0后提供的逻辑复制，这样的工作假设是不合理的。因为系统无法要求用户建表时一定会带有主键，也无法要求主键的名字一定叫id。

于是，就有了 复制标识（Replica Identity） 的概念。复制标识是对OLD.id这样工作假设的进一步泛化与抽象，它用来告诉逻辑复制系统，哪些信息可以被用于唯一定位表中的一条记录。

复制标识

对于逻辑复制而言，INSERT 事件不需要特殊处理，但要想将DELETE|UPDATE复制到订阅者上时，必须提供一种标识行的方式，即复制标识（Replica Identity）。复制标识是一组列的集合，这些列可以唯一标识一条记录。其实这样的定义在概念上来说就是构成主键的列集，当然非空唯一索引中的列集（候选键）也可以起到同样的效果。

一个被纳入逻辑复制发布中的表，必须配置有 复制标识（Replica Identity），只有这样才可以在订阅者一侧定位到需要更新的行，完成UPDATE与DELETE操作的复制。默认情况下，主键（Primary Key）和 非空列上的唯一索引 （UNIQUE NOT NULL）可以用作复制标识。

注意，复制标识 和表上的主键、非空唯一索引并不是一回事。复制标识是表上的一个属性，它指明了在逻辑复制时，哪些信息会被用作身份定位标识符写入到逻辑复制的记录中，供订阅端定位并执行变更。

如PostgreSQL 13官方文档所述，表上的复制标识 共有4种配置模式，分别为：

默认模式（default）：非系统表采用的默认模式，如果有主键，则用主键列作为身份标识，否则用完整模式。
索引模式（index）：将某一个符合条件的索引中的列，用作身份标识
完整模式（full）：将整行记录中的所有列作为复制标识（类似于整个表上每一列共同组成主键）
无身份模式（nothing）：不记录任何复制标识，这意味着UPDATE|DELETE操作无法复制到订阅者上。

复制标识查询

表上的复制标识可以通过查阅pg_class.relreplident获取。

这是一个字符类型的“枚举”，标识用于组装 “复制标识” 的列：d = default ，f = 所有的列，i 使用特定的索引，n 没有复制标识。

表上是否具有可用作复制标识的索引约束，可以通过以下查询获取：

SELECT quote_ident(nspname) || '.' || quote_ident(relname) AS name, con.ri AS keys,
       CASE relreplident WHEN 'd' THEN 'default' WHEN 'n' THEN 'nothing' WHEN 'f' THEN 'full' WHEN 'i' THEN 'index' END AS replica_identity
FROM pg_class c JOIN pg_namespace n ON c.relnamespace = n.oid, LATERAL (SELECT array_agg(contype) AS ri FROM pg_constraint WHERE conrelid = c.oid) con
WHERE relkind = 'r' AND nspname NOT IN ('pg_catalog', 'information_schema', 'monitor', 'repack', 'pg_toast')
ORDER BY 2,3;

复制标识配置

表到复制标识可以通过ALTER TABLE进行修改。

ALTER TABLE tbl REPLICA IDENTITY { DEFAULT | USING INDEX index_name | FULL | NOTHING };
-- 具体有四种形式
ALTER TABLE t_normal REPLICA IDENTITY DEFAULT;                    -- 使用主键，如果没有主键则为FULL
ALTER TABLE t_normal REPLICA IDENTITY FULL;                       -- 使用整行作为标识
ALTER TABLE t_normal REPLICA IDENTITY USING INDEX t_normal_v_key; -- 使用唯一索引
ALTER TABLE t_normal REPLICA IDENTITY NOTHING;                    -- 不设置复制标识

复制标识实例

下面用一个具体的例子来说明复制标识的效果：

CREATE TABLE test(k text primary key, v int not null unique);

现在有一个表test，上面有两列k和v。

INSERT INTO test VALUES('Alice', '1'), ('Bob', '2');
UPDATE test SET v = '3' WHERE k = 'Alice';    -- update Alice value to 3
UPDATE test SET k = 'Oscar' WHERE k = 'Bob';  -- rename Bob to Oscaar
DELETE FROM test WHERE k = 'Alice';           -- delete Alice

在这个例子中，我们对表test执行了增删改操作，与之对应的逻辑解码结果为：

table public.test: INSERT: k[text]:'Alice' v[integer]:1
table public.test: INSERT: k[text]:'Bob' v[integer]:2
table public.test: UPDATE: k[text]:'Alice' v[integer]:3
table public.test: UPDATE: old-key: k[text]:'Bob' new-tuple: k[text]:'Oscar' v[integer]:2
table public.test: DELETE: k[text]:'Alice'

默认情况下，PostgreSQL会使用表的主键作为复制标识，因此在UPDATE|DELETE操作中，都通过k列来定位需要修改的记录。

如果我们手动修改表的复制标识，使用非空且唯一的列v作为复制标识，也是可以的：

ALTER TABLE test REPLICA IDENTITY USING INDEX test_v_key; -- 基于UNIQUE索引的复制身份

同样的变更现在产生如下的逻辑解码结果，这里v作为身份标识，出现在所有的UPDATE|DELETE事件中。

table public.test: INSERT: k[text]:'Alice' v[integer]:1
table public.test: INSERT: k[text]:'Bob' v[integer]:2
table public.test: UPDATE: old-key: v[integer]:1 new-tuple: k[text]:'Alice' v[integer]:3
table public.test: UPDATE: k[text]:'Oscar' v[integer]:2
table public.test: DELETE: v[integer]:3

如果使用完整身份模式（full）

ALTER TABLE test REPLICA IDENTITY FULL; -- 表test现在使用所有列作为表的复制身份

这里，k和v同时作为身份标识，记录到UPDATE|DELETE的日志中。对于没有主键的表，这是一种保底方案。

table public.test: INSERT: k[text]:'Alice' v[integer]:1
table public.test: INSERT: k[text]:'Bob' v[integer]:2
table public.test: UPDATE: old-key: k[text]:'Alice' v[integer]:1 new-tuple: k[text]:'Alice' v[integer]:3
table public.test: UPDATE: old-key: k[text]:'Bob' v[integer]:2 new-tuple: k[text]:'Oscar' v[integer]:2
table public.test: DELETE: k[text]:'Alice' v[integer]:3

如果使用无身份模式（nothing）

ALTER TABLE test REPLICA IDENTITY NOTHING; -- 表test现在没有复制标识

那么逻辑解码的记录中，UPDATE操作中只有新记录，没有包含旧记录中的唯一身份标识，而DELETE操作中则完全没有信息。

table public.test: INSERT: k[text]:'Alice' v[integer]:1
table public.test: INSERT: k[text]:'Bob' v[integer]:2
table public.test: UPDATE: k[text]:'Alice' v[integer]:3
table public.test: UPDATE: k[text]:'Oscar' v[integer]:2
table public.test: DELETE: (no-tuple-data)

这样的逻辑变更日志对于订阅端来说完全没用，在实际使用中，对逻辑复制中的无复制标识的表执行DELETE|UPDATE会直接报错。

复制标识详解

表上的复制标识配置，与表上有没有索引，是相对正交的两个因素。

尽管各种排列组合都是可能的，然而在实际使用中，只有三种可行的情况。

表上有主键，使用默认的 default 复制标识
表上没有主键，但是有非空唯一索引，显式配置 index 复制标识
表上既没有主键，也没有非空唯一索引，显式配置full复制标识（运行效率非常低，仅能作为兜底方案）
其他所有情况，都无法正常完成逻辑复制功能

复制身份模式\表上的约束	主键(p)	非空唯一索引(u)	两者皆无(n)
default	有效	x	x
index	x	有效	x
full	低效	低效	低效
nothing	x	x	x

下面，我们来考虑几个边界条件。

重建主键

假设因为索引膨胀，我们希望重建表上的主键索引回收空间。

CREATE TABLE test(k text primary key, v int);
CREATE UNIQUE INDEX test_pkey2 ON test(k);
BEGIN;
ALTER TABLE test DROP CONSTRAINT test_pkey;
ALTER TABLE test ADD PRIMARY KEY USING INDEX test_pkey2;
COMMIT;

在default模式下，重建并替换主键约束与索引并不会影响复制标识。

重建唯一索引

假设因为索引膨胀，我们希望重建表上的非空唯一索引回收空间。

CREATE TABLE test(k text, v int not null unique);
ALTER TABLE test REPLICA IDENTITY USING INDEX test_v_key;
CREATE UNIQUE INDEX test_v_key2 ON test(v);
-- 使用新的test_v_key2索引替换老的Unique索引
BEGIN;
ALTER TABLE test ADD UNIQUE USING INDEX test_v_key2;
ALTER TABLE test DROP CONSTRAINT test_v_key;
COMMIT;

与default模式不同，index模式下，复制标识是与具体的索引绑定的：

                                    Table "public.test"
 Column |  Type   | Collation | Nullable | Default | Storage  | Stats target | Description
--------+---------+-----------+----------+---------+----------+--------------+-------------
 k      | text    |           |          |         | extended |              |
 v      | integer |           | not null |         | plain    |              |
Indexes:
    "test_v_key" UNIQUE CONSTRAINT, btree (v) REPLICA IDENTITY
    "test_v_key2" UNIQUE CONSTRAINT, btree (v)

这意味着如果采用偷天换日的方式替换UNIQUE索引会导致复制身份的丢失。

解决方案有两种：

使用REINDEX INDEX (CONCURRENTLY)的方式重建该索引，不会丢失复制标识信息。
在替换索引时，一并刷新表的默认复制身份：

BEGIN;
ALTER TABLE test ADD UNIQUE USING INDEX test_v_key2;
ALTER TABLE test REPLICA IDENTITY USING INDEX test_v_key2;
ALTER TABLE test DROP CONSTRAINT test_v_key;
COMMIT;

顺带一提，移除作为身份标识的索引。尽管在表的配置信息中仍然为index模式，但效果与nothing相同。所以不要随意折腾作为身份的索引。

使用不合格的索引作为复制标识

复制标识需要一个唯一，不可延迟，整表范围的，建立在非空列集上的索引。

最经典的例子就是主键索引，以及通过col type NOT NULL UNIQUE声明的单列非空索引。

之所以要求 NOT NULL，是因为NULL值无法进行等值判断，所以表中允许UNIQE的列上存在多条取值为NULL的记录，允许列为空说明这个列无法起到唯一标识记录的效果。如果尝试使用一个普通的UNIQUE索引（列上没有非空约束）作为复制标识，则会报错。

[42809] ERROR: index "t_normal_v_key" cannot be used as replica identity because column "v" is nullable

使用FULL复制标识

如果没有任何复制标识，可以将复制标识设置为FULL，也就是把整个行当作复制标识。

使用FULL模式的复制标识效率很低，所以这种配置只能是保底方案，或者用于很小的表。因为每一行修改都需要在订阅者上执行全表扫描，很容易把订阅者拖垮。

FULL模式限制

使用FULL模式的复制标识还有一个限制，订阅端的表上的复制身份所包含的列，要么与发布者一致，要么比发布者更少，否则也无法保证的正确性，下面具体来看一个例子。

假如发布订阅两侧的表都采用FULL复制标识，但是订阅侧的表要比发布侧多了一列（是的，逻辑复制允许订阅端的表带有发布端表不具有的列）。这样的话，订阅端的表上的复制身份所包含的列要比发布端多了。假设在发布端上删除(f1=a, f2=a)的记录，却会导致在订阅端删除两条满足身份标识等值条件的记录。

     (Publication)       ------>           (Subscription)
|--- f1 ---|--- f2 ---|          |--- f1 ---|--- f2 ---|--- f3 ---|
|    a     |     a    |          |    a     |     a    |     b    |
                                 |    a     |     a    |     c    |

FULL模式如何应对重复行问题

PostgreSQL的逻辑复制可以“正确”处理FULL模式下完全相同行的场景。假设有这样一张设计糟糕的表，表中存在多条一模一样的记录。

CREATE TABLE shitty_table(
	 f1  TEXT,
	 f2  TEXT,
	 f3  TEXT
);
INSERT INTO shitty_table VALUES ('a', 'a', 'a'), ('a', 'a', 'a'), ('a', 'a', 'a');

在FULL模式下，整行将作为复制标识使用。假设我们在shitty_table上通过ctid扫描作弊，删除了3条一模一样记录中的其中一条。

# SELECT ctid,* FROM shitty_table;
 ctid  | a | b | c
-------+---+---+---
 (0,1) | a | a | a
 (0,2) | a | a | a
 (0,3) | a | a | a

# DELETE FROM shitty_table WHERE ctid = '(0,1)';
DELETE 1

# SELECT ctid,* FROM shitty_table;
 ctid  | a | b | c
-------+---+---+---
 (0,2) | a | a | a
 (0,3) | a | a | a

从逻辑上讲，使用整行作为身份标识，那么订阅端执行以下逻辑，会导致全部3条记录被删除。

DELETE FROM shitty_table WHERE f1 = 'a' AND f2 = 'a' AND f3 = 'a'

但实际情况是，因为PostgreSQL的变更记录以行为单位，这条变更仅会对第一条匹配的记录生效，所以在订阅侧的行为也是删除3行中的1行。在逻辑上与发布端等效。

PG慢查询诊断方法论

慢查询是在线业务数据库的大敌，本文介绍了使用监控系统定位诊断慢查询的一般方法论。

著： 冯若航（@Vonng） | 2021-02-01

前言

You can’t optimize what you can’t measure

慢查询是在线业务数据库的大敌，如何诊断定位慢查询是DBA的必修课题。

本文介绍了使用监控系统 —— Pigsty诊断慢查询的一般方法论。

慢查询：危害

对于实际服务于在线业务事务处理的PostgreSQL数据库而言，慢查询的危害包括：

慢查询挤占数据库连接，导致普通查询无连接可用，堆积并导致数据库雪崩。
慢查询长时间锁住了主库已经清理掉的旧版本元组，导致流复制重放进程锁死，导致主从复制延迟。
查询越慢，查询间相互踩踏的几率越高，越容易产生死锁、锁等待，事务冲突等问题。
慢查询浪费系统资源，拉高系统水位。

因此，一个合格的DBA必须知道如何及时定位并处理慢查询。

图：一个慢查询优化前后，系统的整体饱和度从40%降到了4%

慢查询诊断 —— 传统方法

传统上来说，在PostgreSQL有两种方式可以获得慢查询的相关信息，一个是通过官方的扩展插件pg_stat_statements，另一种是慢查询日志。

慢查询日志顾名思义，所有执行时间长于log_min_duration_statement参数的查询都会被记录到PG的日志中，对于定位慢查询，特别是对于分析特例、单次慢查询不可或缺。不过慢查询日志也有自己的局限性。在生产环境中出于性能考虑，通常只会记录时长超出某一阈值的查询，那么许多信息就无法从慢查询日志中获取了。当然值得一提的是，尽管开销很大，但全量查询日志仍然是慢查询分析的终极杀手锏。

更常用的慢查询诊断工具可能还是pg_stat_statements。这事是一个非常实用的扩展，它会收集数据库内运行查询的统计信息，在任何场景下都强烈建议启用该扩展。

pg_stat_statements 提供的原始指标数据以系统视图表的形式呈现。系统中的每一类查询（即抽取变量后执行计划相同的查询）都分配有一个查询ID，紧接着是调用次数，总耗时，最大、最小、平均单次耗时，响应时间都标准差，每次调用平均返回的行数，用于块IO的时间这些指标类数据。

一种简单的方式当然是观察 mean_time/max_time这类指标，从系统的Catalog中，您的确可以知道某类查询有史以来平均的响应时间。对于定位慢查询来说，也许这样也算得上基本够用了。但是像这样的指标，只是系统在当前时刻的一个静态快照，所以能够回答的问题是有限的。譬如说，您想看一看某个查询在加上新索引之后的性能表现是不是有所改善，用这种方式可能就会非常繁琐。

pg_stat_statements需要在shared_preload_library中指定，并在数据库中通过CREATE EXTENSION pg_stat_statements显式创建。创建扩展后即可通过视图pg_stat_statements访问查询统计信息

慢查询的定义

多慢的查询算慢查询？

应该说这个问题取决于业务、以及实际的查询类型，并没有通用的标准。

作为一种经验阈值，频繁的CRUD点查，如果超过1ms，可列为慢查询。

对于偶发的单次特例查询而言，通常超过100ms或1s可以列为慢查询。

慢查询诊断 —— Pigsty

监控系统就可以更全面地回答关于慢查询的问题。监控系统中的数据是由无数历史快照组成的（如5秒一次快照采样）。因此用户可以回溯至任意时间点，考察不同时间段内查询平均响应时间的变化。

上图是Pigsty中 PG Query Detail提供的界面，这里展现出了单个查询的详细信息。

这是一个典型的慢查询，平均响应时间几秒钟。为它添加了一个索引后。从右中Query RT仪表盘的上可以看到，查询的平均响应世界从几秒降到了几毫秒。

用户可以利用监控系统提供的洞察迅速定位数据库中的慢查询，定位问题，提出猜想。更重要的是，用户可以即时地在不同层次审视表与查询的详细指标，应用解决方案并获取实时反馈，这对于紧急故障处理是非常有帮助的。

有时监控系统的用途不仅仅在于提供数据与反馈，它还可以作为一种安抚情绪的良药：设想一个慢查询把生产数据库打雪崩了，如果老板或客户没有一个地方可以透明地知道当前的处理状态，难免会焦急地催问，进一步影响问题解决的速度。监控系统也可以做作为精确管理的依据。您可以有理有据地用监控指标的变化和老板与客户吹牛逼。

一个模拟的慢查询案例

Talk is cheap, show me the code

假设用户已经拥有一个 Pigsty沙箱演示环境，下面将使用Pigsty沙箱，演示模拟的慢查询定位与处理流程。

慢查询：模拟

因为没有实际的业务系统，这里我们以一种简单快捷的方式模拟系统中的慢查询。即pgbench自带的类tpc-b场景。

通过make ri / make ro / make rw，在pg-test集群上初始化 pgbench 用例，并对集群施加读写负载

# 50TPS 写入负载
while true; do pgbench -nv -P1 -c20 --rate=50 -T10 postgres://test:test@pg-test:5433/test; done

# 1000TPS 只读负载
while true; do pgbench -nv -P1 -c40 --select-only --rate=1000 -T10 postgres://test:test@pg-test:5434/test; done

现在我们已经有了一个模拟运行中的业务系统，让我们通过简单粗暴的方式来模拟一个慢查询场景。在pg-test集群的主库上执行以下命令，删除表pgbench_accounts的主键：

ALTER TABLE pgbench_accounts DROP CONSTRAINT pgbench_accounts_pkey ;

该命令会移除 pgbench_accounts 表上的主键，导致相关查询从索引扫描变为顺序全表扫描，全部变为慢查询，访问PG Instance ➡️ Query ➡️ QPS，结果如下图所示：

图1：平均查询响应时间从1ms飙升为300ms，单个从库实例的QPS从500下降至7。

与此同时，实例因为慢查询堆积，系统会在瞬间雪崩过载，访问PG Cluster首页，可以看到集群负载出现飙升。

图2：系统负载达到200%，触发机器负载过大，与查询响应时间过长的报警规则。

慢查询：定位

首先，使用PG Cluster面板定位慢查询所在的具体实例，这里以 pg-test-2 为例。

然后，使用PG Query面板定位具体的慢查询：编号为 -6041100154778468427

图3：从查询总览中发现异常慢查询

该查询表现出：

响应时间显著上升： 17us 升至 280ms
QPS 显著下降：从500下降到 7
花费在该查询上的时间占比显著增加

可以确定，就是这个查询变慢了！

接下来，利用PG Stat Statements面板或PG Query Detail，根据查询ID定位慢查询的具体语句。

图4：定位查询语句为SELECT abalance FROM pgbench_accounts WHERE aid = $1

慢查询：猜想

获知慢查询语句后，接下来需要推断慢查询产生的原因。

SELECT abalance FROM pgbench_accounts WHERE aid = $1

该查询以 aid 作为过滤条件查询 pgbench_accounts 表，如此简单的查询变慢，大概率是这张表上的索引出了问题。 用屁股想都知道是索引少了，因为就是我们自己删掉的嘛！

分析查询后，可以提出猜想：该查询变慢是pgbench_accounts表上aid列缺少索引。

下一步，我们就要验证猜想。

第一步，使用PG Table Catalog，我们可以检视表的详情，例如表上建立的索引。

第二步，查阅 PG Table Detail 面板，检查 pgbench_accounts 表上的访问，来验证我们的猜想

图5： pgbench_accounts 表上的访问情况

通过观察，我们发现表上的索引扫描归零，与此同时顺序扫描却有相应增长。这印证了我们的猜想！

慢查询：方案

假设一旦成立，就可以着手提出方案，解决问题了。

解决慢查询通常有三种方式：修改表结构、修改查询、修改索引。

修改表结构与查询通常涉及到具体的业务知识和领域知识，需要具体问题具体分析。但修改索引通常来说不需要太多的具体业务知识。

这里的问题可以通过添加索引解决，pgbench_accounts 表上 aid 列缺少索引，那么我们尝试在 pgbench_accounts 表上为 aid 列添加索引，看看能否解决这个问题。

CREATE UNIQUE INDEX ON pgbench_accounts (aid);

加上索引后，神奇的事情发生了。

图6：可以看到，查询的响应时间与QPS已经恢复正常。

图7：系统的负载也恢复正常

慢查询：评估

作为慢查询处理的最后一步，我们通常需要对操作的过程进行记录，对效果进行评估。

有时候一个简单的优化可以产生戏剧性的效果。也许本来需要砸几十万加机器的问题，创建一个索引就解决了。

这种故事，就可以通过监控系统，用很生动直观的形式表达出来，赚取KPI与Credit。

图：一个慢查询优化前后，系统的整体饱和度从40%降到了4%

（相当于节省了X台机器，XX万元，老板看了心花怒放，下一任CTO就是你了！）

慢查询：小结

通过这篇教程，您已经掌握了慢查询优化的一般方法论。即：

定位问题
提出猜想
验证假设
制定方案
评估效果

监控系统在慢查询处理的整个生命周期中都能起到重要的效果。更能将运维与DBA的“经验”与“成果”，以可视化，可量化，可复制的方式表达出来。

PgSQL在线修改列类型

如何在线修改表中列的类型，例如从INT升级为BIGINT？

著： 冯若航（@Vonng） | 2021-01-15

如何在线升级INT至Bigint？

假设在PG中有一个表，在设计的时候拍脑袋使用了 INT 整型主键，现在业务蓬勃发展发现序列号不够用了，想升级到BIGINT类型。这时候该怎么做呢？

拍脑袋的方法当然是直接使用DDL修改类型：

ALTER TABLE pgbench_accounts

太长；不看

以Pgbench为例

-- 操作目标：升级 pgbench_accounts 表普通列 abalance 类型：INT -> BIGINT

-- 添加新列：abalance_tmp BIGINT
ALTER TABLE pgbench_accounts ADD COLUMN abalance_tmp BIGINT;

-- 创建触发器函数：保持新列数据与旧列同步
CREATE OR REPLACE FUNCTION public.sync_pgbench_accounts_abalance() RETURNS TRIGGER AS $$
BEGIN NEW.abalance_tmp = NEW.abalance; RETURN NEW;END;
$$ LANGUAGE 'plpgsql';

-- 完成整表更新，分批更新的方式见下
UPDATE pgbench_accounts SET abalance_tmp = abalance; -- 不要在大表上运行这个

-- 创建触发器
CREATE TRIGGER tg_sync_pgbench_accounts_abalance BEFORE INSERT OR UPDATE ON pgbench_accounts
    FOR EACH ROW EXECUTE FUNCTION sync_pgbench_accounts_abalance();

-- 完成列的新旧切换，这时候数据同步方向变化 旧列数据与新列保持同步
BEGIN;
LOCK TABLE pgbench_accounts IN EXCLUSIVE MODE;
ALTER TABLE pgbench_accounts DISABLE TRIGGER tg_sync_pgbench_accounts_abalance;
ALTER TABLE pgbench_accounts RENAME COLUMN abalance TO abalance_old;
ALTER TABLE pgbench_accounts RENAME COLUMN abalance_tmp TO abalance;
ALTER TABLE pgbench_accounts RENAME COLUMN abalance_old TO abalance_tmp;
ALTER TABLE pgbench_accounts ENABLE TRIGGER tg_sync_pgbench_accounts_abalance;
COMMIT;

-- 确认数据完整性
SELECT count(*) FROM pgbench_accounts WHERE abalance_new != abalance;

-- 清理触发器与函数
DROP FUNCTION IF EXISTS sync_pgbench_accounts_abalance();
DROP TRIGGER tg_sync_pgbench_accounts_abalance ON pgbench_accounts;

外键

alter table my_table add column new_id bigint;

begin; update my_table set new_id = id where id between 0 and 100000; commit;
begin; update my_table set new_id = id where id between 100001 and 200000; commit;
begin; update my_table set new_id = id where id between 200001 and 300000; commit;
begin; update my_table set new_id = id where id between 300001 and 400000; commit;
...

create unique index my_table_pk_idx on my_table(new_id);

begin;
alter table my_table drop constraint my_table_pk;
alter table my_table alter column new_id set default nextval('my_table_id_seq'::regclass);
update my_table set new_id = id where new_id is null;
alter table my_table add constraint my_table_pk primary key using index my_table_pk_idx;
alter table my_table drop column id;
alter table my_table rename column new_id to id;
commit;

以pgbench为例

vonng=# \d pgbench_accounts
              Table "public.pgbench_accounts"
  Column  |     Type      | Collation | Nullable | Default
----------+---------------+-----------+----------+---------
 aid      | integer       |           | not null |
 bid      | integer       |           |          |
 abalance | integer       |           |          |
 filler   | character(84) |           |          |
Indexes:
    "pgbench_accounts_pkey" PRIMARY KEY, btree (aid)

升级abalance列为BIGINT

会锁表，在表大小非常小，访问量非常小的的情况下可用。

ALTER TABLE pgbench_accounts ALTER COLUMN abalance SET DATA TYPE bigint;

在线升级流程

添加新列
更新数据
在新列上创建相关索引（如果没有也可以单列创建，加快第四步的速度）
执行切换事务
1. 排他锁表
2. UPDATE更新空列（也可以使用触发器）
3. 删旧列
4. 重命名新列

-- Step 1 : 创建新列
ALTER TABLE pgbench_accounts ADD COLUMN abalance_new BIGINT;

-- Step 2 : 更新数据，可以分批更新，分批更新方法详见下面
UPDATE pgbench_accounts SET abalance_new = abalance;

-- Step 3 : 可选（在新列上创建索引）
CREATE INDEX CONCURRENTLY ON public.pgbench_accounts (abalance_new);
UPDATE pgbench_accounts SET abalance_new = abalance WHERE ;

-- Step 3 :

-- Step 4 :

-- 同步更新对应列
CREATE OR REPLACE FUNCTION public.sync_abalance() RETURNS TRIGGER AS $$
BEGIN NEW.abalance_new = OLD.abalance; RETURN NEW;END;
$$ LANGUAGE 'plpgsql';

CREATE TRIGGER pgbench_accounts_sync_abalance BEFORE INSERT OR UPDATE ON pgbench_accounts EXECUTE FUNCTION sync_abalance();

alter table my_table add column new_id bigint;

begin; update my_table set new_id = id where id between 0 and 100000; commit;
begin; update my_table set new_id = id where id between 100001 and 200000; commit;
begin; update my_table set new_id = id where id between 200001 and 300000; commit;
begin; update my_table set new_id = id where id between 300001 and 400000; commit;
...

create unique index my_table_pk_idx on my_table(new_id);

begin;
alter table my_table drop constraint my_table_pk;
alter table my_table alter column new_id set default nextval('my_table_id_seq'::regclass);
update my_table set new_id = id where new_id is null;
alter table my_table add constraint my_table_pk primary key using index my_table_pk_idx;
alter table my_table drop column id;
alter table my_table rename column new_id to id;
commit;

批量更新逻辑

有时候需要为大表添加一个非空的，带有默认值的列。因此需要对整表进行一次更新，可以使用下面的办法，将一次巨大的更新拆分为100次或者更多的小更新。

从统计信息中获取主键的分桶信息：

SELECT unnest(histogram_bounds::TEXT::BIGINT[]) FROM pg_stats WHERE tablename = 'signup_users' and attname = 'id';

直接从统计分桶信息中生成需要执行的SQL，在这里把SQL改成需要更新的语

SELECT 'UPDATE signup_users SET app_type = '''' WHERE id BETWEEN ' || lo::TEXT || ' AND ' || hi::TEXT || ';'
FROM (
         SELECT lo, lead(lo) OVER (ORDER BY lo) as hi
         FROM (
                  SELECT unnest(histogram_bounds::TEXT::BIGINT[]) lo
                  FROM pg_stats
                  WHERE tablename = 'signup_users'
                    and attname = 'id'
                  ORDER BY 1
              ) t1
     ) t2;

直接使用SHELL脚本打印出更新语句

DATNAME=""
RELNAME="pgbench_accounts"
IDENTITY="aid"
UPDATE_CLAUSE="abalance_new = abalance"

SQL=$(cat <<-EOF
SELECT 'UPDATE ${RELNAME} SET ${UPDATE_CLAUSE} WHERE ${IDENTITY} BETWEEN ' || lo::TEXT || ' AND ' || hi::TEXT || ';'
FROM (
		SELECT lo, lead(lo) OVER (ORDER BY lo) as hi
		FROM (
				SELECT unnest(histogram_bounds::TEXT::BIGINT[]) lo
				FROM pg_stats
				WHERE tablename = '${RELNAME}'
					and attname = '${IDENTITY}'
				ORDER BY 1
			) t1
	) t2;
EOF
)

# echo $SQL

psql ${DATNAME} -qAXwtc "ANALYZE ${RELNAME};"
psql ${DATNAME} -qAXwtc "${SQL}"

处理边界情况。

 UPDATE signup_users SET app_type = '' WHERE app_type != '';

也可以加工一下，添加事务语句和休眠间隔

DATNAME="test"
RELNAME="pgbench_accounts"
COLNAME="aid"
UPDATE_CLAUSE="abalance_tmp = abalance"
SLEEP_INTERVAL=0.1

SQL=$(cat <<-EOF
SELECT 'BEGIN;UPDATE ${RELNAME} SET ${UPDATE_CLAUSE} WHERE ${COLNAME} BETWEEN ' || lo::TEXT || ' AND ' || hi::TEXT || ';COMMIT;SELECT pg_sleep(${SLEEP_INTERVAL});VACUUM ${RELNAME};'
FROM (
		SELECT lo, lead(lo) OVER (ORDER BY lo) as hi
		FROM (
				SELECT unnest(histogram_bounds::TEXT::BIGINT[]) lo
				FROM pg_stats
				WHERE tablename = '${RELNAME}'
					and attname = '${COLNAME}'
				ORDER BY 1
			) t1
	) t2;
EOF
)
# echo $SQL
psql ${DATNAME} -qAXwtc "ANALYZE ${RELNAME};"
psql ${DATNAME} -qAXwtc "${SQL}"

BEGIN;UPDATE pgbench_accounts SET abalance_new = abalance WHERE aid BETWEEN 397 AND 103196;COMMIT;SELECT pg_sleep(0.5);VACUUM pgbench_accounts;
BEGIN;UPDATE pgbench_accounts SET abalance_new = abalance WHERE aid BETWEEN 103196 AND 213490;COMMIT;SELECT pg_sleep(0.5);VACUUM pgbench_accounts;
BEGIN;UPDATE pgbench_accounts SET abalance_new = abalance WHERE aid BETWEEN 213490 AND 301811;COMMIT;SELECT pg_sleep(0.5);VACUUM pgbench_accounts;
BEGIN;UPDATE pgbench_accounts SET abalance_new = abalance WHERE aid BETWEEN 301811 AND 400003;COMMIT;SELECT pg_sleep(0.5);VACUUM pgbench_accounts;
BEGIN;UPDATE pgbench_accounts SET abalance_new = abalance WHERE aid BETWEEN 400003 AND 511931;COMMIT;SELECT pg_sleep(0.5);VACUUM pgbench_accounts;
BEGIN;UPDATE pgbench_accounts SET abalance_new = abalance WHERE aid BETWEEN 511931 AND 613890;COMMIT;SELECT pg_sleep(0.5);VACUUM pgbench_accounts;

黄金监控指标

了解PostgreSQL中的黄金监控指标

著： 冯若航（@Vonng） | 2020-11-06

前言

玩数据库和玩车有一个共通之处，就是都需要经常看仪表盘。

盯着仪表盘干什么，看指标。为什么看指标，掌握当前运行状态才能有效施加控制。

车有很多指标：车速，胎压，扭矩，刹车片磨损，各种温度，等等等等，各式各样。

但人的注意力空间有限，仪表盘也就那么大，

所以，指标可以分两类：

你会去看的：黄金指标 / 关键指标 / 核心指标
你不会看的：黑匣子指标 / 冷指标。

黄金指标就是那几个关键性的核心数据，需要时刻保持关注（或者让自动驾驶系统/报警系统替你时刻保持关注），而冷指标通常只有故障排查时才会去看，故障排查与验尸要求尽可能还原现场，黑匣子指标多多益善。需要时没有就很让人抓狂

今天我们来说说PostgreSQL的核心指标，数据库的核心指标是什么？

数据库的指标

在讲数据库的核心指标之前，我们先来瞄一眼有哪些指标。

avg(count by (ins) ({__name__=~"pg.*"}))
avg(count by (ins) ({__name__=~"node.*"}))

1000多个pg的指标，2000多个机器的指标。

这些指标都是数据宝藏，挖掘与可视化可以提取出其中的价值。

但对于日常管理，只需要少数几个核心指标就可以了。

可用指标千千万，哪些才是核心指标？

核心指标

根据经验和使用频度，不断地做减法，可以筛选出一些核心指标：

指标	缩写	层次	来源	种类
错误日志条数	Error Count	SYS/DB/APP	日志系统	错误
连接池排队数	Queue Clients	DB	连接池	错误
数据库负载	PG Load	DB	连接池	饱和度
数据库饱和度	PG Saturation	DB	连接池&节点	饱和度
主从复制延迟	Repl Lag	DB	数据库	延迟
平均查询响应时间	Query RT	DB	连接池	延迟
活跃后端进程数	Backends	DB	数据库	饱和度
数据库年龄	Age	DB	数据库	饱和度
每秒查询数	QPS	APP	连接池	流量
CPU使用率	CPU Usage	SYS	机器节点	饱和度

紧急情况下：错误是始终是第一优先级的黄金指标。

常规情况下：应用视角的黄金指标：QPS与RT

常规情况下：DBA视角的黄金指标：DB饱和度（水位）

为什么是它们？

错误指标

第一优先级的指标永远是错误，错误往往是直接面向终端用户的。

如果只能选一个指标进行监控，那么选错误指标，比如应用，系统，DB层的每秒错误日志条数可能最合适。

一辆车，只能选一个仪表盘上的功能，你会选什么？

选错误指标，小车不停只管推。

错误类指标非常重要，直接反映出系统的异常，譬如连接池排队。但错误类指标最大的问题就是，它只在告警时有意义，难以用于日常的水位评估与性能分析，此外，错误类指标也往往难以精确量化，往往只能给出定性的结果：有问题 vs 没问题。

此外，错误类指标难以精确量化。我们只能说：当连接池出现排队时，数据库负载比较大；队列越长，负载越大；没有排队时，数据库负载不怎么大，仅此而已。对于日常使用管理来说，这样的能力肯定也是不够的。

定指标，做监控报警系统的一个重要原因就是用于预防系统过载，如果系统已经过载大量报错，那么使用错误现象反过来定义饱和度是没有意义的。

指标的目的，是为了衡量系统的运行状态。，我们还会关注系统其他方面的能力：吞吐量/流量，响应时间/延迟，饱和度/利用率/水位线。这三者分别代表系统的能力，服务质量，负载水平。

关注点不同，后端（数据库用户）关注系统能力与服务质量，DBA（数据库管理者）更关注系统的负载水平。

流量指标

流量类的指标很有潜力，特别是QPS，TPS这样的指标相当具有代表性。

流量指标可以直接衡量系统的能力，譬如每秒处理多少笔订单，每秒处理的多少个请求。

与车速计有异曲同工之妙，高速限速，城市限速。环境，负载。

但像TPS QPS这样流量也存在问题。一个数据库实例上的查询往往是五花八门各式各样的，一个耗时10微秒的查询和一个10秒的查询在统计时都被算为一个Q，类似于QPS这样的指标无法进行横向比较，只有比较粗略的参考意义，甚至当查询类型发生变化时，都无法和自己的历史数据进行纵向比较。此外也很难针对QPS、TPS这样的指标设置利用率目标，同一个数据库执行SELECT 1可以打到几十万的QPS，但执行复杂SQL时可能就只能打到几千的QPS。不同负载类型和机器硬件会对数据库的QPS上限产生显著影响，只有当一个数据库上的查询都是高度单一同质且没有复杂变化的条件下，QPS才有参考意义，在这种苛刻条件下倒是可以通过压力测试设定一个QPS的水位目标。

延迟指标

与档位类似，查询慢，档位低，车速慢。查询档次低，TPS水位低。查询档次高，TPS水位高

延迟适合衡量系统的服务质量。

比起QPS/TPS，RT（响应时间 Response Time）这样的指标反而更具有参考价值。因为响应时间增加往往是系统饱和的前兆。根据经验法则，数据库的负载越大，查询与事务的平均响应时间也会越高。RT相比QPS的一个优势是**，RT是可以设置一个利用率目标的**，比如可以为RT设定一个绝对阈值：不允许生产OLTP库上出现RT超过1ms的慢查询。但QPS这样的指标就很难画出红线来。不过，RT也有自己的问题。第一个问题是它依然是定性而非定量的，延迟增加只是系统饱和的预警，但没法用来精确衡量系统的饱和度。第二个问题通常能从数据库与中间件获取到的RT统计指标都是平均值，但真正起到预警效果的有可能是诸如P99，P999这样的统计量。

饱和度指标

饱和度指标类似汽车的发动机转速表，油量表，水温表。

饱和度指标适合衡量系统的负载

即用户期待的负载指标是一个饱和度（Saturation）指标，所谓饱和度，即服务容量有多”满“，通常是系统中目前最为受限的某种资源的某个具体指标的度量。通常来说，0%的饱和度意味着系统完全空闲，100%的饱和度意味着满载，系统在达到100%利用率前就会出现性能的严重下降，因此设定指标时还需要包括一个利用率目标，或者说水位红线、黄线，当系统瞬时负载超过红线时应当触发告警，长期负载超过黄线时应当进行扩容。

其他可选指标
每秒事务数	TPS	APP	连接池	流量
磁盘IO使用率	Disk Usage	SYS	机器节点	饱和度
内存使用率	Mem Usage	SYS	机器节点	饱和度
网卡带宽使用率	Net Usage	SYS	机器节点	饱和度
TCP错误：溢出重传等	TCP ERROR	SYS	机器节点	错误

数据库集群管理概念与实体命名规范

概念及其命名是非常重要的东西，命名风格体现了工程师对系统架构的认知。定义不清的概念将导致沟通困惑，随意设定的名称将产生意想不到的额外负担。因此需要审慎地设计。

著： 冯若航（@Vonng） | 2020-06-03

数据库集群管理概念与实体命名规范

名之则可言也，言之则可行也。

TL;DR

**集群（Cluster）**是基本自治单元，由用户指定唯一标识，表达业务含义，作为顶层命名空间。
集群在硬件层面上包含一系列的节点（Node），即物理机，虚机（或Pod），可以通过IP唯一标识。
集群在软件层面上包含一系列的实例（Instance），即软件服务器，可以通过IP:Port唯一标识。
集群在服务层面上包含一系列的服务（Service），即可访问的域名与端点，可以通过域名唯一标识。
Cluster命名可以使用任意满足DNS域名规范的名称，但不能带点（[a-zA-Z0-9-]+）。
Node/Pod命名采用Cluster名称前缀，后接-连接一个从0开始分配的序号，（与k8s保持一致）
实例命名通常与Node保持一致，即${cluster}-${seq}的方式，这种方式隐含着节点与实例1:1部署的假设。如果这个假设不成立，则可以采用独立于节点的序号，但保持同样的命名规则。
Service命名采用Cluster名称前缀，后接-连接服务具体内容，如primary, standby

以上图为例，用于测试的数据库集群名为“pg-test”，该集群由一主两从三个数据库服务器实例组成，部署在集群所属的三个节点上。pg-test集群集群对外提供两种服务，读写服务pg-test-primary与只读副本服务pg-test-standby。

基本概念

在Postgres集群管理中，有如下概念：

集群（Cluster）

集群是基本的自治业务单元，这意味着集群能够作为一个整体组织对外提供服务。类似于k8s中Deployment的概念。注意这里的集群是软件层面的概念，不要与PG Cluster（数据库集簇，即包含多个PG Database实例的单个PG Server Instance）或Node Cluster（机器集群）混淆。

集群是管理的基本单位之一，是用于统合各类资源的组织单位。例如一个PG集群可能包括：

三个物理机器节点
一个主库实例，对外提供数据库读写服务。
两个从库实例，对外提供数据库只读副本服务。
两个对外暴露的服务：读写服务，只读副本服务。

每个集群都有用户根据业务需求定义的唯一标识符，本例中定义了一个名为pg-test的数据库集群。

节点（Node）

节点是对硬件资源的一种抽象，通常指代一台工作机器，无论是物理机（bare metal）还是虚拟机（vm），或者是k8s中的Pod。这里注意k8s中Node是硬件资源的抽象，但在实际管理使用上，是k8s中的Pod而不是Node更类似于这里Node概念。总之，节点的关键要素是：

节点是硬件资源的抽象，可以运行一系列的软件服务
节点可以使用IP地址作为唯一标识符

尽管可以使用lan_ip地址作为节点唯一标识符，但为了便于管理，节点应当拥有一个人类可读的充满意义的名称作为节点的Hostname，作为另一个常用的节点唯一标识。

服务（Service）

服务是对软件服务（例如Postgres，Redis）的一种命名抽象（named abastraction）。服务可以有各种各样的实现，但其的关键要素在于：

可以寻址访问的服务名称，用于对外提供接入，例如：
- 一个DNS域名（pg-test-primary）
- 一个Nginx/Haproxy Endpoint
服务流量路由解析与负载均衡机制，用于决定哪个实例负责处理请求，例如：
- DNS L7：DNS解析记录
- HTTP Proxy：Nginx/Ingress L7：Nginx Upstream配置
- TCP Proxy：Haproxy L4：Haproxy Backend配置
- Kubernetes：Ingress：Pod Selector 选择器。

同一个数据集簇中通常包括主库与从库，两者分别提供读写服务（primary）和只读副本服务(standby)。

实例（Instance）

实例指带一个具体的数据库服务器，它可以是单个进程，也可能是共享命运的一组进程，也可以是一个Pod中几个紧密关联的容器。实例的关键要素在于：

可以通过IP:Port唯一标识
具有处理请求的能力

例如，我们可以把一个Postgres进程，为之服务的独占Pgbouncer连接池，PgExporter监控组件，高可用组件，管理Agent看作一个提供服务的整体，视为一个数据库实例。

实例隶属于集群，每个实例在集群范围内都有着自己的唯一标识用于区分。

实例由服务负责解析，实例提供被寻址的能力，而Service将请求流量解析到具体的实例组上。

命名规则

一个对象可以有很多组 标签（Tag） 与 元数据（Metadata/Annotation） ，但通常只能有一个名字。

管理数据库和软件，其实与管理子女或者宠物类似，都是需要花心思去照顾的。而起名字就是其中非常重要的一项工作。肆意的名字（例如 XÆA-12，NULL，史珍香）很可能会引入不必要的麻烦（额外复杂度），而设计得当的名字则可能会有意想不到的效果。

总的来说，对象起名应当遵循一些原则：

简洁直白，人类可读：名字是给人看的，因此要好记，便于使用。
体现功能，反映特征：名字需要反映对象的关键特征
独一无二，唯一标识：名字在命名空间内，自己的类目下应当是独一无二，可以惟一标识寻址的。
不要把太多无关的东西塞到名字里去：在名字中嵌入很多重要元数据是一个很有吸引力的想法，但维护起来会非常痛苦，例如反例：pg:user:profile:10.11.12.13:5432:replica:13。

集群命名

集群名称，其实类似于命名空间的作用。所有隶属本集群的资源，都会使用该命名空间。

集群命名的形式，建议采用符合DNS标准 RFC1034 的命名规则，以免给后续改造埋坑。例如哪一天想要搬到云上去，发现以前用的名字不支持，那就要再改一遍名，成本巨大。

我认为更好的方式是采用更为严格的限制：集群的名称不应该包括点（dot）。应当仅使用小写字母，数字，以及减号连字符（hyphen）-。这样，集群中的所有对象都可以使用这个名称作为前缀，用于各种各样的地方，而不用担心打破某些约束。即集群命名规则为：

cluster_name := [a-z][a-z0-9-]*

之所以强调不要在集群名称中用点，是因为以前很流行一种命名方式，例如com.foo.bar。即由点分割的层次结构命名法。这种命名方式虽然简洁名快，但有一个问题，就是用户给出的名字里可能有任意多的层次，数量不可控。如果集群需要与外部系统交互，而外部系统对于命名有一些约束，那么这样的名字就会带来麻烦。一个最直观的例子是K8s中的Pod，Pod的命名规则中不允许出现.。

集群命名的内涵，建议采用-分隔的两段式，三段式名称，例如：

<集群类型>-<业务>-<业务线>

比如：pg-test-tt就表示tt 业务线下的test集群，类型为pg。pg-user-fin表示fin业务线下的user服务。当然，采集多段命名最好还是保持段数固定。

节点命名

节点命名建议采用与k8s Pod一致的命名规则，即

<cluster_name>-<seq>

Node的名称会在集群资源分配阶段确定下来，每个节点都会分配到一个序号${seq}，从0开始的自增整型。这个与k8s中StatefulSet的命名规则保持一致，因此能够做到云上云下一致管理。

例如，集群pg-test有三个节点，那么这三个节点就可以命名为：

pg-test-0, pg-test-1和pg-test2。

节点的命名，在整个集群的生命周期中保持不变，便于监控与管理。

实例命名

对于数据库来说，通常都会采用独占式部署方式，一个实例占用整个机器节点。PG实例与Node是一一对应的关系，因此可以简单地采用Node的标识符作为Instance的标识符。例如，节点pg-test-1上的PG实例名即为：pg-test-1，以此类推。

采用独占部署的方式有很大优势，一个节点即一个实例，这样能最小化管理复杂度。混部的需求通常来自资源利用率的压力，但虚拟机或者云平台可以有效解决这种问题。通过vm或pod的抽象，即使是每个redis（1核1G）实例也可以有一个独占的节点环境。

作为一种约定，每个集群中的0号节点（Pod），会作为默认主库。因为它是初始化时第一个分配的节点。

服务命名

通常来说，数据库对外提供两种基础服务：primary 读写服务，与standby只读副本服务。

那么服务就可以采用一种简单的命名规则：

<cluster_name>-<service_name>

例如这里pg-test集群就包含两个服务：读写服务pg-test-primary与只读副本服务pg-test-standby。

还有一种流行的实例/节点命名规则：<cluster_name>-<service_role>-<sequence>，即把数据库的主从身份嵌入到实例名称中。这种命名方式有好处也有坏处。好处是管理的时候一眼就能看出来哪一个实例/节点是主库，哪些是从库。缺点是一但发生Failover，实例与节点的名称必须进行调整才能维持一执性，这就带来的额外的维护工作。此外，服务与节点实例是相对独立的概念，这种Embedding命名方式扭曲了这一关系，将实例唯一隶属至服务。但复杂的场景下这一假设可能并不满足。例如，集群可能有几种不同的服务划分方式，而不同的划分方式之间很可能会出现重叠。

可读从库（解析至包含主库在内的所有实例）
同步从库（解析至采用同步提交的备库）
延迟从库，备份实例（解析至特定具体实例）

因此，不要把服务角色嵌入实例名称，而是在服务中维护目标实例列表。

小结

命名属于相当经验性的知识，很少有地方会专门会讲这件事。这种“细节”其实往往能体现出命名者的一些经验水平来。

标识对象不仅仅可以通过ID和名称，还可以通过标签（Label）和选择器（Selector）。实际上这一种做法会更具有通用性和灵活性，本系列下一篇文章（也许）将会介绍数据库对象的标签设计与管理。

微信公众号原文

PostgreSQL的KPI

管数据库和管人差不多，都需要定KPI（关键性能指标）。那么数据库的KPI是什么？本文介绍了一种衡量PostgreSQL负载的方式：使用一种单一横向可比，与负载类型和机器类型基本无关的指标，名曰PG Load（PG负载）。

著： 冯若航（@Vonng） | 2020-05-29

0x01 Introduction

在现实生产中，经常会有衡量数据库性能与负载，评估数据库水位的需求。一种最朴素的形式就是，能不能有一个类似于KPI的单一指标，能直接了当地告诉用户他心爱的数据库负载有没有超过警戒线？工作量到底饱和不饱和？

当然这里其实隐含着一个重要信息，即用户期待的负载指标是一个饱和度（Saturation）指标，所谓饱和度，即服务容量有多”满“，通常是系统中目前最为受限的某种资源的某个具体指标的度量。通常来说，0%的饱和度意味着系统完全空闲，100%的饱和度意味着满载，系统在达到100%利用率前就会出现性能的严重下降，因此设定指标时还需要包括一个利用率目标，或者说水位红线、黄线，当系统瞬时负载超过红线时应当触发告警，长期负载超过黄线时应当进行扩容。

不幸的是，定义系统有多”饱和“并不是一件容易的事情，往往需要借助某些间接指标。评估一个数据库的负载程度，传统上通常会基于这样几类指标进行综合评估：

流量：每秒查询数量QPS，或每秒事务数量TPS。
延迟：查询平均响应时间 Query RT，或事务平均响应时间Xact RT
饱和度：机器负载（Load），CPU使用率，磁盘读写带宽饱和度，网卡IO带宽饱和度
错误：数据库客户端连接排队

这些指标对于数据库性能评估都很有参考意义，但它们也都存在各式各样的问题。

0x02 常用评估指标的问题

让我们来看一看，这些现有的常用指标都有哪些问题。

第一个Pass的当然是错误类指标，譬如连接池排队。错误类指标最大的问题就是，当错误出现时，饱和度可能已经没有意义了。评估饱和度的一个重要原因就是用于预防系统过载，如果系统已经过载大量报错，那么使用错误现象反过来定义饱和度是没有意义的。此外，错误类指标难以精确量化。我们只能说：当连接池出现排队时，数据库负载比较大；队列越长，负载越大；没有排队时，数据库负载不怎么大，仅此而已。这样的定义当然也无法让人满意。

第二个Pass的则是系统层（机器级别）指标，数据库运行在机器上，CPU使用率，IO使用率这样的指标与数据库负载程度密切相关，如果CPU和IO是瓶颈，理论上当然是可以直接使用瓶颈资源的饱和度指标作为数据库的饱和指标，但这一点并非总是成立的，有可能系统瓶颈在于数据库本身。而且严格来说它们是机器的KPI而不是DB的KPI，评估数据库负载时当然可以参照系统层的指标，但DB层也应该有本层的评估指标。要先有数据库本身的饱和度指标，才可以去比较底层资源和数据库本身到底谁先饱和谁是瓶颈。这条原则同样适用于应用层观察到的指标。

流量类的指标很有潜力，特别是QPS，TPS这样的指标相当具有代表性。但这些指标也存在问题。一个数据库实例上的查询往往是五花八门各式各样的，一个耗时10微秒的查询和一个10秒的查询在统计时都被算为一个Q，类似于QPS这样的指标无法进行横向比较，只有比较粗略的参考意义，甚至当查询类型发生变化时，都无法和自己的历史数据进行纵向比较。此外也很难针对QPS、TPS这样的指标设置利用率目标，同一个数据库执行SELECT 1可以打到几十万的QPS，但执行复杂SQL时可能就只能打到几千的QPS。不同负载类型和机器硬件会对数据库的QPS上限产生显著影响，只有当一个数据库上的查询都是高度单一同质且没有复杂变化的条件下，QPS才有参考意义，在这种苛刻条件下倒是可以通过压力测试设定一个QPS的水位目标。

这里把常用指标都批判了一番，到底什么样的指标适合作为数据库本身的饱和度呢？

0x03 衡量PG的负载

我们不妨参考一下**机器负载（Node Load）和CPU利用率（CPU Utilization）**的评估指标是如何设计的。

机器负载（Node Load）

想要看到机器的负载水平，可以在Linux系统中使用top命令。top命令的第一行输出就醒目地打印出当前机器1分钟，5分钟，15分钟的平均负载水平。

$ top -b1
top - 19:27:38 up 18:49,  1 user,  load average: 1.15, 0.72, 0.71

这里load average后面的三个数字分别表示最近1分钟，5分钟，15分钟系统的平均负载水平。

那么这个数字到底是什么意思呢？简单的解释是，这个数字越大机器越忙。

在单核CPU的场景下，Node Load（以下简称负载）是一个非常标准的饱和度指标。对于单核CPU，负载为0时CPU处于完全空闲的状态，负载为1（100%）时，CPU正好处于满载工作的状态。负载大于100%时，超出100%部分比例的任务正在排队。

Node Load也有自己的利用率目标，通常的经验是在单核情况下：0.7（70%）是黄线，意味着系统有问题，需要尽快检查；1.0（100%）是红线，负载大于1意味着进程开始堆积，需要立即着手处理。5.0（500%）是死线，意味着系统基本上已经堵死了。

对于多核CPU，事情稍微有点不一样。假设有n个核，那么当系统负载为n时，所有CPU都处于满载工作的状态；而当系统负载为n/2时，姑且可以认为一半CPU核正在满载运行。因而48核CPU的机器满载时的负载为48。总的来说，如果我们把机器负载除以机器的CPU核数，得到的指标就与单核场景下保持一致了（0%空载，100%满载）。

CPU利用率（CPU Utilization）

另一个很有借鉴意义的指标是CPU利用率（CPU Utilization）。CPU利用率其实是通过一个简单的公式计算出来的，对于单核CPU：

1 - irate(node_cpu_seconds_total{mode="idle"}[1m]

这里node_cpu_seconds_total{mode="idle"}是一个计数器指标，表示CPU处于空闲状态的总时长。irate函数会用该指标对时间进行求导，得出的结果是，每秒CPU处于空闲状态的时长，换句话说也就是CPU空闲率。用1减去该值就得到了CPU的利用率。

对于多核CPU来说，只需要把每个CPU核的利用率加起来，除以CPU的核数，就可以得到CPU的整体利用率。

那么这两个指标对于PG的负载又有什么借鉴意义呢？

数据库负载（PG Load）

PG的负载是不是也可以采用类似于CPU利用率和机器负载的方式来定义？当然可以，而且这是一个极棒的主意。

让我们先来考虑单进程情况下的PG负载，假设我们需要这样一个指标，当该PG进程完全空闲时负载因子为0，当该进程处于满载状态时负载为1（100%）。类比CPU利用率的定义，我们可以使用“单个PG进程处于活跃状态的时长占比”来表示“单个PG后端进程的利用率”。

如图1所示，在一秒的统计周期内，PG处于活跃（执行查询或者执行事务）状态的时长为0.6秒，那么这一秒内的PG负载就是60%。如果这个唯一的PG进程在整个统计周期中都处于忙碌状态，而且还有0.4秒的任务在排队，如那么就可以认为PG的负载为140%。

对于并行场景，计算方法与多核CPU的利用率类似，首先把所有PG进程在统计周期（1s）内处于活跃状态的时长累加，然后除以“可用的PG进程/连接数”，或者说“可用并行数”，即可得到PG本身的利用率指标，如图3所示。两个PG后端进程分别有200ms+400ms与800ms的活跃时长，那么整体的负载水平为：(0.2s + 0.4s + 0.8s) / 1s / 2 = 70%

总结一下，某一段时间内PG的负载可以定义为：

pg_load = pg_active_seconds / time_peroid / parallel

pg_active_seconds是该时间段内所有PG进程处于活跃状态的时长之和。
time_peroid是负载计算的统计周期，通常为1分钟，5分钟，15分钟，以及实时（小于10秒）。
parallel 是PostgreSQL的可用并行数，后面会详细解释。

因为前两项之商实际上就是一段时间内的每秒活跃时长总数，因此这个公式进一步可以简化为活跃时长对时间的导数除以可用并行数，即：

rate(pg_active_seconds[time_peroid]) / parallel

time_peroid通常是固定的常量（1，5，15分钟），所以问题就是如何获取PG进程活跃总时长pg_active_seconds这个指标，以及如何评估计算数据库可用并行数max_parallel 了。

0x04 计算PG的负载饱和度

事务还是查询？

当我们说数据库进程活跃/空闲时，究竟在说什么？ PG处于活跃状态，到底是什么意思？如果PG后端进程正在执行查询，那么当然可以认为PG正处于忙碌状态。但如果如上图4所示，PG进程正在执行一个交互式事务，但没有实际执行查询，即所谓的“Idle in Transaction”状态，又应该怎么计算“活跃时长”呢？图4中两个查询中空闲的那200ms时间。那么这段时间应该算作“活跃”，还是算作“空闲”呢？

这里的核心问题是怎么定义活跃状态：数据库进程位于事务中算活跃，还是只有当实际执行查询时才算活跃。对于没有交互式事务的场景，一个查询就是一个事务，用哪种方式都一样，但对于多语句，特别是交互式的多语句事务，这两者就有比较明显的区别了。从资源使用的角度看，没有执行查询也就意味着没有消耗数据库本身的资源。但空闲着的事务本身会占用连接导致连接无法复用，Idle In Transaction本身也应当是一种极力避免的情况。总的来说，这两种定义方式都可以，使用事务的方式会略微高估应用负载，但从负载评估的角度可能会更为合适。

如何获取活跃时长

决定了数据库后端进程的活跃定义后，第二个问题就是，如何获取一段时间的数据库活跃时长？不幸的是在PG中，用户很难通过数据库本身获取这一性能指标。PG提供了一个系统视图：pg_stat_activity，可以看到当前运行着的Postgres进程里列表，但这是一个时间点快照，只能大致告诉在当前时刻，数据库的后端进程中有多少个处于活跃状态，有多少个处于空闲状态。统计一段时间内数据库处于活跃状态的时长，就成了一个难题。一种解决方案是使用类似于Load的计算方式，通过周期性地采样PG中活跃进程的数量，计算出一个负载指标来。不过，这里有更好的办法，但是需要中间件的协助参与。

数据库中间件对于性能监控非常重要，因为很多指标数据库本身并没有提供，只有通过中间件才能暴露出来。以Pgbouncer为例，Pgbouncer在内部维护了一系列统计计数器，使用SHOW STATS可以打印出这些指标，诸如：

total_xact_count：总共执行了多少个事务
total_query_count：总共执行了多少个查询
total_xact_time：总共花费在事务执行的时长
total_query_time：总共花费在查询执行上的时长

这里total_xact_time就是我们需要的数据，它记录了Pgbouncer中间件中花费在某个数据库上的事务总耗时。我们只需要用这个指标对时间求导，就可以得到想要的数据：每秒活跃时长占比。

这里使用Prometheus的PromQL表达计算逻辑，首先对事务耗时计数器求导，分别算出其1分钟，5分钟，15分钟，以及实时粒度（最近两次采样点之间）上的每秒活跃时长。再上卷求和，将数据库层次的指标上卷为实例级别的指标。（连接池SHOW STATS这里的统计指标是以数据库为单位的，因此在计算实例级别的总活跃时长时，应当上卷求和，消除数据库维度的标签：sum without(datname)）

- record: pg:ins:xact_time_realtime
expr: sum without (datname) (irate(pgbouncer_stat_total_xact_time{}[1m]))
- record: pg:ins:xact_time_rate1m
expr: sum without (datname) (rate(pgbouncer_stat_total_xact_time{}[1m]))
- record: pg:ins:xact_time_rate5m
expr: sum without (datname) (rate(pgbouncer_stat_total_xact_time{}[5m]))
- record: pg:ins:xact_time_rate15m
expr: sum without (datname) (rate(pgbouncer_stat_total_xact_time{}[15m]))

这样计算得到的结果指标已经可以相对本身进行纵向比较，并在同样规格的实例间进行横向比较了。而且无论数据库的负载类型怎样，都可以使用这个指标。

不过不同规格的实例，仍然没法使用这个指标进行对比。比如对于单核单连接PG，满载时每秒活跃时长可能是1秒，也就是100%利用率。而对于64核64连接的PG，满载时每秒活跃时长是64秒，那么就是6400%的利用率。因此，还需要一个归一化的处理，那么问题又来了。

可用并行数如何定义？

不同于CPU利用率，PG的可用并行数并没有一个清晰的定义，而且跟负载类型有一些微妙的关系。但能够确定的是，在一定范围内，最大可用并行与CPU的核数呈粗略的线性关系。当然这个结论的前提是数据库最大连接数显著超过CPU核数，如果在64核的CPU上只允许数据库建立30条连接，那么可以肯定最大可用并行就是30而不是CPU核数64。软件的并行最终还是要由硬件的并行度来支撑，因此我们可以简单的使用实例的CPU核数作为可用并行数。

在64核的CPU上运行64个活跃PG进程，则其负载为（6400% / 64 = 100%）。同理运行128个活跃PG进程，负载就是（12800% / 64 = 200%）。

那么利用上面计算得到的每秒活跃时长指标，就可以计算出实例级别的PG负载指数了。

- record: pg:ins:load0
expr:  pg:ins:xact_time_realtime / on (ip) group_left()  node:ins:cpu_count
- record: pg:ins:load1
expr: pg:ins:xact_time_rate1m  / on (ip) group_left()  node:ins:cpu_count
- record: pg:ins:load5
expr: pg:ins:xact_time_rate5m  / on (ip) group_left()  node:ins:cpu_count
- record: pg:ins:load15
expr: pg:ins:xact_time_rate15m  / on (ip) group_left()  node:ins:cpu_count

PG LOAD的另一种解释

如果我们仔细审视PG Load的定义，其实可以发现每秒活跃时长这个指标，其实可以粗略等价于：TPS x XactRT，或者QPS x Query RT。这个也很好理解，假设我QPS为1000，每个查询RT为1ms，则每秒花费在查询上的时间为 1000 * 1ms = 1s。

因此，PG Load可以视为一个由三个核心指标复合而成的衍生指标：tps * xact_rt / cpu_count

TPS，RT用于负载评估都有各自的问题，但它们通过简单的乘法结合成一个新的复合指标，一下子就显示出了神奇的力量。（尽管实际上是通过其他更准确的方式计算出来的）

0x05 PG Load的实际效果

接下来，我们来看一下PG Load用于实际生产环境的表现。

PG Load最直接的作用有两个，告警以及容量评估。

Case 1: 用于报警：慢查询堆积导致的服务不可用

下图是一次生产事故的现场，由于某业务上线了一个慢查询，瞬间导致连接池被慢查询占据，发生堆积。可以看出PG Load和RT都很及时地反映出了故障的情况，而TPS看上去则是掉了一个坑，并不是特别显眼。

从效果上看，PG Load1与PG Load0（实时负载）是一个相当灵敏的指标，对于大多数与压力负载有关的故障都能及时准确作出反应。所以被我们采纳为核心报警指标。

PG Load的利用率目标有一些经验值：黄线通常为50%，即需要引起关注的阈值；红线通常为70%，即报警线，需要立刻采取行动的阈值；500%或更高通常意味着这个实例已经被打崩了。

Case 2：用于水位评估与容量规划

比起报警，水位评估与容量规划更像是PG Load的核心用途。毕竟报警之类的的需求还是可以通过延迟，排队连接等指标来满足的。

这里，PG集群的15分钟负载是一个很好的参考值。通过这个指标的历史均值，峰值，以及其他一些统计量，我们可以很轻松地看出哪些集群处于高负载状态需要扩容，哪些集群处于低资源利用率状态需要缩容。

CPU利用率是另一个很重要的容量评估指标。我们可以看出，PG Load与CPU Usage有着很密切的关系。不过相比CPU使用率，PG Load更为纯粹地反映了数据库本身的负载水平，滤除了机器上的无关负载，也可以滤除掉数据库维护工作（备份，清理，垃圾回收）产生的杂音，更为丝滑平顺。因此非常适合用于容量评估。

当系统负载长期位于30%~50%时，就应该考虑进行扩容了。

0x06 结论

本文介绍了一种定量衡量PG负载的方式，即PG Load指标

该指标可以简单直观地反映数据库实例的负载水平

该指标非常适合作容量评估之用，也可以作为核心报警指标。

该指标可以基本无视负载类型与机器类型，进行纵向历史比较与横向水位比较。

该指标可以通过简单的方式计算得出，即每秒后端进程活跃总时长除以可用并发数。

该指标所需数据需要从数据库中间件获取

PG Load的0代表空载，100%代表满载。黄线经验值为50%，红线经验值为70%，

PG Load是一个好指标👍

微信公众号原文

在线修改PG字段类型

如何在线修改PostgreSQL中的字段类型？一种通用方法

著： 冯若航（@Vonng） | 2020-01-30

场景

在数据库的生命周期中，有一类需求是很常见的，修改字段类型。例如：

使用INT作为主键，结果发现业务红红火火，INT32的21亿序号不够用了，想要升级为BIGINT
使用BIGINT存身份证号，结果发现里面有个X需要改为TEXT类型。
使用FLOAT存放货币，发现精度丢失，想要修改为Decimal
使用TEXT存储JSON字段，想用到PostgreSQL的JSON特性，修改为JSONB类型。

那么，如何应对这种需求呢？

常规操作

通常来说，ALTER TABLE可以用来修改字段类型。

ALTER TABLE tbl_name ALTER col_name TYPE new_type USING expression;

修改字段类型通常会重写整个表。作为一个特例，如果修改后的类型与之前是二进制兼容的，则可以跳过表重写的过程，但是如果列上有索引，索引还是需要重建的。二进制兼容的转换可以使用以下查询列出。

SELECT t1.typname AS from, t2.typname AS To
FROM pg_cast c
         join pg_type t1 on c.castsource = t1.oid
         join pg_type t2 on c.casttarget = t2.oid
where c.castmethod = 'b';

刨除PostgreSQL内部的类型，二进制兼容的类型转换如下所示

text     → varchar 
xml      → varchar 
xml      → text    
cidr     → inet    
varchar  → text    
bit      → varbit  
varbit   → bit

常见的二进制兼容类型转换基本就是这两种：

varchar(n1) → varchar(n2) （n2 ≥ n1）（比较常用，扩大长度约束不会重写，缩小会重写）
varchar ↔ text （同义转换，基本没啥用）

也就是说，其他的类型转换，都会涉及到表的重写。大表的重写是很慢的，从几分钟到十几小时都有可能。一旦发生重写，表上就会有AccessExclusiveLock，阻止一切并发访问。

如果是一个玩具数据库，或者业务还没上线，或者业务根本不在乎停机多久，那么整表重写的方式当然是没有问题的。但绝大多数时候，业务根本不可能接受这样的停机时间。所以，我们需要一种在线升级的办法。在不停机的情况完成字段类型的改造。

基本思路

在线改列的基本原理如下：

创建一个新的临时列，使用新的类型
旧列的数据同步至新的临时列
- 存量同步：分批更新
- 增量同步：更新触发器
处理列依赖：索引
执行切换
- 处理列以来：约束，默认值，分区，继承，触发器
- 通过列重命名的方式完成新旧列切换

在线改造的问题在于锁粒度拆分，将原来一次长期重锁操作，等效替代为多个瞬时轻锁操作。

原来ALTER TYPE重写过程中，会加上AccessExclusiveLock，阻止一切并发访问，持续时间几分钟到几天。

添加新列：瞬间完成：AccessExclusiveLock
同步新列-增量：创建触发器，瞬间完成，锁级别低。
同步新列-存量：分批次UPDATE，少量多次，每次都能快速完成，锁级别低。
新旧切换：锁表，瞬间完成。

让我们用pgbench的默认用例来说明在线改列的基本原理。假设我们希望在pgbench_accounts有访问的情况下修改abalance字段类型，从INT修改为BIGINT，那么应该如何处理呢？

首先，为pgbench_accounts创建一个名为abalance_tmp，类型为BIGINT的新列。
编写并创建列同步触发器，触发器会在每一行被插入或更新前，使用旧列abalance同步到

详情如下所示：

-- 操作目标：升级 pgbench_accounts 表普通列 abalance 类型：INT -> BIGINT

-- 添加新列：abalance_tmp BIGINT
ALTER TABLE pgbench_accounts ADD COLUMN abalance_tmp BIGINT;

-- 创建触发器函数：保持新列数据与旧列同步
CREATE OR REPLACE FUNCTION public.sync_pgbench_accounts_abalance() RETURNS TRIGGER AS $$
BEGIN NEW.abalance_tmp = NEW.abalance; RETURN NEW;END;
$$ LANGUAGE 'plpgsql';

-- 完成整表更新，分批更新的方式见下
UPDATE pgbench_accounts SET abalance_tmp = abalance; -- 不要在大表上运行这个

-- 创建触发器
CREATE TRIGGER tg_sync_pgbench_accounts_abalance BEFORE INSERT OR UPDATE ON pgbench_accounts
    FOR EACH ROW EXECUTE FUNCTION sync_pgbench_accounts_abalance();

-- 完成列的新旧切换，这时候数据同步方向变化 旧列数据与新列保持同步
BEGIN;
LOCK TABLE pgbench_accounts IN EXCLUSIVE MODE;
ALTER TABLE pgbench_accounts DISABLE TRIGGER tg_sync_pgbench_accounts_abalance;
ALTER TABLE pgbench_accounts RENAME COLUMN abalance TO abalance_old;
ALTER TABLE pgbench_accounts RENAME COLUMN abalance_tmp TO abalance;
ALTER TABLE pgbench_accounts RENAME COLUMN abalance_old TO abalance_tmp;
ALTER TABLE pgbench_accounts ENABLE TRIGGER tg_sync_pgbench_accounts_abalance;
COMMIT;

-- 确认数据完整性
SELECT count(*) FROM pgbench_accounts WHERE abalance_new != abalance;

-- 清理触发器与函数
DROP FUNCTION IF EXISTS sync_pgbench_accounts_abalance();
DROP TRIGGER tg_sync_pgbench_accounts_abalance ON pgbench_accounts;

注意事项

ALTER TABLE的MVCC安全性
列上如果有约束？（PrimaryKey、ForeignKey，Unique，NotNULL）
列上如果有索引？
ALTER TABLE导致的主从复制延迟

PostgreSQL标准复制方案

复制是系统架构中的核心问题之一。

著： 冯若航（@Vonng） | 2019-03-29

复制是系统架构中的核心问题之一。

集群拓扑

假设我们使用4单元的标准配置：主库，同步从库，延迟备库，远程备库，分别用字母M,S,O,R标识。

M：Master, Main, Primary, Leader, 主库，权威数据源。
S: Slave, Secondary, Standby, Sync Replica，同步副本，需要直接挂载至主库
R: Remote Replica, Report instance，远程副本，可以挂载到主库或同步从库上
O: Offline，离线延迟备库，可以挂载到主库，同步从库，或者远程备库上。

依照R和O的挂载目标不同，复制拓扑关系有以下几种选择：

其中，拓扑2具有显著的优越性：

假设采用同步提交，那么为了安全起见，必须有超过一个的同步从库，这样当采用ANY 1或FIRST 1同步提交时，主库不至于因为从库故障而挂掉。因此，离线库O应当直接挂载到主库上：在具体实现细节上：延迟备库可以采用日志传输的方式实现，这样能够将线上库与延迟库解耦。日志归档使用自带的pg_receivewal采用同步的方式（即pg_receivewal作为一个“备库”，而不是离线数据库实例本身）。

另一方面，当使用同步提交时，假设M出现故障，Failover至S，那么S也需要一个同步从库，以免在切换后立刻因为同步提交而Hang住，因此远程备库适合挂载到S上。

故障恢复

当故障发生时，我们需要尽可能快地将生产系统救回来，例如通过Failover，并在事后有时间时恢复原有的拓扑结构。

P0：（M）主库失效，应当在秒级到分钟级内恢复
P1：（S）从库失效，影响只读查询，但主库可以先抗，可以容忍分钟级别到小时级别的问题。
P2：（O，R）离线库与远程备库故障，可能没有直接影响，故障容忍范围可以放宽至小时到天级别。

![](

当M失效时，会对所有组件产生影响。需要执行故障转移（Failover）将S提升为新的M以便尽快使系统恢复。手工Failover包括两个步骤：Fencing M（由重到轻：关机，关数据库，改HBA，关连接池，暂停连接池）与Promote S，这两个操作都可以通过脚本在很短的时间内完成。Failover之后，系统基本恢复。还需要在事后重新恢复原来的拓扑结构。例如将原有的M通过pg_rewind变为新的从库，将O挂载到新的M上，将R挂载到新的S上；或者在修复M后，通过计划内的Failover再次回归原有拓扑。

当S失效时，会对R产生直接影响。作为一种HotFix，我们可以将R的复制源由S改到M，即可将R的影响修复。同时，通过连接池倒流将S的原有流量分发至其他从库或M，接下来就可以慢慢研究并修复S上的问题了。

当O和R失效时，因为它们既没有很大的直接影响，也没有直属后代，因此只要重做一个即可。

实施方式

PostgreSQL Testing Environment 这里给出了一个3节点的样例集群，包含了M，S，O三个节点。R节点是S的一种，因此在此略过。

这里，主库直接挂载了两个“从库”，一个是S节点，一个是O节点上的WAL日志归档器。在丢数据容忍度很低的情况下，可以将两者配置为同步从库。

PgSQL备份方案

备份有各种各样的策略，物理备份通常可以分为四种。

著： 冯若航（@Vonng） | 2019-03-02

备份是DBA的安身立命之本，也是数据库管理中最为关键的工作之一。有各种各样的备份，但今天这里讨论的备份都是物理备份。物理备份通常可以分为以下四种：

热备（Hot Standby）：与主库一模一样，当主库出现故障时会接管主库的工作，同时也会用于承接线上只读流量。
温备（Warm Standby）：与热备类似，但不承载线上流量。通常数据库集群需要一个延迟备库，以便出现错误（例如误删数据）时能及时恢复。在这种情况下，因为延迟备库与主库内容不一致，因此不能服务线上查询。
冷备（Code Backup）：冷备数据库以数据目录静态文件的形式存在，是数据库目录的二进制备份。便于制作，管理简单，便于放到其他AZ实现容灾。是数据库的最终保险。
异地副本（Remote Standby）：所谓X地X中心，通常指的就是放在其他AZ的热备实例。

通常我们所说的备份，指的是冷备和温备。它们与热备的重要区别是：它们通常不是最新的。当服务线上查询时，这种滞后是一个缺陷，但对于故障恢复而言，这是一个非常重要的特性。同步的备库是不足以应对所有的问题。设想这样一种情况：一些人为故障或者软件错误把整个数据表甚至整个数据库删除了，这样的变更会立刻应用到同步从库上。这种情况只能通过从延迟温备中查询，或者从冷备重放日志来恢复。因此无论有没有从库，冷/温备都是必须的。

参考：PostgreSQL复制方案

温备方案

通常我比较建议采用延时日志传输备库的方式做温备，从而快速响应故障，并通过异地云存储冷备的方式做容灾。

温备方案有一些显著的优势：

可靠：温备实际上在运行过程中，就在不断地进行“恢复测试”，因此只要温备工作正常没报错，你总是能够相信它是一个可用的备份，但冷备就不一定了。同时，采用同步提交pg_receivewal与日志传输的离线实例，一方面能够降低主库因为单一同步从库故障而挂点的风险，另一方面也消除了备库活动影响主库的风险。
管理简单：温备的管理方式基本与普通从库类似，因此如果已经有了主从配置，部署一个温备是很简单的事；此外，用到的工具都是PostgreSQL官方提供的工具：pg_basebackup与pg_receivewal。温备的延时窗口可以通过参数简单地调整。
响应快速：在延迟备库的延时窗口内发生的故障（删库），都可以快速地恢复：从延迟备库中查出来灌回主库，或者直接将延迟备库步进至特定时间点并提升为新主库。同时，采用温备的方式，就不用每天或每周从主库上拉去全量备份了，更省带宽，执行也更快。

步骤概览

日志归档

如何归档主库生成的WAL日志，传统上通常是通过配置主库上的archive_command实现的。不过最近版本的PostgreSQL提供了一个相当实用的工具：pg_receivewal（10以前的版本称为pg_receivexlog）。对于主库而言，这个客户端应用看上去就像一个从库一样，主库会不断发送最新的WAL日志，而pg_receivewal会将其写入本地目录中。这种方式相比archive_command的一个显著优势就是，pg_receivewal不会等到PostgreSQL写满一个WAL段文件之后再进行归档，因此可以在同步提交的情况下做到故障不丢数据。

pg_receivewal使用起来也非常简单：

# create a replication slot named walarchiver
pg_receivewal --slot=walarchiver --create-slot --if-not-exists

# add replicator credential to /home/postgres/.pgpass 0600
# start archiving (with proper supervisor/init scritpts)
pg_receivewal \
  -D /pg/arcwal \
  --slot=walarchiver \
  --compress=9\
  -d'postgres://replicator@master.csq.tsa.md/postgres'

当然在实际生产环境中，为了更为鲁棒地归档，通常我们会将其注册为服务，并保存一些命令状态。这里给出了生产环境中使用的一个pg_receivewal命令包装：walarchiver

备份测试

面对故障时如何充满信心？只要备份还在，再大的问题都能恢复。但如何确保你的备份方案真正有效，这就需要我们事先进行充分的测试。

让我们来设想一些故障场景，以及在本方案下应对这些故障的方式

pg_receive进程终止
离线节点重启
主库节点重启
干净的故障切换
脑裂的故障切换
误删表一张
误删库

To be continue

PgSQL报警方案

报警是很重要的！

著： 冯若航（@Vonng） | 2019-01-02

Why

Alert is critical to Operations, It makes OPS

Response in Time
EventDriven instead of Polling

It is a fundamental part of Ops system. A robust system need a a proper alert system rather than waiting final user telling us there is a failure. We have a vivid case right in front of us.

In a naivel case, Failure handling would be like this:

Factory production line halt, BizLevel Failure occur, TPM look into that, figure whether it’s because of it’s own problem, then found it’s because of trace system down, then he calls backend developers
Backend developers find that Application is down, then look into it, Try to figure what is the cause of application failure, After looking into that, he found it is because of database unreachable. Then he calls DBA.
DBA find that database is down, He tries to figure it whether it is because of database itself (like slow queries, traffic jam, data corruption). After looking into it, He figure out it is because of physical machine is Down, then he calls to OPS
OPS figure out that machine is down, He manage to fix it or wait it to be fixed.

While the ideal case would be

When something like primary machine down happens, TPM, DEV, DBA, OPS all get alert notifications and their corresponding levels.

When machine is down, The OPS knows it immediately (like after 1 min, triggers OPS_NODE_UNREACHABLE)
OPS inform DBA: our nodes is down, prepare for failover xxxxx. (and DBA may already receive alert and get hands on it because he receives DB Level alerts DB_PRIMARY_POSTGRES_DOWN)
DBA notify DEV: database is going to failover, beware of xxxxxx (and Dev may already prepare for it because of App Level alert: APP_REQUEST_DROP_50_PERCENT)
DEV notify TPM, our service is going to be down for xxxx, beware of that. (And TPM may already prepare for notifications because he received Biz Level Alert BIZ_PROCESS_CONTRONL_FAIL_RATE_HIGH )

It’s a bottom-to-top procedure, Where the alert information is pass to different levels simultaneously. So the DRI need not wait until information is passed through a long chain to his layer. The responding time may reduce to 1~5minutes rather than 1~2 hours.

How

So how can we setup an alerting system ?

To setup the infrastructure is very simple, Prometheus & It’s Alertmanager is enough for most common cases. While constructing an alerting system is not. because it is more about organization and responsibilities.

Infrastructure

For the infrastructure part, we already have prometheus, the only thing todo is add alerting rules to

prometheus.yml

Specify RULES

Prometheus itself can evaluate rules and generate alert. add following config entries to prometheus.yml

alerting:
  alertmanagers:
  - static_configs:
    - targets: 'http://localhost:9093'

rule_files:
  - "alert.rules"

And then put your own specific alert.rules to another conf file, things done.

Through prometheus UI - Alert Tab, You can view alerts status.

alertmanage is responsible for gather, merge , silence, mange, notify alerts, Firing alert is handled by prometheus itself.

Define Alert

Before defining any specific alert event, We need categorize them first.

All alert events can be categorized via two demension:

Respondent : Who is responsible for that alert (OPS/DBA/DEV/TPM)
urgency: What is the pirority of that (P2/P1/P0)

A common practice is: Split

respondent

into different level groups: System/Database/Application

DevOps team is responsible for System Alert, such as AppDown, Node, Disk, Network, Infrastructure…
DBA team is responsible for DB specifict Alerts (DB Down, CPU, RAM, Activity, Queing, SlowQuery,….)
Backend is responsible for Application Layer Error (HTTP5XX, RequestDrop,HighErrRate,…)
You may have another layer for Biz Layer TPM ( ProductionLineDown, ScrapeRateHigh, ProcessControlFailRateHigh )

The basic princple is that the

respondent team have enough privilege and ability to resolve the alert

And alerts can be categorized as three different priority levels:

P0: Service down, have actuall failure, impact , Loss.
P1: Service degrade, High Potential Cause Failure if Leave it for a while (hours).
P2: Service anomaliesthat needs attention, May cause service degrade if leave it for serval days

DB Alerts

Talk is cheap, Here I will take DB Alert as an example. We can define following alert event for database:

P0 DB_PRIMARY_POSTGRES_DOWN
P0 DB_PRIMARY_PGBOUNCER_DOWN

P1 DB_STANDBY_POSTGRES_DOWN
P1 DB_STANDBY_PGBOUNCER_DOWN
P1 DB_CPU_USAGE_HIGH
P1 DB_RAM_USAGE_HIGH
P1 DB_DISK_USAGE_HIGH
P1 DB_REPLCATION_LAG_HIGH
P1 DB_AGE_HIGH
P1 DB_SESSION_ACTIVE_HIGH
P1 DB_SESSION_IDLE_IN_XACT_HIGH
P1 PG_AVERAGE_QUERY_SLOW

P2 DB_CPU_USAGE_WARN
P2 DB_CPU_ONE_CORE_HIGH
P2 DB_RAM_USAGE_WARN
P2 DB_DISK_USAGE_WARN
P2 DB_REPLCATION_LAG_WARN
P2 DB_AGE_WARN
P2 PG_BACKUP_FAILURE
P2 PG_VACUUM_FAILURE
P2 PG_REPACK_FAILURE

Where the only P0 is DB_PRIMARY_POSTGRES_DOWN and DB_PRIMARY_PGBOUNCER_DOWN, which introduce direct impact to users. This will triggers phone call to every respondent.

P1 alert is event/phenomena which may cause P0. Including: StandbyDown, CPU, RAM, DiskSpace, ReplicationDelay, DatabaseAge, TrafficJam, SlowQuery, TooMuchConnection, and a lot other stuffs. If you leave a P1 alert there, The situation may degrade into P0 failure in serval minutes or hours. This would triggers phone call or sms to on call respondent.

P2 alert is quite like anomalies notification, If you leave P2 alert there , it may grows to P1 in serval days. Usually triggers email report to notify DBA.

Example

For example, the only P0 case of Database is Primary DB Down, which could be determined by prometheus alert rule:

ALERT POSTGRES_PRIMARY_DOWN
IF avg_over_time(up{instance=~"(.*primary.csq.*)",service_port=~"(9127|9187)"}[2m]) < 0.3
FOR 2m
LABELS {team="dba",urgency="P0"}
ANNOTATIONS {description="POSTGRES_PRIMARY_DOWN, {{ $value }}% , {{ $labels.instance }} ",summary="P0_POSTGRES_PRIMARY_DOWN_CSQ, {{ $value }}% , {{ $labels.instance }} "}

That means in last 2 minutes, if the average up time is less than 30% and last for 2 minutes, from (postgres_exporter(9187)|pgbouncer_exporter(9127)). It will trigger a P0 error.

While if a non-primary instance is down, it is a P1 rather than P0. which would be like:

ALERT POSTGRES_STANDBY_DOWN_FKS
IF avg_over_time(up{instance=~"(.*standby.fks.*)",service_port=~"(9127|9187)"}[2m]) < 0.3
FOR 2m
LABELS {team="dba",urgency="P1"}
ANNOTATIONS {description="POSTGRES_STANDBY_DOWN_FKS, {{ $value }}% , {{ $labels.instance }} ",summary="POSTGRES_STANDBY_DOWN_FKS, {{ $value }}% , {{ $labels.instance }} "}

And another example of P1 is

DB_CUP_ALL_CORE_HIGH
ALERT DB_CPU_ALL_CORE_HIGH
IF 1-avg(rate(node_cpu{mode="idle",role=~".*(primary|standby).*",role!~".*statsdb.*"}[1m])) BY (instance, role) > 0.5
FOR 1m
LABELS {team="dba", urgency="P1"}
ANNOTATIONS {description="DB_CPU_ALL_CORE_HIGH, {{ $value}}% , {{ $labels.instance }}, {{ $labels.role }}", summary="DB_CPU_ALL_CORE_HIGH, {{ $value}}% , {{ $labels.instance }}, {{ $labels.role }}"}

This will check all primary/standby (online) instance, And if the average CPU Usage is above 50% continuesly for 1 minute, it will trigger a P1 DB_CUP_ALL_CORE_HIGH Alert. But that does not check DB for statistic OLAP usages (because their CPU high is a normal case)

RULES

So here are the example rules for databases:

groups:
- name: db-alerts
  rules:
  - alert: DB_POSTGRES_PRIMARY_DOWN
    expr: avg_over_time(pg_up{instance=~"(.*primary.*pg)"}[2m]) < 0.3
    for: 2m
    labels:
      team: DBA
      urgency: P0
    annotations:
      summary: "{{$labels.instance}} DB Postgres Primary Down: {{ $value }}"
      description: "{{$labels.instance}} DB Postgres Primary Down: {{ $value }}"

  - alert: DB_STANDBY_POSTGRES_DOWN
    expr: avg_over_time(pg_up{instance=~".*(standby|offline).*pg"}[2m]) < 0.3
    for: 2m
    labels:
      team: DBA
      urgency: P1
    annotations:
      summary: "{{$labels.instance}} DB Postgres Standby Down: {{ $value }}"
      description: "{{$labels.instance}} DB Postgres Standby Down: {{ $value }}"


  - alert: DB_CPU_USAGE_HIGH
    expr: 1 - avg(rate(node_cpu_seconds_total{mode="idle",instance=~".*pg.*"}[1m])) BY (instance) > 0.5
    for: 2m
    labels:
      team: DBA
      urgency: P1
    annotations:
      summary: "{{$labels.instance}} CPU Usage High: {{ $value }}"
      description: "{{$labels.instance}} CPU All Core Usage Higher than 50% percent: {{ $value }}"

  - alert: DB_RAM_USAGE_HIGH
    expr: (node_memory_Buffers_bytes{instance=~".*pg.*"} + node_memory_MemFree_bytes{instance=~".*pg.*"} +  node_memory_Cached_bytes{instance=~".*pg.*"}) /  node_memory_MemTotal_bytes{instance=~".*pg.*"} < 0.1 and rate(node_memory_SwapFree_bytes{instance=~".*pg.*"}[1m]) >= 0
    for: 2m
    labels:
      team: DBA
      urgency: P1
    annotations:
      summary: "{{$labels.instance}} RAM Usage High: {{ $value }}"
      description: "{{$labels.instance}} RAM Usage Higher than 90 Percent: {{ $value }}"

  - alert: DB_DISK_USAGE_HIGH
    expr:  (node_filesystem_free_bytes{instance=~".*pg.*",device="/dev/sda1"} / node_filesystem_size_bytes{instance=~".*pg.*",device="/dev/sda1"}) < 0.1
    for: 2m
    labels:
      team: DBA
      urgency: P1
    annotations:
      summary: "{{$labels.instance}} Disk Free Space Less Than 10 Percent: {{ $value }}"
      description: "{{$labels.instance}} Disk {{$labels.device}} {{$labels.fstype}} {{$labels.mountpoint}} Free Space Less Than 10 Percent: {{ $value }}"

  - alert: DB_REPLCATION_LAG_HIGH
    expr: pg_replication_flush_diff{instance=~".*pg.*", application_name!~"pg_receivewal"} > 102400000
    for: 10m
    labels:
      team: DBA
      urgency: P1
    annotations:
      summary: "{{$labels.instance}} to {{$labels.application_name}} Replication Lag: {{ $value }}"
      description: "{{$labels.instance}} to {{$labels.application_name}} Replication Lag {{ $value }}"

  - alert: DB_AGE_HIGH
    expr: max(pg_database_age{instance=~".*pg.*"}) by (instance) > 600000000
    for: 10m
    labels:
      team: DBA
      urgency: P1
    annotations:
      summary: "{{$labels.instance}} DB_AGE_HIGH: {{ $value }}"
      description: "{{$labels.instance}} DB_AGE_HIGH: {{ $value }}"

  - alert: DB_ACTIVE_SESSION_HIGH
    expr: pg_activity_state_count{instance=~".*pg",state="active",datname!~'(postgres|template.)'} > 30
    for: 2m
    labels:
      team: DBA
      urgency: P1
    annotations:
      summary: "{{$labels.instance}} DB_ACTIVE_SESSION_HIGH Active connection: {{ $value }}"
      description: "{{$labels.instance}} DB_ACTIVE_SESSION_HIGH Active connection: {{ $value }}"

  - alert: DB_IDLE_IN_XACT_SESSION_HIGH
    expr: pg_activity_state_count{instance=~".*pg",state="idle in transaction",datname!~'(postgres|template.)'} > 5
    for: 1m
    labels:
      team: DBA
      urgency: P1
    annotations:
      summary: "{{$labels.instance}} DB_IDLE_IN_XACT_SESSION_HIGH IdleInXact connection: {{ $value }}"
      description: "{{$labels.instance}} DB_IDLE_IN_XACT_SESSION_HIGH IdleInXact connection: {{ $value }}"


  - alert: DB_CPU_USAGE_WARN
    expr: 1 - avg(rate(node_cpu_seconds_total{mode="idle",instance=~".*pg.*"}[1m])) BY (instance) > 0.3
    for: 2m
    labels:
      team: DBA
      urgency: P2
    annotations:
      summary: "{{$labels.instance}} CPU Usage Warning: {{ $value }}"
      description: "{{$labels.instance}} CPU Usage Warning: {{ $value }}"

  - alert: DB_CPU_ONE_CORE_HIGH
    expr: min(rate(node_cpu_seconds_total{mode="idle",instance=~".*pg.*"}[1m])) BY (instance, cpu) < 0.1
    for: 2m
    labels:
      team: DBA
      urgency: P2
    annotations:
      summary: "{{$labels.instance}} DB_CPU_ONE_CORE_HIGH {{$labels.cpu}}: {{ $value }}"
      description: "{{$labels.instance}} DB_CPU_ONE_CORE_HIGH {{$labels.cpu}}: {{ $value }}"

  - alert: DB_RAM_USAGE_WARN
    expr: (node_memory_Buffers_bytes{instance=~".*pg.*"} + node_memory_MemFree_bytes{instance=~".*pg.*"} +  node_memory_Cached_bytes{instance=~".*pg.*"}) /  node_memory_MemTotal_bytes{instance=~".*pg.*"} < 0.2
    for: 2m
    labels:
      team: DBA
      urgency: P2
    annotations:
      summary: "{{$labels.instance}} DB_RAM_USAGE_WARN: {{ $value }}"
      description: "{{$labels.instance}} RAM Usage Higher than 90 Percent: {{ $value }}"

  - alert: DB_DISK_USAGE_WARN
    expr:  (node_filesystem_free_bytes{instance=~".*pg.*",device="/dev/sda1"} / node_filesystem_size_bytes{instance=~".*pg.*",device="/dev/sda1"}) < 0.25
    for: 2m
    labels:
      team: DBA
      urgency: P2
    annotations:
      summary: "{{$labels.instance}} Disk Free Space Less Than 25 Percent: {{ $value }}"
      description: "{{$labels.instance}} Disk {{$labels.device}} {{$labels.fstype}} {{$labels.mountpoint}} Free Space Less Than 10 Percent: {{ $value }}"

  - alert: DB_REPLCATION_LAG_WARN
    expr: pg_replication_flush_diff{instance=~".*pg.*", application_name!~"pg_receivewal"} > 10240000
    for: 10m
    labels:
      team: DBA
      urgency: P2
    annotations:
      summary: "{{$labels.instance}} DB_REPLCATION_LAG_WARN to {{$labels.application_name}} Replication Lag: {{ $value }}"
      description: "{{$labels.instance}} DB_REPLCATION_LAG_WARN to {{$labels.application_name}} Replication Lag  {{ $value }}"

  - alert: DB_AGE_WARN
    expr: max(pg_database_age{instance=~".*pg.*"}) by (instance) > 250000000
    for: 10m
    labels:
      team: DBA
      urgency: P2
    annotations:
      summary: "{{$labels.instance}} DB_AGE_WARN: {{ $value }}"
      description: "{{$labels.instance}} DB_AGE_WARN: {{ $value }}"

Application Alert & System Alert

And App(Backend) Sys(DevOps) can have there own Alerts, such as these (just for illustration)

P0 APP_SERVER_DOWN
P0 ALERT_PROCESS_CONTROL_30PERCENT_DROPS
P0 ALERT_GET_SERIAL_30PERCENT_DROPS
P0 ALERT_PUSH_LOG_30PERCENT_DROPS

P1 5XX_ERROR_EXCEED_30
P1 HIGH_NON_200_RESPONSE_CODE
P1 APP_RESPONSE_TIME_SLOW
P1 APP_CIRCUIT_BREAKER_TRIGGERED
P1 PROCESS_CONTROL_FAIL_RATE_HIGH
P1 SYS_ERROR_RATE_HIGH

P2 LOG_SERIAL_REQUEST_BRUST
P2 QPS_DOD_HIGH

Conclusion

To setup an alert system is very easy, but tune it into good working condition not. It may take serval months ’s tunning work to make it less annoying, and reduce false alert into a moderate level.

关系膨胀：监控与处理

PostgreSQL使用了MVCC作为主要并发控制技术，它有很多好处，但也会带来一些其他的影响，例如关系膨胀。

著： 冯若航（@Vonng） | 2018-10-06

前言

PostgreSQL使用了MVCC作为主要并发控制技术，它有很多好处，但也会带来一些其他的影响，例如关系膨胀。关系（表与索引）膨胀会对数据库性能产生负面影响，并浪费磁盘空间。为了使PostgreSQL始终保持在最佳性能，有必要及时对膨胀的关系进行垃圾回收，并定期重建过度膨胀的关系。

在实际操作中，垃圾回收并没有那么简单，这里有一系列的问题：

关系膨胀的原因？
关系膨胀的度量？
关系膨胀的监控？
关系膨胀的处理？

本文将详细说明这些问题。

关系膨胀概述

假设某个关系实际占用存储100G，但其中有很多空间被死元组，碎片，空闲区域浪费，如果将其压实为一个新的关系，占用空间变为60G，那么就可以近似认为该关系的膨胀率是 (100 - 60) / 100 = 40%。

普通的VACUUM不能解决表膨胀的问题，死元组本身能够被并发VACUUM机制回收，但它产生的碎片，留下的空洞却不可以。比如，即使删除了许多死元组，也无法减小表的大小。久而久之，关系文件被大量空洞填满，浪费了大量的磁盘空间。

VACUUM FULL命令可以回收这些空间，它将旧表文件中的活元组复制到新表中，通过重写整张表的方式将表压实。但在实际生产中，因为该操作会持有表上的AccessExclusiveLock，阻塞业务正常访问，因此在不间断服务的情况下并不适用，pg_repack是一个实用的第三方插件，能够在线上业务正常进行的同时进行无锁的VACUUM FULL。

不幸的是，关于什么时候需要进行VACUUM FULL处理膨胀并没有一个最佳实践。DBA需要针对自己的业务场景制定清理策略。但无论采用何种策略，实施这些策略的机制都是类似的：

监控，检测，衡量关系的膨胀程度
依据关系的膨胀程度，时机等因素，处理关系膨胀。

这里有几个关键的问题，首先是，如何定义关系的膨胀率？

关系膨胀的度量

衡量关系膨胀的程度，首先需要定义一个指标：膨胀率（bloat rate）。

膨胀率的计算思想是：通过统计信息估算出目标表如果处于 紧实（Compact） 状态所占用的空间，而实际使用空间超出该紧实空间部分的占比，就是膨胀率。因此膨胀率可以被定义为 1 - (活元组占用字节总数 / 关系占用字节总数)。

例如，某个表实际占用存储100G，但其中有很多空间被死元组，碎片，空闲区域浪费，如果将其压实为一张新表，占用空间变为60G，那么膨胀率就是 1 - 60/100 = 40%。

关系的大小获取较为简单，可以直接从系统目录中获取。所以问题的关键在于，活元组的字节总数这一数据如何获取。

膨胀率的精确计算

PostgreSQL自带了pgstattuple模块，可用于精确计算表的膨胀率。譬如这里的tuple_percent字段就是元组实际字节占关系总大小的百分比，用1减去该值即为膨胀率。

vonng@[local]:5432/bench# select *,
                          1.0 - tuple_len::numeric / table_len as bloat 
                          from pgstattuple('pgbench_accounts');
┌─[ RECORD 1 ]───────┬────────────────────────┐
│ table_len          │ 136642560              │
│ tuple_count        │ 1000000                │
│ tuple_len          │ 121000000              │
│ tuple_percent      │ 88.55                  │
│ dead_tuple_count   │ 16418                  │
│ dead_tuple_len     │ 1986578                │
│ dead_tuple_percent │ 1.45                   │
│ free_space         │ 1674768                │
│ free_percent       │ 1.23                   │
│ bloat              │ 0.11447794889088729017 │
└────────────────────┴────────────────────────┘

pgstattuple对于精确地判断表与索引的膨胀情况非常有用，具体细节可以参考官方文档：https://www.postgresql.org/docs/current/static/pgstattuple.html。

此外，PostgreSQL还提供了两个自带的扩展，pg_freespacemap与pageinspect，前者可以用于检视每个页面中的空闲空间大小，后者则可以精确地展示关系中每个数据页内物理存储的内容。如果希望检视关系的内部状态，这两个插件非常实用，详细使用方法可以参考官方文档：

https://www.postgresql.org/docs/current/static/pgfreespacemap.html

https://www.postgresql.org/docs/current/static/pageinspect.html

不过在绝大多数情况下，我们并不会太在意膨胀率的精确度。在实际生产中对膨胀率的要求并不高：第一位有效数字是准确的，就差不多够用了。另一方面，要想精确地知道活元组占用的字节总数，需要对整个关系执行一遍扫描，这会对线上系统的IO产生压力。如果希望对所有表的膨胀率进行监控，也不适合使用这种方式。

例如一个200G的关系，使用pgstattuple插件执行精确的膨胀率估算大致需要5分钟时间。在9.5及后续版本，pgstattuple插件还提供了pgstattuple_approx函数，以精度换速度。但即使使用估算，也需要秒级的时间。

监控膨胀率，最重要的要求是速度快，影响小。因此当我们需要对很多数据库的很多表同时进行监控时，需要对膨胀率进行快速估算，避免对业务产生影响。

膨胀率的估算

PostgreSQL为每个关系都维护了很多的统计信息，利用统计信息，可以快速高效地估算数据库中所有表的膨胀率。估算膨胀率需要使用表与列上的统计信息，直接使用的统计指标有三个：

元组的平均宽度avgwidth：从列级统计数据计算而来，用于估计紧实状态占用的空间。
元组数：pg_class.reltuples：用于估计紧实状态占用的空间
页面数：pg_class.relpages：用于测算实际使用的空间

而计算公式也很简单：

1 - (reltuples * avgwidth) / (block_size - pageheader) / relpages

这里block_size是页面大小，默认为8182，pageheader是首部占用的大小，默认为24字节。页面大小减去首部大小就是可以用于元组存储的实际空间，因此(reltuples * avgwidth)给出了元组的估计总大小，而除以前者后，就可以得到预计需要多少个页面才能紧实地存下所有的元组。最后，期待使用的页面数量，除以实际使用的页面数量，就是利用率，而1减去利用率，就是膨胀率。

难点

这里的关键，在于如何使用统计信息估算元组的平均长度，而为了实现这一点，我们需要克服三个困难：

当元组中存在空值时，首部会带有空值位图。
首部与数据部分存在Padding，需要考虑边界对齐。
一些字段类型也存在对齐要求

但好在，膨胀率本身就是一种估算，只要大致正确即可。

计算元组的平均长度

为了理解估算的过程，首先需要理解PostgreSQL中数据页面与元组的的内部布局。

首先来看元组的平均长度，PG中元组的布局如下图所示。

一条元组占用的空间可以分为三个部分：

定长的行指针（4字节，严格来说这不算元组的一部分，但它与元组一一对应）
变长的首部
- 固定长度部分23字节
- 当元组中存在空值时，会出现空值位图，每个字段占一位，故其长度为字段数除以8。
- 在空值位图后需要填充至MAXALIGN，通常为8。
- 如果表启用了WITH OIDS选项，元组还会有一个4字节的OID，但这里我们不考虑该情况。
数据部分

因此，一条元组（包括相应的行指针）的平均长度可以这样计算：

avg_size_tuple = 4 + avg_size_hdr + avg_size_data

关键在于求出首部的平均长度与数据部分的平均长度。

计算首部的平均长度

首部平均长度主要的变数在于空值位图与填充对齐。为了估算元组首部的平均长度，我们需要知道几个参数：

不带空值位图的首部平均长度（带有填充）：normhdr
带有空值位图的首部平均长度（带有填充）：nullhdr
带有空值的元组比例：nullfrac

而估算首部平均长度的公式，也非常简单：

avg_size_hdr =  nullhdr * nullfrac + normhdr * (1 - nullfrac)

因为不带空值位图的首部，其长度是23字节，对齐至8字节的边界，长度为24字节，上式可以改为：

avg_size_hdr =  nullhdr * nullfrac +  24 * (1 - nullfrac)

计算某值被补齐至8字节边界的长度，可以使用以下公式进行高效计算：

padding = lambda x : x + 7 >> 3 << 3

计算数据部分的平均长度

数据部分的平均长度主要取决于每个字段的平均宽度与空值率，加上末尾的对齐。

以下SQL可以利用统计信息算出所有表的平均元组数据部分宽度。

SELECT schemaname, tablename, sum((1 - null_frac) * avg_width)
FROM pg_stats GROUP BY (schemaname, tablename);

例如，以下SQL能够从pg_stats系统统计视图中获取app.apple表上一条元组的平均长度。

SELECT
  count(*),                        -- 字段数目
  ceil(count(*) / 8.0),            -- 空值位图占用的字节数
  max(null_frac),                  -- 最大空值率
  sum((1 - null_frac) * avg_width) -- 数据部分的平均宽度
FROM pg_stats
where schemaname = 'app' and tablename = 'apple';

-[ RECORD 1 ]-----------
count | 47
ceil  | 6
max   | 1
sum   | 1733.76873471724

整合

将上面三节的逻辑整合，得到以下的存储过程，给定一个表，返回其膨胀率。

CREATE OR REPLACE FUNCTION public.pg_table_bloat(relation regclass)
 RETURNS double precision
 LANGUAGE plpgsql
AS $function$
DECLARE
  _schemaname text;
  tuples      BIGINT := 0;
  pages       INTEGER := 0;
  nullheader  INTEGER:= 0;
  nullfrac    FLOAT := 0;
  datawidth   INTEGER :=0;
  avgtuplelen FLOAT :=24;
BEGIN
  SELECT
    relnamespace :: RegNamespace,
    reltuples,
    relpages
  into _schemaname, tuples, pages
  FROM pg_class
  Where oid = relation;

  SELECT
    23 + ceil(count(*) >> 3),
    max(null_frac),
    ceil(sum((1 - null_frac) * avg_width))
  into nullheader, nullfrac, datawidth
  FROM pg_stats
  where schemaname = _schemaname and tablename = relation :: text;

  SELECT (datawidth + 8 - (CASE WHEN datawidth%8=0 THEN 8 ELSE datawidth%8 END)) -- avg data len
    + (1 - nullfrac) * 24 + nullfrac * (nullheader + 8 - (CASE WHEN nullheader%8=0 THEN 8 ELSE nullheader%8 END))
    INTO avgtuplelen;

  raise notice '% %', nullfrac, datawidth;

  RETURN 1 - (ceil(tuples * avgtuplelen / 8168)) / pages;
END;
$function$

批量计算

对于监控而言，我们关注的往往不仅仅是一张表，而是库中所有的表。因此，可以将上面的膨胀率计算逻辑重写为批量计算的查询，并定义为视图便于使用：

DROP VIEW IF EXISTS monitor.pg_bloat_indexes CASCADE;
CREATE OR REPLACE VIEW monitor.pg_bloat_indexes AS
  WITH btree_index_atts AS (
      SELECT
        pg_namespace.nspname,
        indexclass.relname                                                          AS index_name,
        indexclass.reltuples,
        indexclass.relpages,
        pg_index.indrelid,
        pg_index.indexrelid,
        indexclass.relam,
        tableclass.relname                                                          AS tablename,
        (regexp_split_to_table((pg_index.indkey) :: TEXT, ' ' :: TEXT)) :: SMALLINT AS attnum,
        pg_index.indexrelid                                                         AS index_oid
      FROM ((((pg_index
        JOIN pg_class indexclass ON ((pg_index.indexrelid = indexclass.oid)))
        JOIN pg_class tableclass ON ((pg_index.indrelid = tableclass.oid)))
        JOIN pg_namespace ON ((pg_namespace.oid = indexclass.relnamespace)))
        JOIN pg_am ON ((indexclass.relam = pg_am.oid)))
      WHERE ((pg_am.amname = 'btree' :: NAME) AND (indexclass.relpages > 0))
  ), index_item_sizes AS (
      SELECT
        ind_atts.nspname,
        ind_atts.index_name,
        ind_atts.reltuples,
        ind_atts.relpages,
        ind_atts.relam,
        ind_atts.indrelid                                    AS table_oid,
        ind_atts.index_oid,
        (current_setting('block_size' :: TEXT)) :: NUMERIC   AS bs,
        8                                                    AS maxalign,
        24                                                   AS pagehdr,
        CASE
        WHEN (max(COALESCE(pg_stats.null_frac, (0) :: REAL)) = (0) :: FLOAT)
          THEN 2
        ELSE 6
        END                                                  AS index_tuple_hdr,
        sum((((1) :: FLOAT - COALESCE(pg_stats.null_frac, (0) :: REAL)) *
             (COALESCE(pg_stats.avg_width, 1024)) :: FLOAT)) AS nulldatawidth
      FROM ((pg_attribute
        JOIN btree_index_atts ind_atts
          ON (((pg_attribute.attrelid = ind_atts.indexrelid) AND (pg_attribute.attnum = ind_atts.attnum))))
        JOIN pg_stats ON (((pg_stats.schemaname = ind_atts.nspname) AND (((pg_stats.tablename = ind_atts.tablename) AND
                                                                          ((pg_stats.attname) :: TEXT =
                                                                           pg_get_indexdef(pg_attribute.attrelid,
                                                                                           (pg_attribute.attnum) :: INTEGER,
                                                                                           TRUE))) OR
                                                                         ((pg_stats.tablename = ind_atts.index_name) AND
                                                                          (pg_stats.attname = pg_attribute.attname))))))
      WHERE (pg_attribute.attnum > 0)
      GROUP BY ind_atts.nspname, ind_atts.index_name, ind_atts.reltuples, ind_atts.relpages, ind_atts.relam,
        ind_atts.indrelid, ind_atts.index_oid, (current_setting('block_size' :: TEXT)) :: NUMERIC, 8 :: INTEGER
  ), index_aligned_est AS (
      SELECT
        index_item_sizes.maxalign,
        index_item_sizes.bs,
        index_item_sizes.nspname,
        index_item_sizes.index_name,
        index_item_sizes.reltuples,
        index_item_sizes.relpages,
        index_item_sizes.relam,
        index_item_sizes.table_oid,
        index_item_sizes.index_oid,
        COALESCE(ceil((((index_item_sizes.reltuples * ((((((((6 + index_item_sizes.maxalign) -
                                                             CASE
                                                             WHEN ((index_item_sizes.index_tuple_hdr %
                                                                    index_item_sizes.maxalign) = 0)
                                                               THEN index_item_sizes.maxalign
                                                             ELSE (index_item_sizes.index_tuple_hdr %
                                                                   index_item_sizes.maxalign)
                                                             END)) :: FLOAT + index_item_sizes.nulldatawidth)
                                                          + (index_item_sizes.maxalign) :: FLOAT) - (
                                                           CASE
                                                           WHEN (((index_item_sizes.nulldatawidth) :: INTEGER %
                                                                  index_item_sizes.maxalign) = 0)
                                                             THEN index_item_sizes.maxalign
                                                           ELSE ((index_item_sizes.nulldatawidth) :: INTEGER %
                                                                 index_item_sizes.maxalign)
                                                           END) :: FLOAT)) :: NUMERIC) :: FLOAT) /
                        ((index_item_sizes.bs - (index_item_sizes.pagehdr) :: NUMERIC)) :: FLOAT) +
                       (1) :: FLOAT)), (0) :: FLOAT) AS expected
      FROM index_item_sizes
  ), raw_bloat AS (
      SELECT
        current_database()                                                           AS dbname,
        index_aligned_est.nspname,
        pg_class.relname                                                             AS table_name,
        index_aligned_est.index_name,
        (index_aligned_est.bs * ((index_aligned_est.relpages) :: BIGINT) :: NUMERIC) AS totalbytes,
        index_aligned_est.expected,
        CASE
        WHEN ((index_aligned_est.relpages) :: FLOAT <= index_aligned_est.expected)
          THEN (0) :: NUMERIC
        ELSE (index_aligned_est.bs *
              ((((index_aligned_est.relpages) :: FLOAT - index_aligned_est.expected)) :: BIGINT) :: NUMERIC)
        END                                                                          AS wastedbytes,
        CASE
        WHEN ((index_aligned_est.relpages) :: FLOAT <= index_aligned_est.expected)
          THEN (0) :: NUMERIC
        ELSE (((index_aligned_est.bs * ((((index_aligned_est.relpages) :: FLOAT -
                                          index_aligned_est.expected)) :: BIGINT) :: NUMERIC) * (100) :: NUMERIC) /
              (index_aligned_est.bs * ((index_aligned_est.relpages) :: BIGINT) :: NUMERIC))
        END                                                                          AS realbloat,
        pg_relation_size((index_aligned_est.table_oid) :: REGCLASS)                  AS table_bytes,
        stat.idx_scan                                                                AS index_scans
      FROM ((index_aligned_est
        JOIN pg_class ON ((pg_class.oid = index_aligned_est.table_oid)))
        JOIN pg_stat_user_indexes stat ON ((index_aligned_est.index_oid = stat.indexrelid)))
  ), format_bloat AS (
      SELECT
        raw_bloat.dbname                                             AS database_name,
        raw_bloat.nspname                                            AS schema_name,
        raw_bloat.table_name,
        raw_bloat.index_name,
        round(
            raw_bloat.realbloat)                                     AS bloat_pct,
        round((raw_bloat.wastedbytes / (((1024) :: FLOAT ^
                                         (2) :: FLOAT)) :: NUMERIC)) AS bloat_mb,
        round((raw_bloat.totalbytes / (((1024) :: FLOAT ^ (2) :: FLOAT)) :: NUMERIC),
              3)                                                     AS index_mb,
        round(
            ((raw_bloat.table_bytes) :: NUMERIC / (((1024) :: FLOAT ^ (2) :: FLOAT)) :: NUMERIC),
            3)                                                       AS table_mb,
        raw_bloat.index_scans
      FROM raw_bloat
  )
  SELECT
    format_bloat.database_name                    as datname,
    format_bloat.schema_name                      as nspname,
    format_bloat.table_name                       as relname,
    format_bloat.index_name                       as idxname,
    format_bloat.index_scans                      as idx_scans,
    format_bloat.bloat_pct                        as bloat_pct,
    format_bloat.table_mb,
    format_bloat.index_mb - format_bloat.bloat_mb as actual_mb,
    format_bloat.bloat_mb,
    format_bloat.index_mb                         as total_mb
  FROM format_bloat
  ORDER BY format_bloat.bloat_mb DESC;


COMMENT ON VIEW monitor.pg_bloat_indexes IS 'index bloat monitor';

虽然看上去很长，但查询该视图获取全库（3TB）所有表的膨胀率，计算只需要50ms。而且只需要访问统计数据，不需要访问关系本体，占用实例的IO。

表膨胀的处理

如果只是玩具数据库，或者业务允许每天有很长的停机维护时间，那么简单地在数据库中执行VACUUM FULL就可以了。但VACUUM FULL需要表上的排它读写锁，但对于需要不间断运行的数据库，我们就需要用到pg_repack来处理表的膨胀。

主页：http://reorg.github.io/pg_repack/

pg_repack已经包含在了PostgreSQL官方的yum源中，因此可以直接通过yum install pg_repack安装。

yum install pg_repack10

`pg_repack`的使用

与大多数PostgreSQL客户端程序一样，pg_repack也通过类似的参数连接至PostgreSQL服务器。

在使用pg_repack之前，需要在待重整的数据库中创建pg_repack扩展

CREATE EXTENSION pg_repack

然后就可以正常使用了，几种典型的用法：

# 完全清理整个数据库，开5个并发任务，超时等待10秒
pg_repack -d <database> -j 5 -T 10

# 清理mydb中一张特定的表mytable，超时等待10秒
pg_repack mydb -t public.mytable -T 10

# 清理某个特定的索引 myschema.myindex，注意必须使用带模式的全名
pg_repack mydb -i myschema.myindex

详细的用法可以参考官方文档。

`pg_repack`的策略

通常，如果业务存在峰谷周期，则可以选在业务低谷器进行整理。pg_repack执行比较快，但很吃资源。在高峰期执行可能会影响整个数据库的性能表现，也有可能会导致复制滞后。

例如，可以利用上面两节提供的膨胀率监控视图，每天挑选膨胀最为严重的若干张表和若干索引进行自动重整。

#--------------------------------------------------------------#
# Name: repack_tables
# Desc: repack table via fullname
# Arg1: database_name
# Argv: list of table full name
# Deps: psql
#--------------------------------------------------------------#
# repack single table
function repack_tables(){
    local db=$1
    shift

    log_info "repack ${db} tables begin"
    log_info "repack table list: $@"

    for relname in $@
    do
        old_size=$(psql ${db} -Atqc "SELECT pg_size_pretty(pg_relation_size('${relname}'));")
        # kill_queries ${db}
        log_info "repack table ${relname} begin, old size: ${old_size}"
        pg_repack ${db} -T 10 -t ${relname}
        new_size=$(psql ${db} -Atqc "SELECT pg_size_pretty(pg_relation_size('${relname}'));")
        log_info "repack table ${relname} done , new size: ${old_size} -> ${new_size}"
    done

    log_info "repack ${db} tables done"
}

#--------------------------------------------------------------#
# Name: get_bloat_tables
# Desc: find bloat tables in given database match some condition
# Arg1: database_name
# Echo: list of full table name
# Deps: psql, monitor.pg_bloat_tables
#--------------------------------------------------------------#
function get_bloat_tables(){
    echo $(psql ${1} -Atq <<-'EOF'
    WITH bloat_tables AS (
        SELECT
          nspname || '.' || relname as relname,
          actual_mb,
          bloat_pct
        FROM monitor.pg_bloat_tables
        WHERE nspname NOT IN ('dba', 'monitor', 'trash')
        ORDER BY 2 DESC,3 DESC
    )
    -- 64 small + 16 medium + 4 large
    (SELECT relname FROM bloat_tables WHERE actual_mb < 256 AND bloat_pct > 40 ORDER BY bloat_pct DESC LIMIT 64) UNION
    (SELECT relname FROM bloat_tables WHERE actual_mb BETWEEN 256 AND 1024  AND bloat_pct > 30 ORDER BY bloat_pct DESC LIMIT 16) UNION
    (SELECT relname FROM bloat_tables WHERE actual_mb BETWEEN 1024 AND 4096  AND bloat_pct > 20 ORDER BY bloat_pct DESC  LIMIT 4);
EOF
)
}

这里，设置了三条规则：

从小于256MB，且膨胀率超过40%的小表中，选出TOP64
从256MB到1GB之间，且膨胀率超过40%的中表中，选出TOP16
从1GB到4GB之间，且膨胀率超过20%的大表中，选出TOP4

选出这些表，每天凌晨低谷自动进行重整。超过4GB的表手工处理。

但何时进行重整，还是取决于具体的业务模式。

`pg_repack`的原理

pg_repack的原理相当简单，它会为待重建的表创建一份副本。首先取一份全量快照，将所有活元组写入新表，并通过触发器将所有针对原表的变更同步至新表，最后通过重命名，使用新的紧实副本替换老表。而对于索引，则是通过PostgreSQL的CREATE(DROP) INDEX CONCURRENTLY完成的。

重整表

创建一张与原表模式相同，但不带索引的空表。
创建一张与原始表对应的日志表，用于记录pg_repack工作期间该表上发生的变更。
为原始表添加一个行触发器，在相应日志表中记录所有INSERT,DELETE,UPDATE操作。
将老表中的数据复制到新的空表中。
在新表上创建同样的索引
将日志表中的增量变更应用到新表上
通过重命名的方式切换新旧表
将旧的，已经被重命名掉的表DROP掉。

重整索引

使用CREATE INDEX CONCURRENTLY在原表上创建新索引，保持与旧索引相同的定义。
Analyze新索引，并将旧索引设置为无效，在数据目录中将新旧索引交换。
删除旧索引。

`pg_repack`的注意事项

重整开始之前，最好取消掉所有正在进行的Vacuum任务。
对索引做重整之前，最好能手动清理掉可能正在使用该索引的查询
如果出现异常的情况（譬如中途强制退出），有可能会留下未清理的垃圾，需要手工清理。可能包括：
- 临时表与临时索引建立在与原表/索引同一个schema内
- 临时表的名称为：${schema_name}.table_${table_oid}
- 临时索引的名称为：${schema_name}.index_${table_oid}}
- 原始表上可能会残留相关的触发器，需要手动清理。
重整特别大的表时，需要预留至少与该表及其索引相同大小的磁盘空间，需要特别小心，手动检查。
当完成重整，进行重命名替换时，会产生巨量的WAL，有可能会导致复制延迟，而且无法取消。

PipelineDB快速上手

PipelineDB是PostgreSQL的一个扩展插件，提供流式数据处理的相关功能。

著： 冯若航（@Vonng） | 2018-09-07

PipelineDB安装与配置

PipelineDB可以直接通过官方rpm包安装。

加载PipelineDB需要添加动态链接库，在postgresql.conf中修改配置项并重启：

shared_preload_libraries = 'pipelinedb'
max_worker_processes = 128

注意如果不修改max_worker_processes会报错。其他配置都参照标准的PostgreSQL

PipelineDB使用样例 —— 维基PV数据

-- 创建Stream
CREATE FOREIGN TABLE wiki_stream (
        hour timestamp,
        project text,
        title text,
        view_count bigint,
        size bigint)
SERVER pipelinedb;

-- 在Stream上进行聚合
CREATE VIEW wiki_stats WITH (action=materialize) AS
SELECT hour, project,
        count(*) AS total_pages,
        sum(view_count) AS total_views,
        min(view_count) AS min_views,
        max(view_count) AS max_views,
        avg(view_count) AS avg_views,
        percentile_cont(0.99) WITHIN GROUP (ORDER BY view_count) AS p99_views,
        sum(size) AS total_bytes_served
FROM wiki_stream
GROUP BY hour, project;

然后，向Stream中插入数据：

curl -sL http://pipelinedb.com/data/wiki-pagecounts | gunzip | \
        psql -c "
        COPY wiki_stream (hour, project, title, view_count, size) FROM STDIN"

基本概念

PipelineDB中的基本抽象被称之为：连续视图（Continuous View）。

TimescaleDB快速上手

TimescaleDB是PostgreSQL的一个扩展插件，提供时序数据库的一些功能。

著： 冯若航（@Vonng） | 2018-09-07

官方网站：https://www.timescale.com
官方文档：https://docs.timescale.com/v0.9/main
Github：https://github.com/timescale/timescaledb

为什么使用TimescaleDB

什么是时间序列数据？

我们一直在谈论什么是“时间序列数据”，以及与其他数据有何不同以及为什么？

许多应用程序或数据库实际上采用的是过于狭窄的视图，并将时间序列数据与特定形式的服务器度量值等同起来：

Name:    CPU

Tags:    Host=MyServer, Region=West

Data:
2017-01-01 01:02:00    70
2017-01-01 01:03:00    71
2017-01-01 01:04:00    72
2017-01-01 01:05:01    68

但实际上，在许多监控应用中，通常会收集不同的指标（例如，CPU，内存，网络统计数据，电池寿命）。因此，单独考虑每个度量并不总是有意义的。考虑这种替代性的“更广泛”的数据模型，它保持了同时收集的指标之间的相关性。

Metrics: CPU, free_mem, net_rssi, battery

Tags:    Host=MyServer, Region=West

Data:
2017-01-01 01:02:00    70    500    -40    80
2017-01-01 01:03:00    71    400    -42    80
2017-01-01 01:04:00    72    367    -41    80
2017-01-01 01:05:01    68    750    -54    79

这类数据属于更广泛的类别，无论是来自传感器的温度读数，股票价格，机器状态，甚至是登录应用程序的次数。

时间序列数据是统一表示系统，过程或行为随时间变化的数据。

时间序列数据的特征

如果仔细研究它是如何生成和摄入的，TimescaleDB等时间序列数据库通常具有以下重要特征：

以时间为中心：数据记录始终有一个时间戳。
仅追加-：数据是几乎完全追加只（插入）。
最近：新数据通常是关于最近的时间间隔，我们更少更新或回填旧时间间隔的缺失数据。

尽管数据的频率或规律性并不重要，它可以每毫秒或每小时收集一次。它也可以定期或不定期收集（例如，当发生某些事件时，而不是在预先确定的时间）。

但是没有数据库很久没有时间字段？与标准关系“业务”数据等其他数据相比，时间序列数据（以及支持它们的数据库）之间的一个主要区别是对数据的更改是插入而不是覆盖。

时间序列数据无处不在

时间序列数据无处不在，但有些环境特别是在洪流中创建。

监控计算机系统：虚拟机，服务器，容器指标（CPU，可用内存，网络/磁盘IOP），服务和应用程序指标（请求率，请求延迟）。
金融交易系统：经典证券，较新的加密货币，支付，交易事件。
物联网：工业机器和设备上的传感器，可穿戴设备，车辆，物理容器，托盘，智能家居的消费设备等的数据。
事件应用程序：用户/客户交互数据，如点击流，综合浏览量，登录，注册等。
商业智能：跟踪关键指标和业务的整体健康状况。
环境监测：温度，湿度，压力，pH值，花粉计数，空气流量，一氧化碳（CO），二氧化氮（NO2），颗粒物质（PM10）。
（和更多）

数据模型

TimescaleDB使用“宽表”数据模型，这在关系数据库中是非常普遍的。这使得Timescale与大多数其他时间序列数据库有所不同，后者通常使用“窄表”模型。

在这里，我们讨论为什么我们选择宽表模型，以及我们如何推荐将它用于时间序列数据，使用物联网（IoT）示例。

设想一个由1,000个IoT设备组成的分布式组，旨在以不同的时间间隔收集环境数据。这些数据可能包括：

标识符： device_id，timestamp
元数据： location_id，，，dev_type``firmware_version``customer_id
设备指标： cpu_1m_avg，，，，，free_mem``used_mem``net_rssi``net_loss``battery
传感器指标： temperature，，，，，humidity``pressure``CO``NO2``PM10

例如，您的传入数据可能如下所示：

时间戳	设备ID	cpu_1m_avg	Fri_mem	温度	LOCATION_ID	dev_type
2017-01-01 01:02:00	ABC123	80	500MB	72	335	领域
2017-01-01 01:02:23	def456	90	400MB	64	335	屋顶
2017-01-01 01:02:30	ghi789	120	0MB	56	77	屋顶
2017-01-01 01:03:12	ABC123	80	500MB	72	335	领域
2017-01-01 01:03:35	def456	95	350MB	64	335	屋顶
2017-01-01 01:03:42	ghi789	100	100MB	56	77	屋顶

现在，我们来看看用这些数据建模的各种方法。

窄桌模型

大多数时间序列数据库将以下列方式表示这些数据：

代表每个指标作为一个单独的实体（例如，表示与作为两个不同的东西）cpu_1m_avg``free_mem
为该指标存储一系列“时间”，“值”对
将元数据值表示为与该指标/标记集组合关联的“标记集”

在这个模型中，每个度量/标签集组合被认为是包含一系列时间/值对的单独“时间序列”。

使用我们上面的例子，这种方法会导致9个不同的“时间序列”，每个“时间序列”由一组独特的标签定义。

1. {name:  cpu_1m_avg,  device_id: abc123,  location_id: 335,  dev_type: field}
2. {name:  cpu_1m_avg,  device_id: def456,  location_id: 335,  dev_type: roof}
3. {name:  cpu_1m_avg,  device_id: ghi789,  location_id:  77,  dev_type: roof}
4. {name:    free_mem,  device_id: abc123,  location_id: 335,  dev_type: field}
5. {name:    free_mem,  device_id: def456,  location_id: 335,  dev_type: roof}
6. {name:    free_mem,  device_id: ghi789,  location_id:  77,  dev_type: roof}
7. {name: temperature,  device_id: abc123,  location_id: 335,  dev_type: field}
8. {name: temperature,  device_id: def456,  location_id: 335,  dev_type: roof}
9. {name: temperature,  device_id: ghi789,  location_id:  77,  dev_type: roof}

这样的时间序列的数量与每个标签的基数的叉积（即，（＃名称）×（＃设备ID）×（＃位置ID）×（设备类型））的交叉积。

而且这些“时间序列”中的每一个都有自己的一组时间/值序列。

现在，如果您独立收集每个指标，而且元数据很少，则此方法可能有用。

但总的来说，我们认为这种方法是有限的。它会丢失数据中的固有结构，使得难以提出各种有用的问题。例如：

系统状态到0 时是什么状态？free_mem
如何关联？cpu_1m_avg``free_mem
平均值是多少？temperature``location_id

我们也发现这种方法认知混乱。我们是否真的收集了9个不同的时间序列，或者只是一个包含各种元数据和指标读数的数据集？

宽桌模型

相比之下，TimescaleDB使用宽表模型，它反映了数据中的固有结构。

我们的宽表模型看起来与初始数据流完全一样：

时间戳	设备ID	cpu_1m_avg	Fri_mem	温度	LOCATION_ID	dev_type
2017-01-01 01:02:00	ABC123	80	500MB	72	42	领域
2017-01-01 01:02:23	def456	90	400MB	64	42	屋顶
2017-01-01 01:02:30	ghi789	120	0MB	56	77	屋顶
2017-01-01 01:03:12	ABC123	80	500MB	72	42	领域
2017-01-01 01:03:35	def456	95	350MB	64	42	屋顶
2017-01-01 01:03:42	ghi789	100	100MB	56	77	屋顶

在这里，每一行都是一个新的读数，在给定的时间里有一组度量和元数据。这使我们能够保留数据中的关系，并提出比以前更有趣或探索性更强的问题。

当然，这不是一种新的格式：这是在关系数据库中常见的。这也是为什么我们发现这种格式更直观的原因。

与关系数据联合

TimescaleDB的数据模型与关系数据库还有另一个相似之处：它支持JOIN。具体来说，可以将附加元数据存储在辅助表中，然后在查询时使用该数据。

在我们的示例中，可以有一个单独的位置表，映射到该位置的其他元数据。例如：location_id

LOCATION_ID	name	纬度	经度	邮政编码	地区
42	大中央车站	40.7527°N	73.9772°W	10017	NYC
77	大厅7	42.3593°N	71.0935°W	02139	马萨诸塞

然后在查询时，通过加入我们的两个表格，可以提出如下问题：10017 中我们的设备的平均值是多少？free_mem``zip_code

如果没有联接，则需要对数据进行非规范化并将所有元数据存储在每个测量行中。这造成数据膨胀，并使数据管理更加困难。

通过连接，可以独立存储元数据，并更轻松地更新映射。

例如，如果我们想更新我们的“区域”为77（例如从“马萨诸塞州”到“波士顿”），我们可以进行此更改，而不必返回并覆盖历史数据。location_id

架构与概念

概观

TimescaleDB作为PostgreSQL的扩展实现，这意味着Timescale数据库在整个PostgreSQL实例中运行。该扩展模型允许数据库利用PostgreSQL的许多属性，如可靠性，安全性以及与各种第三方工具的连接性。同时，TimescaleDB通过在PostgreSQL的查询规划器，数据模型和执行引擎中添加钩子，充分利用扩展可用的高度自定义。

从用户的角度来看，TimescaleDB公开了一些看起来像单数表的称为hypertable的表，它们实际上是一个抽象或许多单独表的虚拟视图，称为块。

可改变和块

通过将hypertable的数据划分为一个或多个维度来创建块：所有可编程元素按时间间隔分区，并且可以通过诸如设备ID，位置，用户ID等的关键字进行分区。我们有时将此称为分区横跨“时间和空间”。

术语

Hypertables

与数据交互的主要点是一个可以抽象化的跨越所有空间和时间间隔的单个连续表，从而可以通过标准SQL查询它。

实际上，所有与TimescaleDB的用户交互都是使用可调整的。创建表格和索引，修改表格，插入数据，选择数据等都可以（也应该）在hypertable上执行。[[跳转到基本的SQL操作] [jumpSQL]]

一个带有列名和类型的标准模式定义了一个hypertable，其中至少一列指定了一个时间值，另一列（可选）指定了一个额外的分区键。

提示：请参阅我们的[数据模型] []，以进一步讨论组织数据的各种方法，具体取决于您的使用情况; 最简单和最自然的就像许多关系数据库一样在“宽桌”中。

单个TimescaleDB部署可以存储多个可更改的超文本，每个超文本具有不同的架构。

在TimescaleDB中创建一个可超过的值需要两个简单的SQL命令:( 使用标准的SQL语法），后面跟着。CREATE TABLE``SELECT create_hypertable()

时间索引和分区键自动创建在hypertable上，尽管也可以创建附加索引（并且TimescaleDB支持所有PostgreSQL索引类型）。

大块

在内部，TimescaleDB自动将每个可分区块分割成块，每个块对应于特定的时间间隔和分区键空间的一个区域（使用散列）。这些分区是不相交的（非重叠的），这有助于查询计划人员最小化它必须接触以解决查询的组块集合。

每个块都使用标准数据库表来实现。（在PostgreSQL内部，这个块实际上是一个“父”可变的“子表”。）

块是正确的大小，确保表的索引的所有B树可以在插入期间驻留在内存中。这样可以避免在修改这些树中的任意位置时发生颠簸。

此外，通过避免过大的块，我们可以避免根据自动化保留策略删除删除的数据时进行昂贵的“抽真空”操作。运行时可以通过简单地删除块（内部表）来执行这些操作，而不是删除单独的行。

单节点与集群

TimescaleDB在单节点部署和集群部署（开发中）上执行这种广泛的分区。虽然分区传统上只用于在多台机器上扩展，但它也允许我们扩展到高写入速率（并改进了并行查询），即使在单台机器上也是如此。

TimescaleDB的当前开源版本仅支持单节点部署。值得注意的是，TimescaleDB的单节点版本已经在商用机器上基于超过100亿行高可用性进行了基准测试，而没有插入性能的损失。

单节点分区的好处

在单台计算机上扩展数据库性能的常见问题是内存和磁盘之间的显着成本/性能折衷。最终，我们的整个数据集不适合内存，我们需要将我们的数据和索引写入磁盘。

一旦数据足够大以至于我们无法将索引的所有页面（例如B树）放入内存中，那么更新树的随机部分可能会涉及从磁盘交换数据。像PostgreSQL这样的数据库为每个表索引保留一个B树（或其他数据结构），以便有效地找到该索引中的值。所以，当您索引更多列时，问题会复杂化。

但是，由于TimescaleDB创建的每个块本身都存储为单独的数据库表，因此其所有索引都只能建立在这些小得多的表中，而不是代表整个数据集的单个表。所以，如果我们正确地确定这些块的大小，我们可以将最新的表（和它们的B-树）完全放入内存中，并避免交换到磁盘的问题，同时保持对多个索引的支持。

有关TimescaleDB自适应空间/时间组块的动机和设计的更多信息，请参阅我们的[技术博客文章] [chunking]。

TimescaleDB与PostgreSQL相比

TimescaleDB相对于存储时间序列数据的vanilla PostgreSQL或其他传统RDBMS提供了三大优势：

数据采集率要高得多，尤其是在数据库规模较大的情况下。
查询性能从相当于数量级更大。
时间导向的功能。

而且由于TimescaleDB仍然允许您使用PostgreSQL的全部功能和工具 - 例如，与关系表联接，通过PostGIS进行地理空间查询，以及任何可以说PostgreSQL的连接器 - 都没有理由不使用TimescaleDB来存储时间序列PostgreSQL节点中的数据。pg_dump``pg_restore

更高的摄取率

对于时间序列数据，TimescaleDB比PostgreSQL实现更高且更稳定的采集速率。正如我们的架构讨论中所描述的那样，只要索引表不能再适应内存，PostgreSQL的性能就会显着下降。

特别是，无论何时插入新行，数据库都需要更新表中每个索引列的索引（例如B树），这将涉及从磁盘交换一个或多个页面。在这个问题上抛出更多的内存只会拖延不可避免的，一旦您的时间序列表达到数千万行，每秒10K-100K +行的吞吐量就会崩溃到每秒数百行。

TimescaleDB通过大量利用时空分区来解决这个问题，即使在单台机器上运行也是如此。因此，对最近时间间隔的所有写入操作仅适用于保留在内存中的表，因此更新任何二级索引的速度也很快。

基准测试显示了这种方法的明显优势。数据库客户端插入适度大小的包含时间，设备标记集和多个数字指标（在本例中为10）的批量数据，以下10亿行（在单台计算机上）的基准测试模拟常见监控方案。在这里，实验在具有网络连接的SSD存储的标准Azure VM（DS4 v2,8核心）上执行。

我们观察到PostgreSQL和TimescaleDB对于前20M请求的启动速度大约相同（分别为106K和114K），或者每秒超过1M指标。然而，在大约五千万行中，PostgreSQL的表现开始急剧下降。在过去的100M行中，它的平均值仅为5K行/秒，而TimescaleDB保留了111K行/秒的吞吐量。

简而言之，Timescale在PostgreSQL的总时间的十五分之一中加载了十亿行数据库，并且吞吐量超过了PostgreSQL在这些较大规模时的20倍。

我们的TimescaleDB基准测试表明，即使使用单个磁盘，它仍能保持超过10B行的恒定性能。

此外，用户在一台计算机上利用多个磁盘时，可以为数以十亿计的行提供稳定的性能，无论是采用RAID配置，还是使用TimescaleDB支持在多个磁盘上传播单个超级缓存（通过多个表空间传统的PostgreSQL表）。

卓越或类似的查询性能

在单磁盘机器上，许多只执行索引查找或表扫描的简单查询在PostgreSQL和TimescaleDB之间表现相似。

例如，在具有索引时间，主机名和CPU使用率信息的100M行表上，对于每个数据库，以下查询将少于5毫秒：

SELECT date_trunc('minute', time) AS minute, max(user_usage)
  FROM cpu
  WHERE hostname = 'host_1234'
    AND time >= '2017-01-01 00:00' AND time < '2017-01-01 01:00'
  GROUP BY minute ORDER BY minute;

涉及对索引进行基本扫描的类似查询在两者之间也是等效的：

SELECT * FROM cpu
  WHERE usage_user > 90.0
    AND time >= '2017-01-01' AND time < '2017-01-02';

涉及基于时间的GROUP BY的较大查询 - 在面向时间的分析中很常见 - 通常在TimescaleDB中实现卓越的性能。

例如，当整个（超）表为100M行时，接触33M行的以下查询在TimescaleDB中速度提高5倍，而在1B行时速度提高约2倍。

SELECT date_trunc('hour', time) as hour,
    hostname, avg(usage_user)
  FROM cpu
  WHERE time >= '2017-01-01' AND time < '2017-01-02'
  GROUP BY hour, hostname
  ORDER BY hour;

此外，可以约时间订购专理等查询可以多在TimescaleDB更好的性能。

例如，TimescaleDB引入了基于时间的“合并追加”优化，以最小化必须处理以执行以下操作的组的数量（考虑到时间已经被排序）。对于我们的100M行表，这导致查询延迟比PostgreSQL快396倍（82ms vs. 32566ms）。

SELECT date_trunc('minute', time) AS minute, max(usage_user)
  FROM cpu
  WHERE time < '2017-01-01'
  GROUP BY minute
  ORDER BY minute DESC
  LIMIT 5;

我们将很快发布PostgreSQL和TimescaleDB之间更完整的基准测试比较，以及复制我们基准的软件。

我们的查询基准测试的高级结果是，对于几乎所有我们已经尝试过的查询，TimescaleDB都可以为PostgreSQL 实现类似或优越（或极其优越）的性能。

与PostgreSQL相比，TimescaleDB的一项额外成本是更复杂的计划（假设单个可超集可由许多块组成）。这可以转化为几毫秒的计划时间，这对于非常低延迟的查询（<10ms）可能具有不成比例的影响。

时间导向的功能

TimescaleDB还包含许多在传统关系数据库中没有的时间导向功能。这些包括特殊查询优化（如上面的合并附加），它为面向时间的查询以及其他面向时间的函数（其中一些在下面列出）提供了一些巨大的性能改进。

面向时间的分析

TimescaleDB包含面向时间分析的新功能，其中包括以下一些功能：

时间分段：标准功能的更强大的版本，它允许任意的时间间隔（例如5分钟，6小时等），以及灵活的分组和偏移，而不仅仅是第二，分钟，小时等。date_trunc
最后和第一个聚合：这些函数允许您按另一个列的顺序获取一列的值。例如，将返回基于组内时间的最新温度值（例如，一小时）。last(temperature, time)

这些类型的函数能够实现非常自然的面向时间的查询。例如，以下财务查询打印每个资产的开盘价，收盘价，最高价和最低价。

SELECT time_bucket('3 hours', time) AS period
    asset_code,
    first(price, time) AS opening, last(price, time) AS closing,
    max(price) AS high, min(price) AS low
  FROM prices
  WHERE time > NOW() - interval '7 days'
  GROUP BY period, asset_code
  ORDER BY period DESC, asset_code;

通过辅助列进行排序的能力（甚至不同于集合）能够实现一些强大的查询类型。例如，财务报告中常见的技术是“双时态建模”，它们分别从与记录观察时间有关的观察时间的原因出发。在这样的模型中，更正插入为新行（具有更新的time_recorded字段），并且不替换现有数据。last

以下查询返回每个资产的每日价格，按最新记录的价格排序。

SELECT time_bucket('1 day', time) AS day,
    asset_code,
    last(price, time_recorded)
  FROM prices
  WHERE time > '2017-01-01'
  GROUP BY day, asset_code
  ORDER BY day DESC, asset_code;

有关TimescaleDB当前（和增长中）时间功能列表的更多信息，请参阅我们的API。

面向时间的数据管理

TimescaleDB还提供了某些在PostgreSQL中不易获取或执行的数据管理功能。例如，在处理时间序列数据时，数据通常会很快建立起来。因此，您希望按照“仅存储一周原始数据”的方式编写数据保留策略。

实际上，将这与使用连续聚合相结合是很常见的，因此您可以保留两个可改写的数据：一个包含原始数据，另一个包含已经汇总为精细或小时聚合的数据。然后，您可能需要在两个（超）表上定义不同的保留策略，以长时间存储汇总的数据。

TimescaleDB允许通过其功能有效地删除块级别的旧数据，而不是行级别的旧数据。drop_chunks

SELECT drop_chunks(interval '7 days', 'conditions');

这将删除只包含比此持续时间早的数据的可超级“条件”中的所有块（文件），而不是删除块中的任何单独数据行。这避免了底层数据库文件中的碎片，这反过来又避免了在非常大的表格中可能过于昂贵的抽真空的需要。

有关更多详细信息，请参阅我们的数据保留讨论，包括如何自动执行数据保留策略。

TimescaleDB之于NoSQL

与一般的NoSQL数据库（例如MongoDB，Cassandra）或更专门的时间导向数据库（例如InfluxDB，KairosDB）相比，TimescaleDB提供了定性和定量差异：

普通SQL：即使在规模上，TimescaleDB也可以为时间序列数据提供标准SQL查询的功能。大多数（所有？）NoSQL数据库都需要学习新的查询语言或使用最好的“SQL-ish”（它仍然与现有工具兼容）。
操作简单：使用TimescaleDB，您只需要为关系数据和时间序列数据管理一个数据库。否则，用户通常需要将数据存储到两个数据库中：“正常”关系数据库和第二个时间序列数据库。
JOIN可以通过关系数据和时间序列数据执行。
对于不同的查询集，查询性能更快。在NoSQL数据库中，更复杂的查询通常是缓慢或全表扫描，而有些数据库甚至无法支持许多自然查询。
**像PostgreSQL一样管理，**并继承对不同数据类型和索引（B树，哈希，范围，BRIN，GiST，GIN）的支持。
对地理空间数据的本地支持：存储在TimescaleDB中的数据可以利用PostGIS的几何数据类型，索引和查询。
第三方工具：TimescaleDB支持任何可以说SQL的东西，包括像Tableau这样的BI工具。

何时不使用TimescaleDB？

然后，如果以下任一情况属实，则可能不想使用TimescaleDB：

简单的读取要求：如果您只需要快速键值查找或单列累积，则内存或列导向数据库可能更合适。前者显然不能扩展到相同的数据量，但是，后者的性能明显低于更复杂的查询。
非常稀疏或非结构化的数据：尽管TimescaleDB利用PostgreSQL对JSON / JSONB格式的支持，并且相当有效地处理稀疏性（空值的位图），但在某些情况下，无模式体系结构可能更合适。
重要的压缩是一个优先事项：基准测试显示在ZFS上运行的TimescaleDB获得约4倍的压缩率，但压缩优化的列存储可能更适合于更高的压缩率。
不频繁或离线分析：如果响应时间较慢（或响应时间限于少量预先计算的度量标准），并且您不希望许多应用程序/用户同时访问该数据，则可以避免使用数据库，而只是将数据存储在分布式文件系统中。

安装

Mac

直接使用brew安装，最省事的方法，可以连PostgreSQL和PostGIS一起装了。

# Add our tap
brew tap timescale/tap

# To install
brew install timescaledb

# Post-install to move files to appropriate place
/usr/local/bin/timescaledb_move.sh

CentOS

sudo yum install -y https://download.postgresql.org/pub/repos/yum/9.6/redhat/fedora-7.2-x86_64/pgdg-redhat10-10-1.noarch.rpm


wget https://timescalereleases.blob.core.windows.net/rpm/timescaledb-0.9.0-postgresql-9.6-0.x86_64.rpm
# For PostgreSQL 10:
wget https://timescalereleases.blob.core.windows.net/rpm/timescaledb-0.9.0-postgresql-10-0.x86_64.rpm

# To install
sudo yum install timescaledb

配置

在postgresql.conf中添加以下配置，即可在PostgreSQL启动时加载该插件。

shared_preload_libraries = 'timescaledb'

在数据库中执行以下命令以创建timescaledb扩展。

CREATE EXTENSION timescaledb;

调参

对timescaledb比较重要的参数是锁的数量。

TimescaleDB在很大程度上依赖于表分区来扩展时间序列工作负载，这对锁管理有影响。在查询过程中，可修改需要在许多块（子表）上获取锁，这会耗尽所允许的锁的数量的默认限制。这可能会导致如下警告：

psql: FATAL:  out of shared memory
HINT:  You might need to increase max_locks_per_transaction.

为了避免这个问题，有必要修改默认值（通常是64），增加最大锁的数量。由于更改此参数需要重新启动数据库，因此建议预估未来的增长。对大多数情况，推荐配置为：max_locks_per_transaction

max_locks_per_transaction = 2 * num_chunks

num_chunks是在**超级表（HyperTable)中可能存在的块（chunk）**数量上限。

这种配置是考虑到对超级表查询可能申请锁的数量粗略等于超级表中的块数量，如果使用索引的话还要翻倍。

注意这个参数并不是精确的限制，它只是控制每个事物中平均的对象锁数量。

创建超级表

创建超表

为了创建一个可改写的，你从一个普通的SQL表开始，然后通过函数（API参考）将它转换为一个可改写的。create_hypertable

以下示例创建一个可随时间跨越一系列设备来跟踪温度和湿度的可调整高度。

-- We start by creating a regular SQL table

CREATE TABLE conditions (
  time        TIMESTAMPTZ       NOT NULL,
  location    TEXT              NOT NULL,
  temperature DOUBLE PRECISION  NULL,
  humidity    DOUBLE PRECISION  NULL
);

接下来，把它变成一个超表：create_hypertable

-- This creates a hypertable that is partitioned by time
--   using the values in the `time` column.

SELECT create_hypertable('conditions', 'time');

-- OR you can additionally partition the data on another
--   dimension (what we call 'space partitioning').
-- E.g., to partition `location` into 4 partitions:

SELECT create_hypertable('conditions', 'time', 'location', 4);

插入和查询

通过普通的SQL 命令将数据插入到hypertable中，例如使用毫秒时间戳：INSERT

INSERT INTO conditions(time, location, temperature, humidity)
  VALUES (NOW(), 'office', 70.0, 50.0);

同样，查询数据是通过正常的SQL 命令完成的。SELECT

SELECT * FROM conditions ORDER BY time DESC LIMIT 100;

SQL 和命令也按预期工作。有关使用TimescaleDB标准SQL接口的更多示例，请参阅我们的使用页面。UPDATE``DELETE

监控PG中的表大小

PostgreSQL中的表对应着许多物理文件，本文介绍如何统计一张表在PostgreSQL的实际大小

著： 冯若航（@Vonng） | 2018-05-14

表的空间布局

宽泛意义上的表（Table），包含了本体表与TOAST表两个部分：

本体表，存储关系本身的数据，即狭义的关系，relkind='r'。
TOAST表，与本体表一一对应，存储过大的字段，relinkd='t'。

而每个表，又由主体与索引两个**关系（Relation）**组成（对本体表而言，可以没有索引关系）

主体关系：存储元组。
索引关系：存储索引元组。

每个关系又可能会有四种分支：

main: 关系的主文件，编号为0
fsm：保存关于main分支中空闲空间的信息，编号为1
vm：保存关于main分支中可见性的信息，编号为2
init：用于不被日志记录（unlogged）的的表和索引，很少见的特殊分支，编号为3

每个分支存储为磁盘上的一到多个文件：超过1GB的文件会被划分为最大1GB的多个段。

综上所述，一个表并不是看上去那么简单，它由几个关系组成：

本体表的主体关系（单个）
本体表的索引（多个）
TOAST表的主体关系（单个）
TOAST表的索引（单个）

而每个关系实际上可能又包含了1~3个分支：main（必定存在），fsm，vm。

获取表的附属关系

使用下列查询，列出所有的分支oid。

select
  nsp.nspname,
  rel.relname,
  rel.relnamespace    as nspid,
  rel.oid             as relid,
  rel.reltoastrelid   as toastid,
  toastind.indexrelid as toastindexid,
  ind.indexes
from
  pg_namespace nsp
  join pg_class rel on nsp.oid = rel.relnamespace
  , LATERAL ( select array_agg(indexrelid) as indexes from pg_index where indrelid = rel.oid) ind
  , LATERAL ( select indexrelid from pg_index where indrelid = rel.reltoastrelid) toastind
where nspname not in ('pg_catalog', 'information_schema') and rel.relkind = 'r';

 nspname |  relname   |  nspid  |  relid  | toastid | toastindexid |      indexes
---------+------------+---------+---------+---------+--------------+--------------------
 public  | aoi        | 4310872 | 4320271 | 4320274 |      4320276 | {4325606,4325605}
 public  | poi        | 4310872 | 4332324 | 4332327 |      4332329 | {4368886}

统计函数

PG提供了一系列函数用于确定各个部分占用的空间大小。

函数	统计口径
`pg_total_relation_size(oid)`	整个关系，包括表，索引，TOAST等。
`pg_indexes_size(oid)`	关系索引部分所占空间
`pg_table_size(oid)`	关系中除索引外部分所占空间
`pg_relation_size(oid)`	获取一个关系主文件部分的大小（main分支）
`pg_relation_size(oid, 'main')`	获取关系`main`分支大小
`pg_relation_size(oid, 'fsm')`	获取关系`fsm`分支大小
`pg_relation_size(oid, 'vm')`	获取关系`vm`分支大小
`pg_relation_size(oid, 'init')`	获取关系`init`分支大小

虽然在物理上一张表由这么多文件组成，但从逻辑上我们通常只关心两个东西的大小：表与索引。因此这里要用到的主要就是两个函数：pg_indexes_size与pg_table_size，对普通表其和为pg_total_relation_size。

而通常表大小的部分可以这样计算：

 pg_table_size(relid)
 	= pg_relation_size(relid, 'main') 
 	+ pg_relation_size(relid, 'fsm') 
 	+ pg_relation_size(relid, 'vm') 
 	+ pg_total_relation_size(reltoastrelid)
 	
 pg_indexes_size(relid)
 	= (select sum(pg_total_relation_size(indexrelid)) where indrelid = relid)

注意，TOAST表也有自己的索引，但有且仅有一个，因此使用pg_total_relation_size(reltoastrelid)可计算TOAST表的整体大小。

例：统计某一张表及其相关关系UDTF

SELECT
  oid,
  relname,
  relnamespace::RegNamespace::Text               as nspname,
  relkind                                        as relkind,
  reltuples                                      as tuples,
  relpages                                       as pages,
  pg_total_relation_size(oid)                    as size
  FROM pg_class
WHERE oid = ANY(array(SELECT 16418 as id -- main
UNION ALL SELECT indexrelid FROM pg_index WHERE indrelid = 16418 -- index
UNION ALL SELECT reltoastrelid FROM pg_class WHERE oid = 16418)); -- toast

可以将其包装为UDTF：pg_table_size_detail，便于使用：

CREATE OR REPLACE FUNCTION pg_table_size_detail(relation RegClass)
  RETURNS TABLE(
    id      oid,
    pid     oid,
    relname name,
    nspname text,
    relkind "char",
    tuples  bigint,
    pages   integer,
    size    bigint
  )
AS $$
BEGIN
  RETURN QUERY
  SELECT
    rel.oid,
    relation::oid,
    rel.relname,
    rel.relnamespace :: RegNamespace :: Text as nspname,
    rel.relkind                              as relkind,
    rel.reltuples::bigint                    as tuples,
    rel.relpages                             as pages,
    pg_total_relation_size(oid)              as size
  FROM pg_class rel
  WHERE oid = ANY (array(
      SELECT relation as id -- main
      UNION ALL SELECT indexrelid FROM pg_index WHERE indrelid = relation -- index
      UNION ALL SELECT reltoastrelid FROM pg_class WHERE oid = relation)); -- toast
END;
$$
LANGUAGE PlPgSQL;

SELECT * FROM pg_table_size_detail(16418);

返回结果样例：

geo=# select * from  pg_table_size_detail(4325625);
   id    |   pid   |        relname        | nspname  | relkind |  tuples  |  pages  |    size
---------+---------+-----------------------+----------+---------+----------+---------+-------------
 4325628 | 4325625 | pg_toast_4325625      | pg_toast | t       |   154336 |   23012 |   192077824
 4419940 | 4325625 | idx_poi_adcode_btree  | gaode    | i       | 62685464 |  172058 |  1409499136
 4419941 | 4325625 | idx_poi_cate_id_btree | gaode    | i       | 62685464 |  172318 |  1411629056
 4419942 | 4325625 | idx_poi_lat_btree     | gaode    | i       | 62685464 |  172058 |  1409499136
 4419943 | 4325625 | idx_poi_lon_btree     | gaode    | i       | 62685464 |  172058 |  1409499136
 4419944 | 4325625 | idx_poi_name_btree    | gaode    | i       | 62685464 |  335624 |  2749431808
 4325625 | 4325625 | gaode_poi             | gaode    | r       | 62685464 | 2441923 | 33714962432
 4420005 | 4325625 | idx_poi_position_gist | gaode    | i       | 62685464 |  453374 |  3714039808
 4420044 | 4325625 | poi_position_geohash6 | gaode    | i       | 62685464 |  172058 |  1409499136

例：关系大小详情汇总

select
  nsp.nspname,
  rel.relname,
  rel.relnamespace    as nspid,
  rel.oid             as relid,
  rel.reltoastrelid   as toastid,
  toastind.indexrelid as toastindexid,
  pg_total_relation_size(rel.oid)  as size,
  pg_relation_size(rel.oid) + pg_relation_size(rel.oid,'fsm') 
  + pg_relation_size(rel.oid,'vm') as relsize,
  pg_indexes_size(rel.oid)         as indexsize,
  pg_total_relation_size(reltoastrelid) as toastsize,
  ind.indexids,
  ind.indexnames,
  ind.indexsizes
from pg_namespace nsp
  join pg_class rel on nsp.oid = rel.relnamespace
  ,LATERAL ( select indexrelid from pg_index where indrelid = rel.reltoastrelid) toastind
  , LATERAL ( select  array_agg(indexrelid) as indexids,
                      array_agg(indexrelid::RegClass) as indexnames,
                      array_agg(pg_total_relation_size(indexrelid)) as indexsizes
              from pg_index where indrelid = rel.oid) ind
where nspname not in ('pg_catalog', 'information_schema') and rel.relkind = 'r';

PgAdmin安装配置

PgAdmin是一个管理PostgreSQL的GUI程序，用python写成，但实在是过于古早，需要一些额外配置。

著： 冯若航（@Vonng） | 2018-04-14

PgAdmin4的安装与配置

PgAdmin是一个为PostgreSQL定制设计的GUI。用起来很不错。可以以本地GUI程序或者Web服务的方式运行。因为Retina屏幕下面PgAdmin依赖的GUI组件显示效果有点问题，这里主要介绍如何以Web服务方式（Python Flask）配置运行PgAdmin4。

下载

PgAdmin可以从官方FTP下载。

postgresql网站FTP目录地址

wget https://ftp.postgresql.org/pub/pgadmin3/pgadmin4/v1.1/source/pgadmin4-1.1.tar.gz
tar -xf pgadmin4-1.1.tar.gz && cd pgadmin4-1.1/

也可以从官方Git Repo下载：

git clone git://git.postgresql.org/git/pgadmin4.git
cd pgadmin4

安装依赖

首先，需要安装Python，2或者3都可以。这里使用管理员权限安装Anaconda3发行版作为示例。

首先创建一个虚拟环境，当然直接上物理环境也是可以的……

conda create -n pgadmin python=3 anaconda

根据对应的Python版本，按照对应的依赖文件安装依赖。

sudo pip install -r requirements_py3.txt

配置选项

首先执行初始化脚本，创立PgAdmin的管理员用户。

python web/setup.py

按照提示输入Email和密码即可。

编辑web/config.py，修改默认配置，主要是改监听地址和端口。

DEFAULT_SERVER = 'localhost'
DEFAULT_SERVER_PORT = 5050

修改监听地址为0.0.0.0以便从任意IP访问。按需修改端口。

Bash与psql小技巧

一些PostgreSQL与Bash交互的技巧。

著： 冯若航（@Vonng） | 2018-04-07

一些PostgreSQL与Bash交互的技巧。

使用严格模式编写Bash脚本

使用Bash严格模式，可以避免很多无谓的错误。在Bash脚本开始的地方放上这一行很有用：

set -euo pipefail

-e：当程序返回非0状态码时报错退出
-u：使用未初始化的变量时报错，而不是当成NULL
-o pipefail：使用Pipe中出错命令的状态码（而不是最后一个）作为整个Pipe的状态码¹。

执行SQL脚本的Bash包装脚本

通过psql运行SQL脚本时，我们期望有这么两个功能：

能向脚本中传入变量
脚本出错后立刻中止（而不是默认行为的继续执行）

这里给出了一个实际例子，包含了上述两个特性。使用Bash脚本进行包装，传入两个参数。

#!/usr/bin/env bash
set -euo pipefail

if [ $# != 2 ]; then
    echo "please enter a db host and a table suffix"
    exit 1
fi

export DBHOST=$1
export TSUFF=$2

psql \
    -X \
    -U user \
    -h $DBHOST \
    -f /path/to/sql/file.sql \
    --echo-all \
    --set AUTOCOMMIT=off \
    --set ON_ERROR_STOP=on \
    --set TSUFF=$TSUFF \
    --set QTSTUFF=\'$TSUFF\' \
    mydatabase

psql_exit_status = $?

if [ $psql_exit_status != 0 ]; then
    echo "psql failed while trying to run this sql script" 1>&2
    exit $psql_exit_status
fi

echo "sql script successful"
exit 0

一些要点：

参数TSTUFF会传入SQL脚本中，同时作为一个裸值和一个单引号包围的值，因此，裸值可以当成表名，模式名，引用值可以当成字符串值。
使用-X选项确保当前用户的.psqlrc文件不会被自动加载
将所有消息打印到控制台，这样可以知道脚本的执行情况。(失效的时候很管用)
使用ON_ERROR_STOP选项，当出问题时立即终止。
关闭AUTOCOMMIT，所以SQL脚本文件不会每一行都提交一次。取而代之的是SQL脚本中出现COMMIT时才提交。如果希望整个脚本作为一个事务提交，在sql脚本最后一行加上COMMIT（其它地方不要加），否则整个脚本就会成功运行却什么也没提交（自动回滚）。也可以使用--single-transaction标记来实现。

/path/to/sql/file.sql的内容如下:

begin;
drop index this_index_:TSUFF;
commit;

begin;
create table new_table_:TSUFF (
    greeting text not null default '');
commit;

begin;
insert into new_table_:TSUFF (greeting)
values ('Hello from table ' || :QTSUFF);
commit;

使用PG环境变量让脚本更简练

使用PG环境变量非常方便，例如用PGUSER替代-U <user>，用PGHOST替代-h <host>，用户可以通过修改环境变量来切换数据源。还可以通过Bash为这些环境变量提供默认值。

#!/bin/bash

set -euo pipefail

# Set these environmental variables to override them,
# but they have safe defaults.
export PGHOST=${PGHOST-localhost}
export PGPORT=${PGPORT-5432}
export PGDATABASE=${PGDATABASE-my_database}
export PGUSER=${PGUSER-my_user}
export PGPASSWORD=${PGPASSWORD-my_password}

RUN_PSQL="psql -X --set AUTOCOMMIT=off --set ON_ERROR_STOP=on "

${RUN_PSQL} <<SQL
select blah_column 
  from blahs 
 where blah_column = 'foo';
rollback;
SQL

在单个事务中执行一系列SQL命令

你有一个写满SQL的脚本，希望将整个脚本作为单个事务执行。一种经常出现的情况是在最后忘记加一行COMMIT。一种解决办法是使用—single-transaction标记：

psql \
    -X \
    -U myuser \
    -h myhost \
    -f /path/to/sql/file.sql \
    --echo-all \
    --single-transaction \
    --set AUTOCOMMIT=off \
    --set ON_ERROR_STOP=on \
    mydatabase

file.sql的内容变为：

insert into foo (bar) values ('baz');
insert into yikes (mycol) values ('hello');

两条插入都会被包裹在同一对BEGIN/COMMIT中。

让多行SQL语句更美观

#!/usr/bin/env bash
set -euo pipefail

RUN_ON_MYDB="psql -X -U myuser -h myhost --set ON_ERROR_STOP=on --set AUTOCOMMIT=off mydb"

$RUN_ON_MYDB <<SQL
drop schema if exists new_my_schema;
create table my_new_schema.my_new_table (like my_schema.my_table);
create table my_new_schema.my_new_table2 (like my_schema.my_table2);
commit;
SQL

# 使用'包围的界定符意味着HereDocument中的内容不会被Bash转义。
$RUN_ON_MYDB <<'SQL'
create index my_new_table_id_idx on my_new_schema.my_new_table(id);
create index my_new_table2_id_idx on my_new_schema.my_new_table2(id);
commit;
SQL

也可以使用Bash技巧，将多行语句赋值给变量，并稍后使用。

注意，Bash会自动清除多行输入中的换行符。实际上整个Here Document中的内容在传输时会重整为一行，你需要添加合适的分隔符，例如分号，来避免格式被搞乱。

CREATE_MY_TABLE_SQL=$(cat <<EOF
    create table foo (
        id bigint not null,
        name text not null
    );
EOF
)

$RUN_ON_MYDB <<SQL
$CREATE_MY_TABLE_SQL
commit;
SQL

如何将单个SELECT标量结果赋值给Bash变量

CURRENT_ID=$($PSQL -X -U $PROD_USER -h myhost -P t -P format=unaligned $PROD_DB -c "select max(id) from users")
let NEXT_ID=CURRENT_ID+1
echo "next user.id is $NEXT_ID"

echo "about to reset user id sequence on other database"
$PSQL -X -U $DEV_USER $DEV_DB -c "alter sequence user_ids restart with $NEXT_ID"

如何将单行结果赋给Bash变量

并且每个变量都以列名命名。

read username first_name last_name <<< $(psql \
    -X \
    -U myuser \
    -h myhost \
    -d mydb \
    --single-transaction \
    --set ON_ERROR_STOP=on \
    --no-align \
    -t \
    --field-separator ' ' \
    --quiet \
    -c "select username, first_name, last_name from users where id = 5489")

echo "username: $username, first_name: $first_name, last_name: $last_name"

也可以使用数组的方式

#!/usr/bin/env bash
set -euo pipefail

declare -a ROW=($(psql \
    -X \
    -h myhost \
    -U myuser \
    -c "select username, first_name, last_name from users where id = 5489" \
    --single-transaction \
    --set AUTOCOMMIT=off \
    --set ON_ERROR_STOP=on \
    --no-align \
    -t \
    --field-separator ' ' \
    --quiet \
    mydb))

username=${ROW[0]}
first_name=${ROW[1]}
last_name=${ROW[2]}

echo "username: $username, first_name: $first_name, last_name: $last_name"

如何在Bash脚本中迭代查询结果集

#!/usr/bin/env bash
set -euo pipefail
PSQL=/usr/bin/psql

DB_USER=myuser
DB_HOST=myhost
DB_NAME=mydb

$PSQL \
    -X \
    -h $DB_HOST \
    -U $DB_USER \
    -c "select username, password, first_name, last_name from users" \
    --single-transaction \
    --set AUTOCOMMIT=off \
    --set ON_ERROR_STOP=on \
    --no-align \
    -t \
    --field-separator ' ' \
    --quiet \
    -d $DB_NAME \
| while read username password first_name last_name ; do
    echo "USER: $username $password $first_name $last_name"
done

也可以读进数组里：

#!/usr/bin/env bash
set -euo pipefail

PSQL=/usr/bin/psql

DB_USER=myuser
DB_HOST=myhost
DB_NAME=mydb

$PSQL \
    -X \
    -h $DB_HOST \
    -U $DB_USER \
    -c "select username, password, first_name, last_name from users" \
    --single-transaction \
    --set AUTOCOMMIT=off \
    --set ON_ERROR_STOP=on \
    --no-align \
    -t \
    --field-separator ' ' \
    --quiet \
    $DB_NAME | while read -a Record ; do

    username=${Record[0]}
    password=${Record[1]}
    first_name=${Record[2]}
    last_name=${Record[3]}

    echo "USER: $username $password $first_name $last_name"
done

如何使用状态表来控制多个PG任务

假设你有一份如此之大的工作，以至于你一次只想做一件事。您决定一次可以完成一项任务，而这对数据库来说更容易，而不是执行一个长时间运行的查询。您创建一个名为my_schema.items_to_process的表，其中包含要处理的每个项目的item_id，并且您将一列添加到名为done的items_to_process表中，该表默认为false。然后，您可以使用脚本从items_to_process中获取每个未完成项目，对其进行处理，然后在items_to_process中将该项目更新为done = true。一个bash脚本可以这样做：

#!/usr/bin/env bash
set -euo pipefail

PSQL="/u99/pgsql-9.1/bin/psql"
DNL_TABLE="items_to_process"
#DNL_TABLE="test"
FETCH_QUERY="select item_id from my_schema.${DNL_TABLE} where done is false limit 1"

process_item() {
    local item_id=$1
    local dt=$(date)
    echo "[${dt}] processing item_id $item_id"
    $PSQL -X -U myuser -h myhost -c "insert into my_schema.thingies select thingie_id, salutation, name, ddr from thingies where item_id = $item_id and salutation like 'Mr.%'" mydb
}

item_id=$($PSQL -X -U myuser -h myhost -P t -P format=unaligned -c "${FETCH_QUERY}" mydb)
dt=$(date)
while [ -n "$item_id" ]; do
    process_item $item_id
    echo "[${dt}] marking item_id $item_id as done..."
    $PSQL -X -U myuser -h myhost -c "update my_schema.${DNL_TABLE} set done = true where item_id = $item_id" mydb
    item_id=$($PSQL -X -U myuser -h myhost -P t -P format=unaligned -c "${FETCH_QUERY}" mydb)
    dt=$(date)
done

跨数据库拷贝表

有很多方式可以实现这一点，利用psql的\copy命令可能是最简单的方式。假设你有两个数据库olddb与newdb，有一张users表需要从老库同步到新库。如何用一条命令实现：

psql \
    -X \
    -U user \
    -h oldhost \
    -d olddb \
    -c "\\copy users to stdout" \
| \
psql \
    -X \
    -U user \
    -h newhost \
    -d newdb \
    -c "\\copy users from stdin"

一个更困难的例子：假如你的表在老数据库中有三列：first_name, middle_name, last_name。

但在新数据库中只有两列，first_name，last_name，则可以使用：

psql \
    -X \
    -U user \
    -h oldhost \
    -d olddb \
    -c "\\copy (select first_name, last_name from users) to stdout" \
| \
psql \
    -X \
    -U user \
    -h newhost \
    -d newdb \
    -c "\\copy users from stdin"

获取表定义的方式

pg_dump \
    -U db_user \
    -h db_host \
    -p 55432 \
    --table my_table \
    --schema-only my_db

将bytea列中的二进制数据导出到文件

注意bytea列，在PostgreSQL 9.0 以上是使用十六进制表示的，带有一个恼人的前缀\x，可以用substring去除。

#!/usr/bin/env bash
set -euo pipefail

psql \
    -P t \
    -P format=unaligned \
    -X \
    -U myuser \
    -h myhost \
    -c "select substring(my_bytea_col::text from 3) from my_table where id = 12" \
    mydb \
| xxd -r -p > dump.txt

将文件内容作为一个列的值插入

有两种思路完成这件事，第一种是在外部拼SQL，第二种是在脚本中作为变量。

CREATE TABLE sample(
	filename	INTEGER,
    value		JSON
);

psql <<SQL
\set content `cat ${filename}`
INSERT INTO sample VALUES(\'${filename}\',:'content')
SQL

显示特定数据库中特定表的统计信息

#!/usr/bin/env bash
set -euo pipefail
if [ -z "$1" ]; then
    echo "Usage: $0 table [db]"
    exit 1
fi

SCMTBL="$1"
SCHEMANAME="${SCMTBL%%.*}"  # everything before the dot (or SCMTBL if there is no dot)
TABLENAME="${SCMTBL#*.}"  # everything after the dot (or SCMTBL if there is no dot)

if [ "${SCHEMANAME}" = "${TABLENAME}" ]; then
    SCHEMANAME="public"
fi

if [ -n "$2" ]; then
    DB="$2"
else
    DB="my_default_db"
fi

PSQL="psql -U my_default_user -h my_default_host -d $DB -x -c "

$PSQL "
select '-----------' as \"-------------\", 
       schemaname,
       tablename,
       attname,
       null_frac,
       avg_width,
       n_distinct,
       correlation,
       most_common_vals,
       most_common_freqs,
       histogram_bounds
  from pg_stats
 where schemaname='$SCHEMANAME'
   and tablename='$TABLENAME';
" | grep -v "\-\[ RECORD "

使用方式

./table-stats.sh myschema.mytable

对于public模式中的表

./table-stats.sh mytable

连接其他数据库

./table-stats.sh mytable myotherdb

将psql的默认输出转换为Markdown表格

alias pg2md=' sed '\''s/+/|/g'\'' | sed '\''s/^/|/'\'' | sed '\''s/$/|/'\'' |  grep -v rows | grep -v '\''||'\'''

# Usage
psql -c 'SELECT * FROM pg_database' | pg2md

输出的结果贴到Markdown编辑器即可。

管道程序的退出状态放置在环境变量数组PIPESTATUS中 ↩︎

PostgreSQL例行维护

汽车需要上油，数据库也需要维护保养。对Pg而言，有三项比较重要的维护工作：备份、重整、清理

著： 冯若航（@Vonng） | 2018-02-10

汽车需要上油，数据库也需要维护保养。

PG中的维护工作

对Pg而言，有三项比较重要的维护工作：备份、重整、清理

备份（backup）：最重要的例行工作，生命线。
- 制作基础备份
- 归档增量WAL
重整（repack）
- 重整表与索引能消除其中的膨胀，节约空间，确保查询性能不会劣化。
清理（vacuum）
- 维护表与库的年龄，避免事务ID回卷故障。
- 更新统计数据，生成更好的执行计划。
- 回收死元组。节约空间，提高性能。

备份

备份可以使用pg_backrest 作为一条龙解决方案，但这里考虑使用脚本进行备份。

参考：pg-backup

重整

重整使用pg_repack，PostgreSQL自带源里包含了pg_repack

参考：pg-repack

清理

虽然有AutoVacuum，但手动执行Vacuum仍然有帮助。检查数据库的年龄，当出现老化时及时上报。

参考：pg-vacuum

PgSQL备份恢复概览

备份是DBA的安身立命之本，有备份，就不用慌。

著： 冯若航（@Vonng） | 2018-02-09

备份是DBA的安身立命之本，有备份，就不用慌。

备份有三种形式：SQL转储，文件系统备份，连续归档

1. SQL转储

SQL 转储方法的思想是：

创建一个由SQL命令组成的文件，服务器能利用其中的SQL命令重建与转储时状态一样的数据库。

1.1 转储

工具pg_dump、pg_dumpall用于进行SQL转储。结果输出到stdout。

pg_dump dbname > filename
pg_dump dbname -f filename

pg_dump是一个普通的PostgreSQL客户端应用。可以在任何可以访问该数据库的远端主机上进行备份工作。
pg_dump不会以任何特殊权限运行，必须要有你想备份的表的读权限，同时它也遵循同样的HBA机制。
要备份整个数据库，几乎总是需要一个数据库超级用户。
该备份方式的重要优势是，它是跨版本、跨机器架构的备份方式。（最远回溯至7.0）
pg_dump的备份是内部一致的，是转储开始时刻的数据库快照，转储期间的更新不被包括在内。
pg_dump不会阻塞其他数据库操作，但需要排它锁的命令除外（例如大多数 ALTER TABLE）

1.2 恢复

文本转储文件可由psql读取，从转储中恢复的常用命令是：

psql dbname < infile

这条命令不会创建数据库dbname，必须在执行psql前自己从template0创建。例如，用命令createdb -T template0 dbname。默认template1和template0是一样的，新创建的数据库默认以template1为模板。

CREATE DATABASE dbname TEMPLATE template0;
非文本文件转储可以使用pg_restore工具来恢复。
在开始恢复之前，转储库中对象的拥有者以及在其上被授予了权限的用户必须已经存在。如果它们不存在，那么恢复过程将无法将对象创建成具有原来的所属关系以及权限（有时候这就是你所需要的，但通常不是）。
恢复时遇到错误自动终止，则可以设置ON_ERROR_STOP变量来运行psql，遇到SQL错误后退出并返回状态3：

psql --set ON_ERROR_STOP=on dbname < infile

恢复时可以使用单个事务来保证要么完全正确恢复，要么完全回滚。使用-1或--single-transaction
pg_dump和psql可以通过管道on-the-fly做转储与恢复

pg_dump -h host1 dbname | psql -h host2 dbname

1.3 全局转储

一些信息属于数据库集簇，而不是单个数据库的，例如角色、表空间。如果希望转储这些，可使用pg_dumpall

pg_dumpall > outfile

如果只想要全局的数据（角色与表空间），则可以使用-g, --globals-only参数。

转储的结果可以使用psql恢复，通常将转储载入到一个空集簇中可以用postgres作为数据库名

psql -f infile postgres

在恢复一个pg_dumpall转储时常常需要具有数据库超级用户访问权限，因为它需要恢复角色和表空间信息。
如果使用了表空间，请确保转储中的表空间路径适合于新的安装。
pg_dumpall工作步骤是，先创建角色、表空间转储，再为每一个数据库做pg_dump。这意味着每个数据库自身是一致的，但是不同数据库的快照并不同步。

1.4 命令实践

准备环境，创建测试数据库

psql postgres -c "CREATE DATABASE testdb;"
psql postgres -c "CREATE ROLE test_user LOGIN;"
psql testdb -c "CREATE TABLE test_table(i INTEGER);"
psql testdb -c "INSERT INTO test_table SELECT generate_series(1,16);"

# dump到本地文件
pg_dump testdb -f testdb.sql 

# dump并用xz压缩，-c指定从stdio接受，-d指定解压模式
pg_dump testdb | xz -cd > testdb.sql.xz

# dump，压缩，分割为1m的小块
pg_dump testdb | xz | split -b 1m - testdb.sql.xz
cat testdb.sql.xz* | xz -cd | psql # 恢复

# pg_dump 常用参数参考
-s --schema-only
-a --data-only
-t --table
-n --schema
-c --clean
-f --file

--inserts
--if-exists
-N --exclude-schema
-T --exclude-table

2. 文件系统转储

SQL 转储方法的思想是：拷贝数据目录的所有文件。为了得到一个可用的备份，所有备份文件都应当保持一致。

所以通常比而且为了得到一个可用的备份，所有备份文件都应当保持一致。

文件系统拷贝不做逻辑解析，只是简单拷贝文件。好处是执行快，省掉了逻辑解析和重建索引的时间，坏处是占用空间更大，而且只能用于整个数据库集簇的备份

最简单的方式：停机，直接拷贝数据目录的所有文件。
有办法通过文件系统（例如xfs）获得一致的冻结快照也可以不停机，但wal和数据目录必须是一致的。
可以通过制作pg_basebackup进行远程归档备份，可以不停机。
可以通过停机执行rsync的方式向远端增量同步数据变更。

3. PITR 连续归档与时间点恢复

Pg在运行中会不断产生WAL，WAL记录了操作日志，从某一个基础的全量备份开始回放后续的WAL，就可以恢复数据库到任意的时刻的状态。为了实现这样的功能，就需要配置WAL归档，将数据库生成的WAL不断保存起来。

WAL在逻辑上是一段无限的字节流。pg_lsn类型（bigint）可以标记WAL中的位置，pg_lsn代表一个WAL中的字节位置偏移量。但实践中WAL不是连续的一个文件，而被分割为每16MB一段。

WAL文件名是有规律的，而且归档时不允许更改。通常为24位十六进制数字，000000010000000000000003，其中前面8位十六进制数字表示时间线，后面的16位表示16MB块的序号。即lsn >> 24的值。

查看pg_lsn时，例如0/84A8300，只要去掉最后六位hex，就可以得到WAL文件序号的后面部分，这里，也就是8，如果使用的是默认时间线1，那么对应的WAL文件就是000000010000000000000008。

3.1 准备环境

# 目录：
# 使用/var/lib/pgsql/data 作为主库目录，使用/var/lib/pgsql/wal作为日志归档目录
# sudo mkdir /var/lib/pgsql && sudo chown postgres:postgres /var/lib/pgsql/
pg_ctl stop -D /var/lib/pgsql/data
rm -rf /var/lib/pgsql/{data,wal} && mkdir -p /var/lib/pgsql/{data,wal}

# 初始化：
# 初始化主库并修改配置文件
pg_ctl -D /var/lib/pgsql/data init 

# 配置文件
# 创建默认额外配置文件夹，并在postgresql.conf中配置include_dir
mkdir -p /var/lib/pgsql/data/conf.d
cat >> /var/lib/pgsql/data/postgresql.conf <<- 'EOF'
include_dir = 'conf.d'
EOF

3.2 配置自动归档命令

# 归档配置
# %p 代表 src wal path, %f 代表 filename
cat > /var/lib/pgsql/data/conf.d/archive.conf <<- 'EOF'
archive_mode = on
archive_command = 'conf.d/archive.sh %p %f'
EOF

# 归档脚本 
cat > /var/lib/pgsql/data/conf.d/archive.sh <<- 'EOF'
test ! -f /var/lib/pgsql/wal/${2} && cp ${1} /var/lib/pgsql/wal/${2}
EOF
chmod a+x /var/lib/pgsql/data/conf.d/archive.sh

归档脚本可以简单到只是一个cp，也可以非常复杂。但需要注意以下事项：

归档命令使用数据库用户postgres执行，最好放在0700的目录下面。
归档命令应当拒绝覆盖现有文件，出现覆盖时，返回一个错误代码。
归档命令可以通过reload配置更新。
处理归档失败时的情形
归档文件应当保留原有文件名。
WAL不会记录对配置文件的变更。
归档命令中：%p 会替换为生成待归档WAL的路径，而%f会替换为待归档WAL的文件名

归档脚本可以使用更复杂的逻辑，例如下面的归档命令，在归档目录中每天创建一个以日期YYYYMMDD命名的文件夹，在每天12点移除前一天的归档日志。每天的归档日志使用xz压缩存储。

wal_dir=/var/lib/pgsql/wal;
[[ $(date +%H%M) == 1200 ]] && rm -rf ${wal_dir}/$(date -d"yesterday" +%Y%m%d); /bin/mkdir -p ${wal_dir}/$(date +%Y%m%d) && \
test ! -f ${wal_dir}/ && \ 
xz -c %p > ${wal_dir}/$(date +%Y%m%d)/%f.xz

归档也可以使用外部专用备份工具进行。例如pgbackrest与barman等。

3.3 测试归档

# 启动数据库
pg_ctl -D /var/lib/pgsql/data start

# 确认配置
psql postgres -c "SELECT name,setting FROM pg_settings where name like '%archive%';"

在当前shell开启监视循环，不断查询WAL的位置，以及归档目录和pg_wal中的文件变化

for((i=0;i<100;i++)) do 
	sleep 1 && \
	ls /var/lib/pgsql/data/pg_wal && ls /var/lib/pgsql/data/pg_wal/archive_status/
	psql postgres -c 'SELECT pg_current_wal_lsn() as current, pg_current_wal_insert_lsn() as insert, pg_current_wal_flush_lsn() as flush;'
done

在另一个Shell中创建一张测试表foobar，包含单一的时间戳列，并引入负载，每秒写入一万条记录：

psql postgres -c 'CREATE TABLE foobar(ts TIMESTAMP);'
for((i=0;i<1000;i++)) do 
	sleep 1 && \
	psql postgres -c 'INSERT INTO foobar SELECT now() FROM generate_series(1,10000)' && \
	psql postgres -c 'SELECT pg_current_wal_lsn() as current, pg_current_wal_insert_lsn() as insert, pg_current_wal_flush_lsn() as flush;'
done

自然切换WAL

可以看到，当WAL LSN的位置超过16M（可以由后6个hex表示）之后，就会rotate到一个新的WAL文件，归档命令会将写完的WAL归档。

000000010000000000000001 archive_status
  current  |  insert   |   flush
-----------+-----------+-----------
 0/1FC2630 | 0/1FC2630 | 0/1FC2630
(1 row)

# rotate here

000000010000000000000001 000000010000000000000002 archive_status
000000010000000000000001.done
  current  |  insert   |   flush
-----------+-----------+-----------
 0/205F1B8 | 0/205F1B8 | 0/205F1B8

手工切换WAL

再开启一个Shell，执行pg_switch_wal，强制写入一个新的WAL文件

psql postgres -c 'SELECT pg_switch_wal();'

可以看到，虽然位置才到32C1D68，但立即就跳到了下一个16MB的边界点。

000000010000000000000001 000000010000000000000002 000000010000000000000003 archive_status
000000010000000000000001.done 000000010000000000000002.done
  current  |  insert   |   flush
-----------+-----------+-----------
 0/32C1D68 | 0/32C1D68 | 0/32C1D68
(1 row)

# switch here

000000010000000000000001 000000010000000000000002 000000010000000000000003 archive_status
000000010000000000000001.done 000000010000000000000002.done 000000010000000000000003.done
  current  |  insert   |   flush
-----------+-----------+-----------
 0/4000000 | 0/4000028 | 0/4000000
(1 row)

000000010000000000000001 000000010000000000000002 000000010000000000000003 000000010000000000000004 archive_status
000000010000000000000001.done 000000010000000000000002.done 000000010000000000000003.done
  current  |  insert   |   flush
-----------+-----------+-----------
 0/409CBA0 | 0/409CBA0 | 0/409CBA0
(1 row)

强制kill数据库

数据库因为故障异常关闭，重启之后，会从最近的检查点，也就是0/2FB0160开始重放WAL。

[17:03:37] vonng@vonng-mac /var/lib/pgsql
$  ps axu | grep postgres | grep data | awk '{print $2}' | xargs kill -9

[17:06:31] vonng@vonng-mac /var/lib/pgsql
$ pg_ctl -D /var/lib/pgsql/data start
pg_ctl: another server might be running; trying to start server anyway
waiting for server to start....2018-01-25 17:07:27.063 CST [9762] LOG:  listening on IPv6 address "::1", port 5432
2018-01-25 17:07:27.063 CST [9762] LOG:  listening on IPv4 address "127.0.0.1", port 5432
2018-01-25 17:07:27.064 CST [9762] LOG:  listening on Unix socket "/tmp/.s.PGSQL.5432"
2018-01-25 17:07:27.078 CST [9763] LOG:  database system was interrupted; last known up at 2018-01-25 17:06:01 CST
2018-01-25 17:07:27.117 CST [9763] LOG:  database system was not properly shut down; automatic recovery in progress
2018-01-25 17:07:27.120 CST [9763] LOG:  redo starts at 0/2FB0160
2018-01-25 17:07:27.722 CST [9763] LOG:  invalid record length at 0/49CBE78: wanted 24, got 0
2018-01-25 17:07:27.722 CST [9763] LOG:  redo done at 0/49CBE50
2018-01-25 17:07:27.722 CST [9763] LOG:  last completed transaction was at log time 2018-01-25 17:06:30.158602+08
2018-01-25 17:07:27.741 CST [9762] LOG:  database system is ready to accept connections
 done
server started

至此，WAL归档已经确认可以正常工作了。

3.4 制作基础备份

首先，查看当前WAL的位置：

$ psql postgres -c 'SELECT pg_current_wal_lsn() as current, pg_current_wal_insert_lsn() as insert, pg_current_wal_flush_lsn() as flush;'

  current  |  insert   |   flush
-----------+-----------+-----------
 0/49CBF20 | 0/49CBF20 | 0/49CBF20

使用pg_basebackup制作基础备份

psql postgres -c 'SELECT now();'
pg_basebackup -Fp -Pv -Xs -c fast -D /var/lib/pgsql/bkup

# 常用选项
-D  : 必选项，基础备份的位置。
-Fp : 备份格式: plain 普通文件 tar 归档文件
-Pv : -P 启用进度报告 -v 启用详细输出
-Xs : 在备份中包括备份期间产生的WAL日志 f:备份完后拉取 s:备份时流式传输
-c  : fast 立即执行Checkpoint而不是均摊IO spread:均摊IO
-R  : 设置recovery.conf

制作基础备份时，会立即创建一个检查点使得所有脏数据页落盘。

$ pg_basebackup -Fp -Pv -Xs -c fast -D /var/lib/pgsql/bkup
pg_basebackup: initiating base backup, waiting for checkpoint to complete
pg_basebackup: checkpoint completed
pg_basebackup: write-ahead log start point: 0/5000028 on timeline 1
pg_basebackup: starting background WAL receiver
45751/45751 kB (100%), 1/1 tablespace
pg_basebackup: write-ahead log end point: 0/50000F8
pg_basebackup: waiting for background process to finish streaming ...
pg_basebackup: base backup completed

3.5 使用备份

直接使用

最简单的使用方式，就是直接用pg_ctl启动它。

当recovery.conf不存在时，这样做会启动一个新的完整数据库实例，原原本本地保留了备份完成时的状态。数据库会并不会意识到自己是一个备份。而是以为自己上次没有正常关闭，应用pg_wal目录中自带的WAL进行修复，正常重启。

基础的全量备份可能每天或每周备份一次，要想恢复到最新的时刻，需要和WAL归档配合使用。

使用WAL归档追赶进度

可以在备份中数据库下创建一个recovery.conf文件，并指定restore_command选项。这样的话，当使用pg_ctl启动这个数据目录时，postgres会依次拉取所需的WAL，直到没有了为止。

cat >> /var/lib/pgsql/bkup/recovery.conf <<- 'EOF'
restore_command = 'cp /var/lib/pgsql/wal/%f %p' 
EOF

继续在原始主库中执行负载，这时候WAL的进度已经到了0/9060CE0，而制作备份的时候位置还在0/5000028。

启动备份之后，可以发现，备份数据库自动从归档文件夹拉取了5~8号WAL并应用。

$ pg_ctl start -D /var/lib/pgsql/bkup -o '-p 5433'
waiting for server to start....2018-01-25 17:35:35.001 CST [10862] LOG:  listening on IPv6 address "::1", port 5433
2018-01-25 17:35:35.001 CST [10862] LOG:  listening on IPv4 address "127.0.0.1", port 5433
2018-01-25 17:35:35.002 CST [10862] LOG:  listening on Unix socket "/tmp/.s.PGSQL.5433"
2018-01-25 17:35:35.016 CST [10863] LOG:  database system was interrupted; last known up at 2018-01-25 17:21:15 CST
2018-01-25 17:35:35.051 CST [10863] LOG:  starting archive recovery
2018-01-25 17:35:35.063 CST [10863] LOG:  restored log file "000000010000000000000005" from archive
2018-01-25 17:35:35.069 CST [10863] LOG:  redo starts at 0/5000028
2018-01-25 17:35:35.069 CST [10863] LOG:  consistent recovery state reached at 0/50000F8
2018-01-25 17:35:35.070 CST [10862] LOG:  database system is ready to accept read only connections
 done
server started
2018-01-25 17:35:35.081 CST [10863] LOG:  restored log file "000000010000000000000006" from archive
$ 2018-01-25 17:35:35.924 CST [10863] LOG:  restored log file "000000010000000000000007" from archive
2018-01-25 17:35:36.783 CST [10863] LOG:  restored log file "000000010000000000000008" from archive
cp: /var/lib/pgsql/wal/000000010000000000000009: No such file or directory
2018-01-25 17:35:37.604 CST [10863] LOG:  redo done at 0/8FFFF90
2018-01-25 17:35:37.604 CST [10863] LOG:  last completed transaction was at log time 2018-01-25 17:30:39.107943+08
2018-01-25 17:35:37.614 CST [10863] LOG:  restored log file "000000010000000000000008" from archive
cp: /var/lib/pgsql/wal/00000002.history: No such file or directory
2018-01-25 17:35:37.629 CST [10863] LOG:  selected new timeline ID: 2
cp: /var/lib/pgsql/wal/00000001.history: No such file or directory
2018-01-25 17:35:37.678 CST [10863] LOG:  archive recovery complete
2018-01-25 17:35:37.783 CST [10862] LOG:  database system is ready to accept connections

但是使用WAL归档的方式来恢复也有问题，例如查询主库与备库最新的数据记录，发现时间戳差了一秒。也就是说，主库还没有写完的WAL并没有被归档，因此也没有应用。

[17:37:22] vonng@vonng-mac /var/lib/pgsql
$ psql postgres -c 'SELECT max(ts) FROM foobar;'
            max
----------------------------
 2018-01-25 17:30:40.159684
(1 row)


[17:37:42] vonng@vonng-mac /var/lib/pgsql
$ psql postgres -p 5433 -c 'SELECT max(ts) FROM foobar;'
            max
----------------------------
 2018-01-25 17:30:39.097167
(1 row)

通常archive_command, restore_command主要用于紧急情况下的恢复，比如主库从库都挂了。因为还没有归档

3.6 指定进度

默认情况下，恢复将会一直恢复到 WAL 日志的末尾。下面的参数可以被用来指定一个更早的停止点。recovery_target、recovery_target_name、recovery_target_time和recovery_target_xid四个选项中最多只能使用一个，如果在配置文件中使用了多个，将使用最后一个。

上面四个恢复目标中，常用的是 recovery_target_time，用于指明将系统恢复到什么时间。

另外几个常用的选项包括：

recovery_target_inclusive (boolean) ：是否包括目标点，默认为true
recovery_target_timeline (string)：指定恢复到一个特定的时间线中。
recovery_target_action (enum)：指定在达到恢复目标时服务器应该立刻采取的动作。
- pause: 暂停恢复，默认选项，可通过pg_wal_replay_resume恢复。
- shutdown: 自动关闭。
- promote: 开始接受连接

例如在2018-01-25 18:51:20 创建了一个备份

$ psql postgres -c 'SELECT now();'
             now
------------------------------
 2018-01-25 18:51:20.34732+08
(1 row)


[18:51:20] vonng@vonng-mac ~
$ pg_basebackup -Fp -Pv -Xs -c fast -D /var/lib/pgsql/bkup
pg_basebackup: initiating base backup, waiting for checkpoint to complete
pg_basebackup: checkpoint completed
pg_basebackup: write-ahead log start point: 0/3000028 on timeline 1
pg_basebackup: starting background WAL receiver
33007/33007 kB (100%), 1/1 tablespace
pg_basebackup: write-ahead log end point: 0/30000F8
pg_basebackup: waiting for background process to finish streaming ...
pg_basebackup: base backup completed

之后运行了两分钟，到了2018-01-25 18:53:05我们发现有几条脏数据，于是从备份开始恢复，希望恢复到脏数据出现前一分钟的状态，例如2018-01-25 18:52

可以这样配置

cat >> /var/lib/pgsql/bkup/recovery.conf <<- 'EOF'
restore_command = 'cp /var/lib/pgsql/wal/%f %p' 
recovery_target_time = '2018-01-25 18:52:30'
recovery_target_action = 'promote'
EOF

当新的数据库实例完成恢复之后，可以看到它的状态确实回到了 18:52分，这正是我们期望的。

$ pg_ctl -D /var/lib/pgsql/bkup -o '-p 5433' start
waiting for server to start....2018-01-25 18:56:24.147 CST [13120] LOG:  listening on IPv6 address "::1", port 5433
2018-01-25 18:56:24.147 CST [13120] LOG:  listening on IPv4 address "127.0.0.1", port 5433
2018-01-25 18:56:24.148 CST [13120] LOG:  listening on Unix socket "/tmp/.s.PGSQL.5433"
2018-01-25 18:56:24.162 CST [13121] LOG:  database system was interrupted; last known up at 2018-01-25 18:51:22 CST
2018-01-25 18:56:24.197 CST [13121] LOG:  starting point-in-time recovery to 2018-01-25 18:52:30+08
2018-01-25 18:56:24.210 CST [13121] LOG:  restored log file "000000010000000000000003" from archive
2018-01-25 18:56:24.215 CST [13121] LOG:  redo starts at 0/3000028
2018-01-25 18:56:24.215 CST [13121] LOG:  consistent recovery state reached at 0/30000F8
2018-01-25 18:56:24.216 CST [13120] LOG:  database system is ready to accept read only connections
 done
server started
2018-01-25 18:56:24.228 CST [13121] LOG:  restored log file "000000010000000000000004" from archive
$ 2018-01-25 18:56:25.034 CST [13121] LOG:  restored log file "000000010000000000000005" from archive
2018-01-25 18:56:25.853 CST [13121] LOG:  restored log file "000000010000000000000006" from archive
2018-01-25 18:56:26.235 CST [13121] LOG:  recovery stopping before commit of transaction 649, time 2018-01-25 18:52:30.492371+08
2018-01-25 18:56:26.235 CST [13121] LOG:  redo done at 0/67CFD40
2018-01-25 18:56:26.235 CST [13121] LOG:  last completed transaction was at log time 2018-01-25 18:52:29.425596+08
cp: /var/lib/pgsql/wal/00000002.history: No such file or directory
2018-01-25 18:56:26.240 CST [13121] LOG:  selected new timeline ID: 2
cp: /var/lib/pgsql/wal/00000001.history: No such file or directory
2018-01-25 18:56:26.293 CST [13121] LOG:  archive recovery complete
2018-01-25 18:56:26.401 CST [13120] LOG:  database system is ready to accept connections
$

# query new server ，确实回到了18:52分
$ psql postgres -p 5433 -c 'SELECT max(ts) FROM foobar;'
            max
----------------------------
 2018-01-25 18:52:29.413911
(1 row)

3.7 时间线

每当归档文件恢复完成后，也就是服务器可以开始接受新的查询，写新的WAL的时候。会创建一个新的时间线用来区别新生成的WAL记录。WAL文件名由时间线和日志序号组成，因此新的时间线WAL不会覆盖老时间线的WAL。时间线主要用来解决复杂的恢复操作冲突，例如试想一个场景：刚才恢复到18:52分之后，新的服务器开始不断接受请求：

psql postgres -c 'CREATE TABLE foobar(ts TIMESTAMP);'
for((i=0;i<1000;i++)) do 
	sleep 1 && \
	psql -p 5433 postgres -c 'INSERT INTO foobar SELECT now() FROM generate_series(1,10000)' && \
	psql -p 5433 postgres -c 'SELECT pg_current_wal_lsn() as current, pg_current_wal_insert_lsn() as insert, pg_current_wal_flush_lsn() as flush;'
done

可以看到，WAL归档目录中出现了两个6号WAL段文件，如果没有前面的时间线作为区分，WAL就会被覆盖。

$ ls -alh wal
total 262160
drwxr-xr-x  12 vonng  wheel   384B Jan 25 18:59 .
drwxr-xr-x   6 vonng  wheel   192B Jan 25 18:51 ..
-rw-------   1 vonng  wheel    16M Jan 25 18:51 000000010000000000000001
-rw-------   1 vonng  wheel    16M Jan 25 18:51 000000010000000000000002
-rw-------   1 vonng  wheel    16M Jan 25 18:51 000000010000000000000003
-rw-------   1 vonng  wheel   302B Jan 25 18:51 000000010000000000000003.00000028.backup
-rw-------   1 vonng  wheel    16M Jan 25 18:51 000000010000000000000004
-rw-------   1 vonng  wheel    16M Jan 25 18:52 000000010000000000000005
-rw-------   1 vonng  wheel    16M Jan 25 18:52 000000010000000000000006
-rw-------   1 vonng  wheel    50B Jan 25 18:56 00000002.history
-rw-------   1 vonng  wheel    16M Jan 25 18:58 000000020000000000000006
-rw-------   1 vonng  wheel    16M Jan 25 18:59 000000020000000000000007

假设完成恢复之后又反悔了，则可以用基础备份通过指定recovery_target_timeline = '1' 再次恢复回第一次运行到18:53 时的状态。

3.8 其他注意事项

在Pg 10之前，哈希索引上的操作不会被记录在WAL中，需要在Slave上手工REINDEX。
不要在创建基础备份的时候修改任何模板数据库
注意表空间会严格按照字面值记录其路径，如果使用了表空间，恢复时要非常小心。

4. 制作备机

通过主从（master-slave），可以同时提高可用性与可靠性。

主从读写分离提高性能：写请求落在Master上，通过WAL流复制传输到从库上，从库接受读请求。
通过备份提高可靠性：当一台服务器故障时，可以立即由另一台顶上(promote slave or & make new slave)

通常主从、副本、备机这些属于高可用的话题。但从另一个角度来讲，备机也是备份的一种。

创建目录

sudo mkdir /var/lib/pgsql && sudo chown postgres:postgres /var/lib/pgsql/
mkdir -p /var/lib/pgsql/master /var/lib/pgsql/slave /var/lib/pgsql/wal

制作主库

pg_ctl -D /var/lib/pgsql/master init && pg_ctl -D /var/lib/pgsql/master start

创建用户

创建备库需要一个具有REPLICATION权限的用户，这里在Master中创建replication用户

psql postgres -c 'CREATE USER replication REPLICATION;'

为了创建从库，需要一个具有REPLICATION权限的用户，并在pg_hba中允许访问，10中默认允许：

local   replication     all                                     trust
host    replication     all             127.0.0.1/32            trust

制作备库

通过pg_basebackup创建一个slave实例。实际上是连接到Master实例，并复制一份数据目录到本地。

pg_basebackup -Fp -Pv -R -c fast -U replication -h localhost -D /var/lib/pgsql/slave

这里的关键是通过-R 选项，在备份的制作过程中自动将主机的连接信息填入recovery.conf，这样使用pg_ctl 启动时，数据库会意识到自己是备机，并从主机自动拉取WAL追赶进度。

启动从库

pg_ctl -D /var/lib/pgsql/slave -o "-p 5433" start

从库与主库的唯一区别在于，数据目录中多了一个recovery.conf文件。这个文件不仅仅可以用于标识从库的身份，而且在故障恢复时也需要用到。对于pg_basebackup构造的从库，它默认包含两个参数：

standby_mode = 'on'
primary_conninfo = 'user=replication passfile=''/Users/vonng/.pgpass'' host=localhost port=5432 sslmode=prefer sslcompression=1 krbsrvname=postgres target_session_attrs=any'

standby_mode指明是否将PostgreSQL作为从库启动。

在备份时，standby_mode默认关闭，这样当所有的WAL拉取完毕后，就完成恢复，进入正常工作模式。

如果打开，那么数据库会意识到自己是备机，那么即使到达WAL末尾也不会停止，它会持续拉取主库的WAL，追赶主库的进度。

拉取WAL有两种办法，通过primary_conninfo流式复制拉取（9.0后的新特性，推荐，默认），或者通过restore_command来手工指明WAL的获取方式（老办法，恢复时使用）。

查看状态

主库的所有从库可以通过系统视图pg_stat_replication查阅：

$ psql postgres -tzxc 'SELECT * FROM pg_stat_replication;'
pid              | 1947
usesysid         | 16384
usename          | replication
application_name | walreceiver
client_addr      | ::1
client_hostname  |
client_port      | 54124
backend_start    | 2018-01-25 13:24:57.029203+08
backend_xmin     |
state            | streaming
sent_lsn         | 0/5017F88
write_lsn        | 0/5017F88
flush_lsn        | 0/5017F88
replay_lsn       | 0/5017F88
write_lag        |
flush_lag        |
replay_lag       |
sync_priority    | 0
sync_state       | async

检查主库和备库的状态可以使用函数pg_is_in_recovery，备库会处于恢复状态：

$ psql postgres -Atzc 'SELECT pg_is_in_recovery()' && \
psql postgres -p 5433 -Atzc 'SELECT pg_is_in_recovery()'
f
t

在主库中建表，从库也能看到。

psql postgres -c 'CREATE TABLE foobar(i INTEGER);' && psql postgres -p 5433 -c '\d'

在主库中插入数据，从库也能看到

psql postgres -c 'INSERT INTO foobar VALUES (1);' && \
psql postgres -p 5433 -c 'SELECT * FROM foobar;'

现在主备已经配置就绪

PgBackRest2中文文档

PgBackRest是用perl写的一组PostgreSQL备份工具

著： 冯若航（@Vonng） | 2018-02-07

pgBackRest主页：http://pgbackrest.org

pgBackRest Github主页：https://github.com/pgbackrest/pgbackrest

前言

pgBackRest旨在提供一个简单可靠，容易纵向扩展的PostgreSQL备份恢复系统。

pgBackRest并不依赖像tar和rsync这样的传统备份工具，而在内部实现所有备份功能，并使用自定义协议来与远程系统进行通信。消除对tar和rsync的依赖可以更好地解决特定于数据库的备份问题。自定义远程协议提供了更多的灵活性，并限制执行备份所需的连接类型，从而提高安全性。

pgBackRest v2.01是目前的稳定版本。发行说明位在发行页面上。

pgBackRest旨在成为一个简单，可靠的备份和恢复系统，可以无缝扩展到最大的数据库和工作负载。

pgBackRest不依赖像tar和rsync这样的传统备份工具，而是在内部实现所有备份功能，并使用自定义协议与远程系统进行通信。消除对tar和rsync的依赖可以更好地解决针对数据库的备份挑战。自定义远程协议允许更大的灵活性，并限制执行备份所需的连接类型，从而提高安全性。

pgBackRest v2.01是当前的稳定版本。发行说明位于发行版页面上。

只有在EOL之前，pgBackRest v1才会收到修复错误。v1的文档可以在这里找到。

0. 特性

并行备份和恢复

压缩通常是备份操作的瓶颈，但即使是现在已经很普及的多核服务器，大多数数据库备份解决方案仍然是单进程的。 pgBackRest通过并行处理解决了压缩瓶颈问题。利用多个核心进行压缩，即使在1Gb/s的链路上，也可以实现1TB /小时的原生吞吐量。更多的核心和更大的带宽将带来更高的吞吐量。
本地或远程操作

自定义协议允许pgBackRest以最少的配置通过SSH进行本地或远程备份，恢复和归档。通过协议层也提供了查询PostgreSQL的接口，从而不需要对PostgreSQL进行远程访问，从而增强了安全性。
全量备份与增量备份

支持全量备份，增量备份，以及差异备份。 pgBackRest不会受到rsync的时间分辨问题的影响，使得差异备份和增量备份完全安全。
备份轮换和归档过期

可以为全量备份和增量备份设置保留策略，以创建覆盖任何时间范围的备份。 WAL归档可以设置为为所有的备份或仅最近的备份保留。在后一种情况下，在归档过程中会自动保证更老备份的一致性。
备份完整性

每个文件在备份时都会计算校验和，并在还原过程中重新检查。完成文件复制后，备份会等待所有必须的WAL段进入存储库。存储库中的备份以与标准PostgreSQL集群（包括表空间）相同的格式存储。如果禁用压缩并启用硬链接，则可以在存储库中快照备份，并直接在快照上创建PostgreSQL集群。这对于以传统方式恢复很耗时的TB级数据库是有利的。所有操作都使用文件和目录级别fsync来确保持久性。
页面校验和

PostgreSQL从9.3开始支持页面级校验和。如果启用页面校验和，pgBackRest将验证在备份过程中复制的每个文件的校验和。所有页面校验和在完整备份过程中均得到验证，在差异备份和增量备份过程中验证了已更改文件中的校验和。验证失败不会停止备份过程，但会向控制台和文件日志输出具体的哪些页面验证失败的详细警告。

此功能允许在包含有效数据副本的备份已过期之前及早检测到页级损坏。
备份恢复

中止的备份可以从停止点恢复。已经复制的文件将与清单中的校验和进行比较，以确保完整性。由于此操作可以完全在备份服务器上进行，因此减少了数据库服务器上的负载，并节省了时间，因为校验和计算比压缩和重新传输数据要快。
流压缩和校验和

无论存储库位于本地还是远程，压缩和校验和计算均在流中执行，而文件正在复制到存储库。如果存储库位于备份服务器上，则在数据库服务器上执行压缩，并以压缩格式传输文件，并将其存储在备份服务器上。当禁用压缩时，利用较低级别的压缩来有效使用可用带宽，同时将CPU成本降至最低。
增量恢复

清单包含备份中每个文件的校验和，以便在还原过程中可以使用这些校验和来加快处理速度。在增量恢复时，备份中不存在的任何文件将首先被删除，然后对其余文件执行校验和。与备份相匹配的文件将保留在原位，其余文件将照常恢复。并行处理可能会导致恢复时间大幅减少。
并行WAL归档

包括专用的命令将WAL推送到归档并从归档中检索WAL。push命令会自动检测多次推送的WAL段，并在段相同时自动解除重复，否则会引发错误。 push和get命令都通过比较PostgreSQL版本和系统标识符来确保数据库和存储库匹配。这排除了错误配置WAL归档位置的可能性。异步归档允许将传输转移到另一个并行压缩WAL段的进程，以实现最大的吞吐量。对于写入量非常高的数据库来说，这可能是一个关键功能。
表空间和链接支持

完全支持表空间，并且还原表空间可以重映射到任何位置。也可以使用一个对开发恢复有用的命令将所有的表空间重新映射到一个位置。
Amazon S3支持

pgBackRest存储库可以存储在Amazon S3上，以实现几乎无限的容量和保留。
加密

pgBackRest可以对存储库进行加密，以保护无论存储在何处的备份。
与PostgreSQL兼容> = 8.3

pgBackRest包含了对8.3以下版本的支持，因为旧版本的PostgreSQL仍然是经常使用的。

1. 简介

本用户指南旨在从头到尾按顺序进行，每一节依赖上一节。例如“备份”部分依赖“快速入门”部分中执行的设置。

尽管这些例子是针对Debian / Ubuntu和PostgreSQL 9.4的，但是将这个指南应用到任何Unix发行版和PostgreSQL版本上应该相当容易。请注意，由于Perl代码中的64位操作，目前只支持64位发行版。唯一的特定于操作系统的命令是创建，启动，停止和删除PostgreSQL集群的命令。尽管安装Perl库和可执行文件的位置可能有所不同，但任何Unix系统上的pgBackRest命令都是相同的。

PostgreSQL的配置信息和文档可以在PostgreSQL手册中找到。

本用户指南采用了一些新颖的方法来记录。从XML源生成文档时，每个命令都在虚拟机上运行。这意味着您可以高度自信地确保命令按照所呈现的顺序正确工作。捕获输出并在适当的时候显示在命令之下。如果输出不包括，那是因为它被认为是不相关的或者被认为是从叙述中分心的。

所有的命令都是作为非特权用户运行的，它对root用户和postgres用户都具有sudo权限。也可以直接以各自的用户身份运行这些命令而不用修改，在这种情况下，sudo命令可以被剥离。

2. 概念

2.1 备份

备份是数据库集群的一致副本，可以从硬件故障中恢复，执行时间点恢复或启动新的备用数据库。

全量备份（Full Backup）

pgBackRest将数据库集簇的全部文件复制到备份服务器。数据库集簇的第一个备份总是全量备份。

pgBackRest总能从全量备份直接恢复。全量备份的一致性不依赖任何外部文件。
差异备份（Differential Backup）

pgBackRest仅复制自上次全量备份以来，内容发生变更的数据库群集文件。恢复时，pgBackRest拷贝差异备份中的所有文件，以及之前一次全量备份中所有未发生变更的文件。差异备份的优点是它比全量备份需要更少的硬盘空间，缺点是差异备份的恢复依赖上一次全量备份的有效性。
增量备份（Incremental Backup）

pgBackRest仅复制自上次备份（可能是另一个增量备份，差异备份或完全备份）以来发生更改的数据库群集文件。由于增量备份只包含自上次备份以来更改的那些文件，因此它们通常远远小于完全备份或差异备份。与差异备份一样，增量备份依赖于其他备份才能有效恢复增量备份。由于增量备份只包含自上次备份以来的文件，所有之前的增量备份都恢复到以前的差异，先前的差异备份和先前的完整备份必须全部有效才能执行增量备份的恢复。如果不存在差异备份，则以前的所有增量备份将恢复到之前的完整备份（必须存在），而完全备份本身必须有效才能恢复增量备份。

2.2 还原

还原是将备份复制到将作为实时数据库集群启动的系统的行为。还原需要备份文件和一个或多个WAL段才能正常工作。

2.3 WAL

WAL是PostgreSQL用来确保没有提交的更改丢失的机制。将事务顺序写入WAL，并且在将这些写入刷新到磁盘时认为事务被提交。之后，后台进程将更改写入主数据库集群文件（也称为堆）。在发生崩溃的情况下，重播WAL以使数据库保持一致。

WAL在概念上是无限的，但在实践中被分解成单独的16MB文件称为段。 WAL段按照命名约定0000000100000A1E000000FE，其中前8个十六进制数字表示时间线，接下来的16个数字是逻辑序列号（LSN）。

2.4 加密

加密是将数据转换为无法识别的格式的过程，除非提供了适当的密码（也称为密码短语）。

pgBackRest将根据用户提供的密码加密存储库，从而防止未经授权访问存储库中的数据。

3. 安装

short version

# cent-os
sudo yum install -y pgbackrest

# ubuntu
sudo apt-get install libdbd-pg-perl libio-socket-ssl-perl libxml-libxml-perl

verbose version

创建一个名为db-primary的新主机来包含演示群集并运行pgBackRest示例。如果已经安装了pgBackRest，最好确保没有安装先前的副本。取决于pgBackRest的版本可能已经安装在几个不同的位置。以下命令将删除所有先前版本的pgBackRest。

db-primary⇒删除以前的pgBackRest安装

sudo rm -f /usr/bin/pgbackrest
sudo rm -f /usr/bin/pg_backrest
sudo rm -rf /usr/lib/perl5/BackRest
sudo rm -rf /usr/share/perl5/BackRest
sudo rm -rf /usr/lib/perl5/pgBackRest
sudo rm -rf /usr/share/perl5/pgBackRest

pgBackRest是用Perl编写的，默认包含在Debian/Ubuntu中。一些额外的模块也必须安装，但是它们可以作为标准包使用。

db-primary⇒安装必需的Perl软件包

# cent-os
sudo yum install -y pgbackrest

# ubuntu
sudo apt-get install libdbd-pg-perl libio-socket-ssl-perl libxml-libxml-perl

适用于pgBackRest的Debian / Ubuntu软件包位于apt.postgresql.org。如果没有为您的发行版/版本提供，则可以轻松下载源代码并手动安装。

db-primary⇒下载pgBackRest的2.01版本

sudo wget -q -O- \
       https://github.com/pgbackrest/pgbackrest/archive/release/2.01.tar.gz | \
       sudo tar zx -C /root
       
# or without sudo
wget -q -O - https://github.com/pgbackrest/pgbackrest/archive/release/2.01.tar.gz | tar zx -C /tmp

db-primary⇒安装pgBackRest

sudo cp -r /root/pgbackrest-release-2.01/lib/pgBackRest \
       /usr/share/perl5
sudo find /usr/share/perl5/pgBackRest -type f -exec chmod 644 {} +
sudo find /usr/share/perl5/pgBackRest -type d -exec chmod 755 {} +
sudo mkdir -m 770 /var/log/pgbackrest
sudo chown postgres:postgres /var/log/pgbackrest
sudo touch /etc/pgbackrest.conf
sudo chmod 640 /etc/pgbackrest.conf
sudo chown postgres:postgres /etc/pgbackrest.conf



sudo cp -r /root/pgbackrest-release-1.27/lib/pgBackRest \
       /usr/share/perl5
sudo find /usr/share/perl5/pgBackRest -type f -exec chmod 644 {} +
sudo find /usr/share/perl5/pgBackRest -type d -exec chmod 755 {} +

sudo cp /root/pgbackrest-release-1.27/bin/pgbackrest /usr/bin/pgbackrest
sudo chmod 755 /usr/bin/pgbackrest
sudo mkdir -m 770 /var/log/pgbackrest
sudo chown postgres:postgres /var/log/pgbackrest
sudo touch /etc/pgbackrest.conf
sudo chmod 640 /etc/pgbackrest.conf
sudo chown postgres:postgres /etc/pgbackrest.conf

pgBackRest包含一个可选的伴随C库，可以增强性能并启用checksum-page选项和加密。预构建的软件包通常比手动构建C库更好，但为了完整性，下面给出了所需的步骤。根据分布情况，可能需要一些软件包，这里不一一列举。

db-primary⇒构建并安装C库

sudo sh -c 'cd /root/pgbackrest-release-2.01/libc && \
       perl Makefile.PL INSTALLMAN1DIR=none INSTALLMAN3DIR=none'
sudo make -C /root/pgbackrest-release-2.01/libc test
sudo make -C /root/pgbackrest-release-2.01/libc install

现在pgBackRest应该正确安装了，但最好检查一下。如果任何依赖关系被遗漏，那么当你从命令行运行pgBackRest的时候你会得到一个错误。

db-primary⇒确保安装正常

sudo -u postgres pgbackrest
pgBackRest 1.27 - General help

Usage:
    pgbackrest [options] [command]

Commands:
    archive-get     Get a WAL segment from the archive.
    archive-push    Push a WAL segment to the archive.
    backup          Backup a database cluster.
    check           Check the configuration.
    expire          Expire backups that exceed retention.
    help            Get help.
    info            Retrieve information about backups.
    restore         Restore a database cluster.
    stanza-create   Create the required stanza data.
    stanza-upgrade  Upgrade a stanza.
    start           Allow pgBackRest processes to run.
    stop            Stop pgBackRest processes from running.
    version         Get version.

Use 'pgbackrest help [command]' for more information.

mac version

在MacOS上安装可以按照之前的手动安装教程，参考文章：https://hunleyd.github.io/posts/pgBackRest-2.07-and-macOS-Mojave/

# 注意如果需要从终端访问代理，可以使用以下命令：
alias proxy='export all_proxy=socks5://127.0.0.1:1080'
alias unproxy='unset all_proxy'

# 安装 homebrew & wget
/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
brew install wget

# install perl DB driver: Pg
perl -MCPAN -e 'install Bundle::DBI'
perl -MCPAN -e 'install Bundle::DBD::Pg'
perl -MCPAN -e 'install IO::Socket::SSL'
perl -MCPAN -e 'install XML::LibXML'

# Download and unzip
wget https://github.com/pgbackrest/pgbackrest/archive/release/2.07.tar.gz

# Copy to Perls lib
sudo cp -r  ~/Downloads/pgbackrest-release-1.27/lib/pgBackRest /Library/Perl/5.18
sudo find /Library/Perl/5.18/pgBackRest -type f -exec chmod 644 {} +
sudo find /Library/Perl/5.18/pgBackRest -type d -exec chmod 755 {} +

# Copy binary to your path
sudo cp ~/Downloads/pgbackrest-release-1.27/bin/pgbackrest /usr/local/bin/
sudo chmod 755 /usr/local/bin/pgbackrest

# Make log dir & conf file. maybe you will change vonng to postgres
sudo mkdir -m 770 /var/log/pgbackrest && sudo touch /etc/pgbackrest.conf
sudo chmod 640 /etc/pgbackrest.conf
sudo chown vonng /etc/pgbackrest.conf /var/log/pgbackrest

# Uninstall
# sudo rm -rf /usr/local/bin/pgbackrest /Library/Perl/5.18/pgBackRest /var/log/pgbackrest /etc/pgbackrest.conf

4. 快速入门

4.1 搭建测试数据库集群

创建示例群集是可选的，但强烈建议试一遍，尤其对于新用户，因为用户指南中的示例命令引用了示例群集。示例假定演示群集正在默认端口（即5432）上运行。直到后面的部分才会启动群集，因为还有一些配置要做。

db-primary⇒创建演示群集

# create database cluster
pg_ctl init -D /var/lib/pgsql/data

# change listen address to *
sed -ie "s/^#listen_addresses = 'localhost'/listen_addresses = '*'/g" /var/lib/pgsql/data/postgresql.conf

# change log prefix 
sed -ie "s/^#log_line_prefix = '%m [%p] '/log_line_prefix = ''/g" /var/lib/pgsql/data/postgresql.conf

默认情况下PostgreSQL只接受本地连接。本示例需要来自其他服务器的连接，将listen_addresses配置为在所有端口上侦听。如果有安全性要求，这样做可能是不合适的。

出于演示目的，log_line_prefix设置将被最低限度地配置。这使日志输出尽可能简短，以更好地说明重要的信息。

4.2 配置集群的备份单元（Stanza）

一个备份单元是指一组关于PostgreSQL数据库集簇的配置，它定义了数据库的位置，如何备份，归档选项等。大多数数据库服务器只有一个Postgres数据库集簇，因此只有一个备份单元，而备份服务器则对每一个需要备份的数据库集簇都有一个备份单元。

在主群集之后命名该节是诱人的，但是更好的名称描述群集中包含的数据库。由于节名称将用于主节点名称和所有副本，因此选择描述群集实际功能（例如app或dw）的名称（而不是本地群集名称（如main或prod））会更合适。

“Demo”这个名字可以准确地描述这个数据库集簇的目的，所以这里就这么用了。

pgBackRest需要知道PostgreSQL集簇的数据目录所在的位置。备份的时候PostgreSQL可以使用该目录，但恢复的时候PostgreSQL必须停机。备份期，提供给pgBackRest的值将与PostgreSQL运行的路径比较，如果它们不相等则备份将报错。确保db-path与postgresql.conf中的data_directory完全相同。

默认情况下，Debian / Ubuntu在/ var / lib / postgresql / [版本] / [集群]中存储集群，因此很容易确定数据目录的正确路径。

在创建/etc/pgbackrest.conf文件时，数据库所有者（通常是postgres）必须被授予读取权限。

db-primary：/etc/pgbackrest.conf⇒配置PostgreSQL集群数据目录

[demo]
db-path=/var/lib/pgsql/data

pgBackRest配置文件遵循Windows INI约定。部分用括号中的文字表示，每个部分包含键/值对。以#开始的行被忽略，可以用作注释。

4.3 创建存储库

存储库是pgBackRest存储备份和归档WAL段的地方。

新备份很难提前估计需要多少空间。最好的办法是做一些备份，然后记录不同类型备份的大小（full / incr / diff），并测量每天产生的WAL数量。这将给你一个大致需要多少空间的概念。当然随着数据库的发展，需求可能会随着时间而变化。

对于这个演示，存储库将被存储在与PostgreSQL服务器相同的主机上。这是最简单的配置，在使用传统备份软件备份数据库主机的情况下非常有用。

db-primary⇒创建pgBackRest存储库

sudo mkdir /var/lib/pgbackrest
sudo chmod 750 /var/lib/pgbackrest
sudo chown postgres:postgres /var/lib/pgbackrest

存储库路径必须配置，以便pgBackRest知道在哪里找到它。

db-primary：/etc/pgbackrest.conf ⇒配置pgBackRest存储库路径

[demo]
db-path=/var/lib/postgresql/9.4/demo

[global]
repo-path=/var/lib/pgbackrest

4.4 配置归档

备份正在运行的PostgreSQL集群需要启用WAL归档。请注意，即使没有对群集进行明确写入，在备份过程中也会创建至少一个WAL段。

db-primary：/var/lib/pgsql/data/postgresql.conf⇒ 配置存档设置

archive_command = 'pgbackrest --stanza=demo archive-push %p'
archive_mode = on
listen_addresses = '*'
log_line_prefix = ''
max_wal_senders = 3
wal_level = hot_standby

wal_level设置必须至少设置为archive，但hot_standby和logical也适用于备份。在PostgreSQL 10中，相应的wal_level是replica。将wal_level设置为hot_standy并增加max_wal_senders是一个好主意，即使您当前没有运行热备用数据库也是一个好主意，因为这样可以在不重新启动主群集的情况下添加它们。在进行这些更改之后和执行备份之前，必须重新启动PostgreSQL群集。

4.5 保留配置（retention）

pgBackRest会根据保留配置对备份进行过期处理。

db-primary: /etc/pgbackrest.conf ⇒ 配置为保留两个全量备份

[demo]
db-path=/var/lib/postgresql/9.4/demo

[global]
repo-path=/var/lib/pgbackrest

retention-full=2

更多关于保留的信息可以在Retention一节找到。

4.6 配置存储库加密

该节创建命令必须在仓库位于初始化节的主机上运行。建议的检查命令后运行节创建，确保归档和备份的配置是否正确。

db-primary: /etc/pgbackrest.conf ⇒ 配置pgBackRest存储库加密

[demo]
db-path=/var/lib/postgresql/9.4/demo

[global]
repo-cipher-pass=zWaf6XtpjIVZC5444yXB+cgFDFl7MxGlgkZSaoPvTGirhPygu4jOKOXf9LO4vjfO
repo-cipher-type=aes-256-cbc
repo-path=/var/lib/pgbackrest
retention-full=2

一旦存储库（repository）配置完成且备份单元创建并检查完毕，存储库加密设置便不能更改。

4.7 创建存储单元

stanza-create命令必须在仓库位于初始化节的主机上运行。建议在stanza-create命令之后运行check命令，确保归档和备份的配置是否正确。

db-primary ⇒ 创建存储单元并检查配置

postgres$ pgbackrest --stanza=demo --log-level-console=info stanza-create

P00   INFO: stanza-create command begin 1.27: --db1-path=/var/lib/postgresql/9.4/demo --log-level-console=info --no-log-timestamp --repo-cipher-pass= --repo-cipher-type=aes-256-cbc --repo-path=/var/lib/pgbackrest --stanza=demo

P00   INFO: stanza-create command end: completed successfully

1. Install

  $ sudo yum install -y pgbackrest


2. configuration

  1) pgbackrest.conf

    $ sudo vim /etc/pgbackrest.conf
      [global]
      repo-cipher-pass=O8lotSfiXYSYomc9BQ0UzgM9PgXoyNo1t3c0UmiM7M26rOETVNawbsW7BYn+I9es
      repo-cipher-type=aes-256-cbc
      repo-path=/var/backups
      retention-full=2
      retention-diff=2
      retention-archive=2
      start-fast=y
      stop-auto=y
      archive-copy=y
      
      [global:archive-push]
      archive-async=y
      process-max=4
      
      [test]
      db-path=/var/lib/pgsql/9.5/data
      process-max=10

  2) postgresql.conf

    $ sudo vim /var/lib/pgsql/9.5/data/postgresql.conf
      archive_command = '/usr/bin/pgbackrest --stanza=test archive-push %p'

3. Initial

  $ sudo chown -R postgres:postgres /var/backups/
  $ sudo -u postgres pgbackrest --stanza=test --log-level-console=info stanza-create
    2018-01-04 11:38:21.082 P00   INFO: stanza-create command begin 1.27: --db1-path=/var/lib/pgsql/9.5/data --log-level-console=info --repo-cipher-pass=<redacted> --repo-cipher-type=aes-256-cbc --repo-path=/var/backups --stanza=test
    2018-01-04 11:38:21.533 P00   INFO: stanza-create command end: completed successfully
  $ sudo service postgresql-9.5 reload

  $ sudo -u postgres pgbackrest --stanza=test --log-level-console=info info
  stanza: test
      status: error (no valid backups)
  
      db (current)
          wal archive min/max (9.5-1): 0000000500041CFD000000BE / 0000000500041CFD000000BE

4. Backup

  $ sudo -u postgres pgbackrest --stanza=test --log-level-console=info --type=full backup
  2018-01-04 16:24:57.329 P00   INFO: backup command begin 1.27: --archive-copy --db1-path=/var/lib/pgsql/9.5/data --log-level-console=info --process-max=40 --repo-cipher-pass=<redacted> --repo-cipher-type=aes-
  256-cbc --repo-path=/var/backups --retention-archive=2 --retention-diff=2 --retention-full=2 --stanza=test --start-fast --stop-auto --type=full
  2018-01-04 16:24:58.192 P00   INFO: execute exclusive pg_start_backup() with label "pgBackRest backup started at 2018-01-04 16:24:57": backup begins after the requested immediate checkpoint completes
  2018-01-04 16:24:58.495 P00   INFO: backup start archive = 0000000500041CFD000000C0, lsn = 41CFD/C0000060
  2018-01-04 16:26:04.863 P34   INFO: backup file /var/lib/pgsql/9.5/data/base/16384/3072016471.83 (1GB, 0%) checksum ab17fdd9f70652a0de55fd0da5d2b6b1f48de490
  2018-01-04 16:26:04.923 P35   INFO: backup file /var/lib/pgsql/9.5/data/base/16384/3072016471.82 (1GB, 0%) checksum 5acba8d0eb70dcdc64199201ee3999743e747699
  2018-01-04 16:26:05.208 P37   INFO: backup file /var/lib/pgsql/9.5/data/base/16384/3072016471.80 (1GB, 0%) checksum 74e2f876d8e7d68ab29624d53d33b0c6cb078382
  2018-01-04 16:26:06.973 P30   INFO: backup file /var/lib/pgsql/9.5/data/base/16384/3072016471.87 (1GB, 1%) checksum b6d6884724178476ee24a9a1a812e8941d4da396
  2018-01-04 16:26:09.434 P24   INFO: backup file /var/lib/pgsql/9.5/data/base/16384/3072016471.92 (1GB, 1%) checksum c5e6232171e0a7cadc7fc57f459a7bc75c2955d8
  2018-01-04 16:26:09.860 P40   INFO: backup file /var/lib/pgsql/9.5/data/base/16384/3072016471.78 (1GB, 1%) checksum 95d94b1bac488592677f7942b85ab5cc2a39bf62
  2018-01-04 16:26:10.708 P33   INFO: backup file /var/lib/pgsql/9.5/data/base/16384/3072016471.84 (1GB, 2%) checksum 32e8c83f9bdc5934552f54ee59841f1877b04f69
  2018-01-04 16:26:11.035 P28   INFO: backup file /var/lib/pgsql/9.5/data/base/16384/3072016471.89 (1GB, 2%) checksum aa7bee244d2d2c49b56bc9b2e0b9bf36f2bcc227
  2018-01-04 16:26:11.239 P17   INFO: backup file /var/lib/pgsql/9.5/data/base/16384/3072016471.99 (1GB, 2%) checksum 218bcecf7da2230363926ca00d719011a6c27467
  2018-01-04 16:26:11.383 P18   INFO: backup file /var/lib/pgsql/9.5/data/base/16384/3072016471.98 (1GB, 2%) checksum 38744d27867017dfadb6b520b6c0034daca67481
  ...
  2018-01-04 16:34:07.782 P32   INFO: backup file /var/lib/pgsql/9.5/data/base/16384/3072016471.184 (852.7MB, 98%) checksum 92990e159b0436d5a6843d21b2d888b636e246cf
  2018-01-04 16:34:07.935 P10   INFO: backup file /var/lib/pgsql/9.5/data/base/16384/3072016468.100 (1GB, 98%) checksum d9e0009447a5ef068ce214239f1c999cc5251462
  2018-01-04 16:34:10.212 P35   INFO: backup file /var/lib/pgsql/9.5/data/base/16384/3072016476.3 (569.6MB, 98%) checksum d02e6efed6cea3005e1342d9d6a8e27afa5239d7
  2018-01-04 16:34:12.289 P20   INFO: backup file /var/lib/pgsql/9.5/data/base/16384/3072016468.10 (1GB, 98%) checksum 1a99468cd18e9399ade9ddc446eb21f1c4a1f137
  2018-01-04 16:34:13.270 P03   INFO: backup file /var/lib/pgsql/9.5/data/base/16384/3072016468.1 (1GB, 99%) checksum c0ddb80d5f1be83aa4557777ad05adb7cbc47e72
  2018-01-04 16:34:13.792 P38   INFO: backup file /var/lib/pgsql/9.5/data/base/16384/3072016468 (1GB, 99%) checksum 767a2e0d21063b92b9cebc735fbb0e3c7332218d
  2018-01-04 16:34:18.446 P26   INFO: backup file /var/lib/pgsql/9.5/data/base/16384/3072016473.3 (863.9MB, 99%) checksum 87ba54690ea418c2ddd1d488c56fa164ebda5042
  2018-01-04 16:34:23.551 P13   INFO: backup file /var/lib/pgsql/9.5/data/base/16384/3072016475.7 (895.4MB, 100%) checksum a2693bfdc84940c82b7d77a13b752e33448bb008
  2018-01-04 16:34:23.648 P00   INFO: full backup size = 341.5GB
  2018-01-04 16:34:23.649 P00   INFO: execute exclusive pg_stop_backup() and wait for all WAL segments to archive
  2018-01-04 16:34:37.774 P00   INFO: backup stop archive = 0000000500041CFD000000C0, lsn = 41CFD/C0000168
  2018-01-04 16:34:39.648 P00   INFO: new backup label = 20180104-162457F
  2018-01-04 16:34:41.004 P00   INFO: backup command end: completed successfully
  2018-01-04 16:34:41.005 P00   INFO: expire command begin 1.27: --log-level-console=info --repo-cipher-pass=<redacted> --repo-cipher-type=aes-256-cbc --repo-path=/var/backups --retention-archive=2 --retention-diff=2 --retention-full=2 --stanza=test
  2018-01-04 16:34:41.028 P00   INFO: full backup total < 2 - using oldest full backup for 9.5-1 archive retention
  2018-01-04 16:34:41.034 P00   INFO: expire command end: completed successfully 

  $ sudo -u postgres pgbackrest --stanza=test --log-level-console=info info
  stanza: test
      status: ok
  
      db (current)
          wal archive min/max (9.5-1): 0000000500041CFD000000C0 / 0000000500041CFD000000C0
  
          full backup: 20180104-162457F
              timestamp start/stop: 2018-01-04 16:24:57 / 2018-01-04 16:34:38
              wal start/stop: 0000000500041CFD000000C0 / 0000000500041CFD000000C0
              database size: 341.5GB, backup size: 341.5GB
              repository size: 153.6GB, repository backup size: 153.6GB


5. restore

  $ sudo vim /etc/pgbackrest.conf
    db-path=/export/pgdata
  $ sudo mkdir /export/pgdata
  $ sudo chown -R postgres:postgres /export/pgdata/
  $ sudo chmod 0700 /export/pgdata/
  $ sudo -u postgres pgbackrest --stanza=test --log-level-console=info --delta --set=20180104-162457F --type=time "--target=2018-01-04 16:34:38" restore
  2018-01-04 17:04:23.170 P00   INFO: restore command begin 1.27: --db1-path=/export/pgdata --delta --log-level-console=info --process-max=40 --repo-cipher-pass=<redacted> --repo-cipher-type=aes-256-cbc --repo-
  path=/var/backups --set=20180104-162457F --stanza=test "--target=2018-01-04 16:34:38" --type=time
  WARN: --delta or --force specified but unable to find 'PG_VERSION' or 'backup.manifest' in '/export/pgdata' to confirm that this is a valid $PGDATA directory.  --delta and --force have been disabled and if an
  y files exist in the destination directories the restore will be aborted.
  2018-01-04 17:04:23.313 P00   INFO: restore backup set 20180104-162457F
  2018-01-04 17:04:23.935 P00   INFO: remap $PGDATA directory to /export/pgdata
  2018-01-04 17:05:09.626 P01   INFO: restore file /export/pgdata/base/16384/3072016476.2 (1GB, 0%) checksum be1145405b8bcfa57c3f1fd8d0a78eee3ed2df21
  2018-01-04 17:05:09.627 P04   INFO: restore file /export/pgdata/base/16384/3072016475.6 (1GB, 0%) checksum d2bc51d5b58dea3d14869244cd5a23345dbc4ffb
  2018-01-04 17:05:09.627 P27   INFO: restore file /export/pgdata/base/16384/3072016471.9 (1GB, 0%) checksum 94cbf743143baffac0b1baf41e60d4ed99ab910f
  2018-01-04 17:05:09.627 P37   INFO: restore file /export/pgdata/base/16384/3072016471.80 (1GB, 1%) checksum 74e2f876d8e7d68ab29624d53d33b0c6cb078382
  2018-01-04 17:05:09.627 P38   INFO: restore file /export/pgdata/base/16384/3072016471.8 (1GB, 1%) checksum 5f0edd85543c9640d2c6cf73257165e621a6b295
  2018-01-04 17:05:09.652 P02   INFO: restore file /export/pgdata/base/16384/3072016476.1 (1GB, 1%) checksum 3e262262b106bdc42c9fe17ebdf62bc4ab2e8166
  ...
  2018-01-04 17:09:15.415 P34   INFO: restore file /export/pgdata/base/1/13142 (0B, 100%)
  2018-01-04 17:09:15.415 P35   INFO: restore file /export/pgdata/base/1/13137 (0B, 100%)
  2018-01-04 17:09:15.415 P36   INFO: restore file /export/pgdata/base/1/13132 (0B, 100%)
  2018-01-04 17:09:15.415 P37   INFO: restore file /export/pgdata/base/1/13127 (0B, 100%)
  2018-01-04 17:09:15.418 P00   INFO: write /export/pgdata/recovery.conf
  2018-01-04 17:09:15.950 P00   INFO: restore global/pg_control (performed last to ensure aborted restores cannot be started)
  2018-01-04 17:09:16.588 P00   INFO: restore command end: completed successfully

  $ sudo vim /export/pgdata/postgresql.conf
    port = 5433
  $ sudo -u postgres /usr/pgsql-9.5/bin/pg_ctl -D /export/pgdata/ start
  server starting
  < 2018-01-04 17:13:47.361 CST >LOG:  redirecting log output to logging collector process
  < 2018-01-04 17:13:47.361 CST >HINT:  Future log output will appear in directory "pg_log".

  $ sudo -u postgres psql -p5433
  psql (9.5.10)
  Type "help" for help.
  
  postgres=# \q

6. archive_command and restore_command
  1) on master
    $ sudo vim /var/lib/pgsql/9.5/data/postgresql.conf
      archive_command = '/usr/bin/pgbackrest --stanza=test archive-push %p'
    $ sudo service postgresql-9.5 reload
    $ sudo yum install -y -q nfs-utils
    $ sudo echo "/var/backups 10.191.0.0/16(rw)" > /etc/exports
    $ sudo service nfs start

  2) on slave
    $ sudo mount -o v3 master_ip:/var/backups /var/backups
    $ sudo vim /etc/pgbackrest.conf
      [global]
      repo-cipher-pass=O8lotSfiXYSYomc9BQ0UzgM9PgXoyNo1t3c0UmiM7M26rOETVNawbsW7BYn+I9es
      repo-cipher-type=aes-256-cbc
      repo-path=/var/backups
      retention-full=2
      retention-diff=2
      retention-archive=2
      start-fast=y
      stop-auto=y
      archive-copy=y

      [global:archive-push]
      archive-async=y
      process-max=4

      [test]
      db-path=/var/lib/pgsql/9.5/data
      process-max=10

    $ sudo vim /var/lib/pgsql/9.5/data/recovery.conf
      restore_command = '/usr/bin/pgbackrest --stanza=test archive-get %f "%p"'

Pgbouncer快速上手

Pgbouncer是一个轻量级的数据库连接池，这里简单介绍Pgbouncer的配置、管理与使用。

著： 冯若航（@Vonng） | 2018-02-07

Pgbouncer是一个轻量级的数据库连接池。

概要

pgbouncer [-d][-R][-v][-u user] <pgbouncer.ini>
pgbouncer -V|-h

描述

pgbouncer 是一个PostgreSQL连接池。任何目标应用程序都可以连接到 pgbouncer，就像它是PostgreSQL服务器一样，pgbouncer 将创建到实际服务器的连接，或者它将重用其中一个现有的连接。

pgbouncer 的目的是为了降低打开PostgreSQL新连接时的性能影响。

为了不影响连接池的事务语义，pgbouncer 在切换连接时，支持多种类型的池化：

会话连接池（Session pooling）

最礼貌的方法。当客户端连接时，将在客户端保持连接的整个持续时间内分配一个服务器连接。当客户端断开连接时，服务器连接将放回到连接池中。这是默认的方法。
事务连接池（Transaction pooling）

服务器连接只有在一个事务的期间内才指派给客户端。当PgBouncer发觉事务结束的时候，服务器连接将会放回连接池中。
语句连接池（Statement pooling）

最激进的模式。在查询完成后，服务器连接将立即被放回连接池中。该模式中不允许多语句事务，因为它们会中断。

pgbouncer 的管理界面由连接到特殊’虚拟’数据库 pgbouncer 时可用的一些新的 SHOW 命令组成。

上手

基本设置和用法如下。

创建一个pgbouncer.ini文件。pgbouncer(5) 的详细信息。简单例子

[databases]
template1 = host=127.0.0.1 port=5432 dbname=template1

[pgbouncer]
listen_port = 6543
listen_addr = 127.0.0.1
auth_type = md5
auth_file = users.txt
logfile = pgbouncer.log
pidfile = pgbouncer.pid
admin_users = someuser

创建包含许可用户的 users.txt 文件

"someuser" "same_password_as_in_server"

加载 pgbouncer
```
$ pgbouncer -d pgbouncer.ini
```
你的应用程序（或 客户端psql）已经连接到 pgbouncer ，而不是直接连接到PostgreSQL服务器了吗：
```
 psql -p 6543 -U someuser template1
```

通过连接到特殊管理数据库 pgbouncer 来管理 pgbouncer，发出 show help; 开始

$ psql -p 6543 -U someuser pgbouncer
pgbouncer=# show help;
NOTICE:  Console usage
DETAIL:
  SHOW [HELP|CONFIG|DATABASES|FDS|POOLS|CLIENTS|SERVERS|SOCKETS|LISTS|VERSION]
  SET key = arg
  RELOAD
  PAUSE
  SUSPEND
  RESUME
  SHUTDOWN

如果你修改了pgbouncer.ini文件，可以用下列命令重新加载：
```
pgbouncer=# RELOAD;
```

命令行开关

-d	在后台运行。没有它，进程将在前台运行。注意：在Windows上不起作用，pgbouncer 需要作为服务运行。
-R	进行在线重启。这意味着连接到正在运行的进程，从中加载打开的套接字，然后使用它们。如果没有活动进程，请正常启动。注意：只有在操作系统支持Unix套接字且 `unix_socket_dir` 在配置中未被禁用时才可用。在Windows机器上不起作用。不使用TLS连接，它们被删除了。
-u user	启动时切换到给定的用户。
-v	增加详细度。可多次使用。
-q	安静 - 不要登出到stdout。请注意，这不影响日志详细程度，只有该stdout不被使用。用于init.d脚本。
-V	显示版本。
-h	显示简短的帮助。
–regservice	Win32：注册pgbouncer作为Windows服务运行。 service_name 配置参数值用作要注册的名称。
–unregservice	Win32: 注销Windows服务。

管理控制台

通过正常连接到数据库 pgbouncer 可以使用控制台

$ psql -p 6543 pgbouncer

只有在配置参数 admin_users 或 stats_users 中列出的用户才允许登录到控制台。（除了 auth_mode=any 时，任何用户都可以作为stats_user登录。）

另外，如果通过Unix套接字登录，并且客户端具有与运行进程相同的Unix用户uid，允许用户名 pgbouncer 不使用密码登录。

SHOW命令

`SHOW STATS;`

显示统计信息。

字段	说明
`database`	统计信息按数据库组织
`total_xact_count`	SQL事务总数
`total_query_count`	SQL查询总数
`total_received`	收到的网络流量(字节)
`total_sent`	发送的网络流量(字节)
`total_xact_time`	在事务中的总时长
`total_query_time`	在查询中的总时长
`total_wait_time`	在等待中的总时长
`avg_xact_count`	（当前）平均事务数
`avg_query_count`	（当前）平均查询数
`avg_recv`	（当前）平均每秒收到字节数
`avg_sent`	（当前）平均每秒发送字节数
`avg_xact_time`	平均事务时长（以毫秒计）
`avg_query_time`	平均查询时长（以毫秒计）
`avg_wait_time`	平均等待时长（以毫秒计）

两个变体：SHOW STATS_TOTALS与SHOW STATS_AVERAGES，分别显示整体与平均的统计。

TOTAL实际上是Counter，而AVG通常是Guage。监控时建议采集TOTAL，查看时建议查看AVG。

`SHOW SERVERS`

字段	说明
`type`	Server的类型固定为S
`user`	Pgbouncer用于连接数据库的用户名
`state`	pgbouncer服务器连接的状态，active、used 或 idle 之一。
`addr`	PostgreSQL server服务器的IP地址。
`port`	PostgreSQL服务器的端口。
`local_addr`	本机连接启动的地址。
`local_port`	本机上的连接启动端口。
`connect_time`	建立连接的时间。
`request_time`	最后一个请求发出的时间。
`ptr`	该连接内部对象的地址，用作唯一标识符
`link`	服务器配对的客户端连接地址。
`remote_pid`	后端服务器进程的pid。如果通过unix套接字进行连接，并且OS支持获取进程ID信息，则为OS pid。否则它将从服务器发送的取消数据包中提取出来，如果服务器是Postgres，则应该是PID，但是如果服务器是另一个PgBouncer，则它是一个随机数。

`SHOW CLIENTS`

字段	说明
`type`	Client的类型固定为C
`user`	客户端用于连接的用户
`state`	pgbouncer客户端连接的状态，active、used 、waiting或 idle 之一。
`addr`	客户端的IP地址。
`port`	客户端的端口
`local_addr`	本机地址
`local_port`	本机端口
`connect_time`	建立连接的时间。
`request_time`	最后一个请求发出的时间。
`ptr`	该连接内部对象的地址，用作唯一标识符
`link`	配对的服务器端连接地址。
`remote_pid`	如果通过unix套接字进行连接，并且OS支持获取进程ID信息，则为OS pid。

`SHOW CLIENTS`

字段	说明
`type`	Client的类型固定为C
`user`	客户端用于连接的用户
`state`	pgbouncer客户端连接的状态，active、used 、waiting或 idle 之一。
`addr`	客户端的IP地址。
`port`	客户端的端口
`local_addr`	本机地址
`local_port`	本机端口
`connect_time`	建立连接的时间。
`request_time`	最后一个请求发出的时间。
`ptr`	该连接内部对象的地址，用作唯一标识符
`link`	配对的服务器端连接地址。
`remote_pid`	如果通过unix套接字进行连接，并且OS支持获取进程ID信息，则为OS pid。

SHOW POOLS;

为每对(database, user)创建一个新的连接池选项。

database

数据库名称。
user

用户名。
cl_active

链接到服务器连接并可以处理查询的客户端连接。
cl_waiting

已发送查询但尚未获得服务器连接的客户端连接。
sv_active

链接到客户端的服务器连接。
sv_idle

未使用且可立即用于客户机查询的服务器连接。
sv_used

已经闲置超过 server_check_delay 时长的服务器连接，所以在它可以使用之前，需要运行 server_check_query。
sv_tested

当前正在运行 server_reset_query 或 server_check_query 的服务器连接。
sv_login

当前正在登录过程中的服务器连接。
maxwait

队列中第一个（最老的）客户端已经等待了多长时间，以秒计。如果它开始增加，那么服务器当前的连接池处理请求的速度不够快。原因可能是服务器负载过重或 pool_size 设置过小。
pool_mode

正在使用的连接池模式。

SHOW LISTS;

在列（不是行）中显示以下内部信息：

databases

数据库计数。
users

用户计数。
pools

连接池计数。
free_clients

空闲客户端计数。
used_clients

使用了的客户端计数。
login_clients

在 login 状态中的客户端计数。
free_servers

空闲服务器计数。
used_servers

使用了的服务器计数。

SHOW USERS;

name

用户名
pool_mode

用户重写的pool_mode，如果使用默认值，则返回NULL。

SHOW DATABASES;

name

配置的数据库项的名称。
host

pgbouncer连接到的主机。
port

pgbouncer连接到的端口。
database

pgbouncer连接到的实际数据库名称。
force_user

当用户是连接字符串的一部分时，pgbouncer和PostgreSQL 之间的连接被强制给给定的用户，不管客户端用户是谁。
pool_size

服务器连接的最大数量。
pool_mode

数据库的重写pool_mode，如果使用默认值则返回NULL。

SHOW FDS;

内部命令 - 显示与附带的内部状态一起使用的fds列表。

当连接的用户使用用户名"pgbouncer"时，通过Unix套接字连接并具有与运行过程相同的UID，实际的fds通过连接传递。该机制用于进行在线重启。注意：这不适用于Windows机器。

此命令还会阻止内部事件循环，因此在使用PgBouncer时不应该使用它。

fd

文件描述符数值。
task

pooler、client 或 server 之一。
user

使用该FD的连接的用户。
database

使用该FD的连接的数据库。
addr

使用FD的连接的IP地址，如果使用unix套接字则是 unix。
port

使用FD的连接的端口。
cancel

取消此连接的键。
link

对应服务器/客户端的fd。如果空闲则为NULL。

SHOW CONFIG;

显示当前的配置设置，一行一个，带有下列字段：

key

配置变量名
value

配置值
changeable

yes 或者 no，显示运行时变量是否可更改。如果是 no，则该变量只能在启动时改变。

SHOW DNS_HOSTS;

显示DNS缓存中的主机名。

hostname

主机名。
ttl

直到下一次查找经过了多少秒。
addrs

地址的逗号分隔的列表。

SHOW DNS_ZONES

显示缓存中的DNS区域。

zonename

区域名称。
serial

当前序列号。
count

属于此区域的主机名。

过程控制命令

`PAUSE [db];`

PgBouncer尝试断开所有服务器的连接，首先等待所有查询完成。所有查询完成之前，命令不会返回。在数据库重新启动时使用。如果提供了数据库名称，那么只有该数据库将被暂停。

`DISABLE db;`

拒绝给定数据库上的所有新客户端连接。

`ENABLE db;`

在上一个的 DISABLE 命令之后允许新的客户端连接。

`KILL db;`

立即删除给定数据库上的所有客户端和服务器连接。

`SUSPEND;`

所有套接字缓冲区被刷新，PgBouncer停止监听它们上的数据。在所有缓冲区为空之前，命令不会返回。在PgBouncer在线重新启动时使用。

`RESUME [db];`

从之前的 PAUSE 或 SUSPEND 命令中恢复工作。

`SHUTDOWN;`

PgBouncer进程将会退出。

`RELOAD;`

PgBouncer进程将重新加载它的配置文件并更新可改变的设置。

信号

SIGHUP

重新加载配置。与在控制台上发出命令 RELOAD; 相同。
SIGINT

安全关闭。与在控制台上发出 PAUSE; 和 SHUTDOWN; 相同。
SIGTERM

立即关闭。与在控制台上发出 SHUTDOWN; 相同。

Libevent设置

来自libevent的文档:

可以通过分别设置环境变量EVENT_NOEPOLL、EVENT_NOKQUEUE、
VENT_NODEVPOLL、EVENT_NOPOLL或EVENT_NOSELECT来禁用对
epoll、kqueue、devpoll、poll或select的支持。

通过设置环境变量EVENT_SHOW_METHOD，libevent显示它使用的内核通知方法。

Pgbouncer参数配置

默认配置

;; 数据库名 = 连接串
;;
;; 连接串包括这些参数:
;;   dbname= host= port= user= password=
;;   client_encoding= datestyle= timezone=
;;   pool_size= connect_query=
;;   auth_user=
[databases]

instanceA = host=10.1.1.1 dbname=core
instanceB = host=102.2.2.2 dbname=payment

; 通过Unix套接字的 foodb
;foodb =

; 将bardb在localhost上重定向为bazdb 
;bardb = host=localhost dbname=bazdb

; 使用单个用户访问目标数据库
;forcedb = host=127.0.0.1 port=300 user=baz password=foo client_encoding=UNICODE datestyle=ISO connect_query='SELECT 1'

; 使用定制的连接池大小
;nondefaultdb = pool_size=50 reserve_pool=10

; 如果用户不在认证文件中，替换使用的auth_user; auth_user必须在认证文件中
; foodb = auth_user=bar

; 保底的通配连接串
;* = host=testserver

;; Pgbouncer配置区域
[pgbouncer]

;;;
;;; 管理设置
;;;

logfile = /var/log/pgbouncer/pgbouncer.log
pidfile = /var/run/pgbouncer/pgbouncer.pid

;;;
;;; 监听哪里的客户端
;;;

; 监听IP地址，* 代表所有IP
listen_addr = *
listen_port = 6432

; -R选项也会处理Unix Socket.
; 在Debian上是 /var/run/postgresql
;unix_socket_dir = /tmp
;unix_socket_mode = 0777
;unix_socket_group =

;;;
;;; TLS配置
;;;

;; 选项：disable, allow, require, verify-ca, verify-full
;client_tls_sslmode = disable

;; 信任CA证书的路径
;client_tls_ca_file = <system default>

;; 代表客户端的私钥与证书路径
;; 从客户端接受TLS连接时，这是必须参数
;client_tls_key_file =
;client_tls_cert_file =

;; fast, normal, secure, legacy, <ciphersuite string>
;client_tls_ciphers = fast

;; all, secure, tlsv1.0, tlsv1.1, tlsv1.2
;client_tls_protocols = all

;; none, auto, legacy
;client_tls_dheparams = auto

;; none, auto, <curve name>
;client_tls_ecdhcurve = auto

;;;
;;; 连接到后端数据库时的TLS设置
;;;

;; disable, allow, require, verify-ca, verify-full
;server_tls_sslmode = disable

;; 信任CA证书的路径
;server_tls_ca_file = <system default>

;; 代表后端的私钥与证书
;; 只有当后端服务器需要客户端证书时需要
;server_tls_key_file =
;server_tls_cert_file =

;; all, secure, tlsv1.0, tlsv1.1, tlsv1.2
;server_tls_protocols = all

;; fast, normal, secure, legacy, <ciphersuite string>
;server_tls_ciphers = fast

;;;
;;; 认证设置
;;;

; any, trust, plain, crypt, md5, cert, hba, pam
auth_type = trust
auth_file = /etc/pgbouncer/userlist.txt

;; HBA风格的认证配置文件
# auth_hba_file = /pg/data/pg_hba.conf

;; 从数据库获取密码的查询，结果必须包含两列： 用户名 与 密码哈希值.
;auth_query = SELECT usename, passwd FROM pg_shadow WHERE usename=$1

;;;
;;; 允许访问虚拟数据库'pgbouncer'的用户
;;;

; 允许修改设置，逗号分隔的用户名列表。
admin_users = postgres

; 允许使用SHOW命令，逗号分隔的用户名列表。
stats_users = stats, postgres

;;;
;;; 连接池设置
;;;

; 什么时候服务端连接会被放回到池中？(默认为session)
;   session      - 会话模式，当客户端断开连接时
;   transaction  - 事务模式，当事务结束时
;   statement    - 语句模式，当语句结束时
pool_mode = session

; 客户端释放连接后，用于立刻清理连接的查询。
; 不用把ROLLBACK放在这儿，当事务还没结束时，Pgbouncer是不会重用连接的。
;
; 8.3及更高版本的查询:
;   DISCARD ALL;
;
; 更老的版本:
;   RESET ALL; SET SESSION AUTHORIZATION DEFAULT
;
; 如果启用事务级别的连接池，则为空。
;
server_reset_query = DISCARD ALL


; server_reset_query 是否需要在任何情况下执行。
; 如果关闭(默认)，server_reset_query 只会在会话级连接池中使用。
;server_reset_query_always = 0

;
; Comma-separated list of parameters to ignore when given
; in startup packet.  Newer JDBC versions require the
; extra_float_digits here.
;
;ignore_startup_parameters = extra_float_digits

;
; When taking idle server into use, this query is ran first.
;   SELECT 1
;
;server_check_query = select 1

; If server was used more recently that this many seconds ago,
; skip the check query.  Value 0 may or may not run in immediately.
;server_check_delay = 30

; Close servers in session pooling mode after a RECONNECT, RELOAD,
; etc. when they are idle instead of at the end of the session.
;server_fast_close = 0

;; Use <appname - host> as application_name on server.
;application_name_add_host = 0

;;;
;;; 连接限制
;;;

; 最大允许的连接数
max_client_conn = 100

; 默认的连接池尺寸，当使用事务连接池时，20是一个合适的值。对于会话级连接池而言
; 该值是你想在同一时刻处理的最大连接数。
default_pool_size = 20

;; 连接池中最少的保留连接数
;min_pool_size = 0

; 出现问题时，最多允许多少条额外连接
;reserve_pool_size = 0

; 如果客户端等待超过这么多秒，使用备用连接池
;reserve_pool_timeout = 5

; 单个数据库/用户最多允许多少条连接
;max_db_connections = 0
;max_user_connections = 0

; If off, then server connections are reused in LIFO manner
;server_round_robin = 0

;;;
;;; Logging
;;;

;; Syslog settings
;syslog = 0
;syslog_facility = daemon
;syslog_ident = pgbouncer

; log if client connects or server connection is made
;log_connections = 1

; log if and why connection was closed
;log_disconnections = 1

; log error messages pooler sends to clients
;log_pooler_errors = 1

;; Period for writing aggregated stats into log.
;stats_period = 60

;; Logging verbosity.  Same as -v switch on command line.
;verbose = 0

;;;
;;; Timeouts
;;;

;; Close server connection if its been connected longer.
;server_lifetime = 3600

;; Close server connection if its not been used in this time.
;; Allows to clean unnecessary connections from pool after peak.
;server_idle_timeout = 600

;; Cancel connection attempt if server does not answer takes longer.
;server_connect_timeout = 15

;; If server login failed (server_connect_timeout or auth failure)
;; then wait this many second.
;server_login_retry = 15

;; Dangerous.  Server connection is closed if query does not return
;; in this time.  Should be used to survive network problems,
;; _not_ as statement_timeout. (default: 0)
;query_timeout = 0

;; Dangerous.  Client connection is closed if the query is not assigned
;; to a server in this time.  Should be used to limit the number of queued
;; queries in case of a database or network failure. (default: 120)
;query_wait_timeout = 120

;; Dangerous.  Client connection is closed if no activity in this time.
;; Should be used to survive network problems. (default: 0)
;client_idle_timeout = 0

;; Disconnect clients who have not managed to log in after connecting
;; in this many seconds.
;client_login_timeout = 60

;; Clean automatically created database entries (via "*") if they
;; stay unused in this many seconds.
; autodb_idle_timeout = 3600

;; How long SUSPEND/-R waits for buffer flush before closing connection.
;suspend_timeout = 10

;; Close connections which are in "IDLE in transaction" state longer than
;; this many seconds.
;idle_transaction_timeout = 0

;;;
;;; Low-level tuning options
;;;

;; buffer for streaming packets
;pkt_buf = 4096

;; man 2 listen
;listen_backlog = 128

;; Max number pkt_buf to process in one event loop.
;sbuf_loopcnt = 5

;; Maximum PostgreSQL protocol packet size.
;max_packet_size = 2147483647

;; networking options, for info: man 7 tcp

;; Linux: notify program about new connection only if there
;; is also data received.  (Seconds to wait.)
;; On Linux the default is 45, on other OS'es 0.
;tcp_defer_accept = 0

;; In-kernel buffer size (Linux default: 4096)
;tcp_socket_buffer = 0

;; whether tcp keepalive should be turned on (0/1)
;tcp_keepalive = 1

;; The following options are Linux-specific.
;; They also require tcp_keepalive=1.

;; count of keepalive packets
;tcp_keepcnt = 0

;; how long the connection can be idle,
;; before sending keepalive packets
;tcp_keepidle = 0

;; The time between individual keepalive probes.
;tcp_keepintvl = 0

;; DNS lookup caching time
;dns_max_ttl = 15

;; DNS zone SOA lookup period
;dns_zone_check_period = 0

;; DNS negative result caching time
;dns_nxdomain_ttl = 15

;;;
;;; Random stuff
;;;

;; Hackish security feature.  Helps against SQL-injection - when PQexec is disabled,
;; multi-statement cannot be made.
;disable_pqexec = 0

;; Config file to use for next RELOAD/SIGHUP.
;; By default contains config file from command line.
;conffile

;; Win32 service name to register as.  job_name is alias for service_name,
;; used by some Skytools scripts.
;service_name = pgbouncer
;job_name = pgbouncer

;; Read additional config from the /etc/pgbouncer/pgbouncer-other.ini file
;%include /etc/pgbouncer/pgbouncer-other.ini

空中换引擎 —— PostgreSQL不停机迁移数据

通常涉及到数据迁移，常规操作都是停服务更新。不停机迁移数据是相对比较高级的操作。

著： 冯若航（@Vonng） | 2018-02-06

通常涉及到数据迁移，常规操作都是停服务更新。不停机迁移数据是相对比较高级的操作。

不停机数据迁移在本质上，可以视作由三个操作组成：

复制：将目标表从源库逻辑复制到宿库。
改读：将应用读取路径由源库迁移到宿库上。
改写：将应用写入路径由源库迁移到宿库上。

但在实际执行中，这三个步骤可能会有不一样的表现形式。

逻辑复制

使用逻辑复制是比较稳妥的做法，也有几种不同的做法：应用层逻辑复制，数据库自带的逻辑复制（PostgreSQL 10 之后的逻辑订阅），使用第三方逻辑复制插件（例如pglogical）。

几种逻辑复制的方法各有优劣，我们采用了应用层逻辑复制的方式。具体包括四个步骤：

一、复制

在新库中fork老库目标表的模式，以及所有依赖的函数、序列、权限、属主等对象。
应用添加双写逻辑，同时向新库与老库中写入同样数据。
- 同时向新库与老库写入
保证增量数据正确写入两个一样的库中。
应用需要正确处理全量数据不存在下的删改逻辑。例如改UPDATE为UPSERT，忽略DELETE。
应用读取仍然走老库。
出现问题时，回滚应用至原来的单写版本。

二、同步

老表加上表级排它锁 LOCK TABLE <xxx> IN EXCLUSIVE MODE，阻塞所有写入。
执行全量同步 pg_dump | psql
校验数据一致性，判断迁移是否成功。
出现问题时，简单清空新库中的对应表。

改读
- 应用修改为从新库中读取数据。
- 出现问题时，回滚至从老库中读取的版本。
单写
- 观察一段时间无误后，应用修改为仅写入新库。
- 出现问题时，回滚至双写版本。

说明

关键在于阻塞全量同步期间对老表的写入。这可以通过表级排它锁实现。

在对表进行了分片的情况下，锁表对业务造成的影响非常小。

一张逻辑表拆分成8192个分区，实际上一次只需要处理一个分区。

阻塞对八千分之一的数据写入约几秒到十几秒，业务上通常是可以接受的。

但如果是单张非常大的表，也许就需要特殊处理了。

ETL函数

以下Bash函数接受三个参数，源库URL，宿库URL，以及待迁移的表名。

假设是源宿库都可连接，且目标表都存在。

function etl(){
    local src_url=${1}
    local dst_url=${2}
    local table_name=${3}

    rm -rf "/tmp/etl-${table_name}.done"
    
    psql ${src_url} -1qAtc "LOCK TABLE ${table_name} IN EXCLUSIVE MODE;COPY ${table_name} TO STDOUT;" \
    | psql ${dst_url} -1qAtc "LOCK TABLE ${table_name} IN EXCLUSIVE MODE; TRUNCATE ${table_name}; COPY ${table_name} FROM STDIN;"
    
    touch "/tmp/etl-${table_name}.done"
}

实际上虽然锁定了源表与宿表，但在实际测试中，管道退出时前后两个psql进程退出的timing并不是完全同步的。管道前面的进程比后面一个进程早了0.1秒退出。在负载很大的情况下，可能会产生数据不一致。

另一种更科学的做法是按照某一唯一约束列进行切分，锁定相应的行，更新后释放

物理复制

物理复制是通过回放WAL日志实现的复制，是数据库集簇层面的复制。

基于物理复制的迁移粒度很粗，仅适用于垂直分裂库时使用，会有极短暂的服务不可用。

使用物理复制进行数据迁移的流程如下：

复制，从主库拖出一台从库，保持流式复制。
改读：将应用读取路径从主库改为从库，但写入仍然写入主库。
- 如果有问题，将应用回滚至读主库版本。
改写：将从库提升为主库，阻塞老库的写入，并立即重启应用，切换写入路径至新主库上。
- 将不需要的表和库删除。
- 这一步无法回滚（回滚会损失写入新库的数据）

PgSQL日志方案

建议配置PostgreSQL的日志格式为CSV，方便分析，而且可以直接导入PostgreSQL数据表中。

著： 冯若航（@Vonng） | 2018-02-06

建议配置PostgreSQL的日志格式为CSV，方便分析，而且可以直接导入PostgreSQL数据表中。

日志相关配置项

log_destination ='csvlog'
logging_collector =on
log_directory ='log'
log_filename ='postgresql-%a.log'
log_min_duration_statement =1000
log_checkpoints =on
log_lock_waits =on
log_statement ='ddl'
log_replication_commands =on
log_timezone ='UTC'
log_autovacuum_min_duration =1000

track_io_timing =on
track_functions =all
track_activity_query_size =16384

日志收集

如果需要从外部收集日志，可以考虑使用filebeat。

filebeat.prospectors:

## input
- type: log
enabled: true
paths:
- /var/lib/postgresql/data/pg_log/postgresql-*.csv
document_type: db-trace
tail_files: true
multiline.pattern: '^20\d\d-\d\d-\d\d'
multiline.negate: true
multiline.match: after
multiline.max_lines: 20
max_cpus: 1

## modules
filebeat.config.modules:
path: ${path.config}/modules.d/*.yml
reload.enabled: false

## queue
queue.mem:
events: 1024
flush.min_events: 0
flush.timeout: 1s

## output
output.kafka:
hosts: ["10.10.10.10:9092","x.x.x.x:9092"]
topics:
- topic: 'log.db'

CSV日志格式

很有趣的想法，将CSV日志弄成PostgreSQL表，对于分析而言非常方便。

原始的csv日志格式定义如下：

日志表的结构定义
create table postgresql_log
(
  log_time               timestamp,
  user_name              text,
  database_name          text,
  process_id             integer,
  connection_from        text,
  session_id             text   not null,
  session_line_num       bigint not null,
  command_tag            text,
  session_start_time     timestamp with time zone,
  virtual_transaction_id text,
  transaction_id         bigint,
  error_severity         text,
  sql_state_code         text,
  message                text,
  detail                 text,
  hint                   text,
  internal_query         text,
  internal_query_pos     integer,
  context                text,
  query                  text,
  query_pos              integer,
  location               text,
  application_name       text,
  PRIMARY KEY (session_id, session_line_num)
);

导入日志

日志是结构良好的CSV，（CSV允许跨行记录），直接使用COPY命令导入即可。

COPY postgresql_log FROM '/var/lib/pgsql/data/pg_log/postgresql.log' CSV DELIMITER ',';

映射日志

当然，除了把日志直接拷贝到数据表里分析，还有一种办法，可以让PostgreSQL直接将自己的本地CSVLOG映射为一张外部表。以SQL的方式直接进行访问。

CREATE SCHEMA IF NOT EXISTS monitor;

-- search path for su
ALTER ROLE postgres SET search_path = public, monitor;
SET search_path = public, monitor;

-- extension
CREATE EXTENSION IF NOT EXISTS file_fdw WITH SCHEMA monitor;

-- log parent table: empty
CREATE TABLE monitor.pg_log
(
  log_time               timestamp(3) with time zone,
  user_name              text,
  database_name          text,
  process_id             integer,
  connection_from        text,
  session_id             text,
  session_line_num       bigint,
  command_tag            text,
  session_start_time     timestamp with time zone,
  virtual_transaction_id text,
  transaction_id         bigint,
  error_severity         text,
  sql_state_code         text,
  message                text,
  detail                 text,
  hint                   text,
  internal_query         text,
  internal_query_pos     integer,
  context                text,
  query                  text,
  query_pos              integer,
  location               text,
  application_name       text,
  PRIMARY KEY (session_id, session_line_num)
);
COMMENT ON TABLE monitor.pg_log IS 'PostgreSQL csv log schema';
-- local file server
CREATE SERVER IF NOT EXISTS pg_log FOREIGN DATA WRAPPER file_fdw;
-- Change filename to actual path
CREATE FOREIGN TABLE IF NOT EXISTS monitor.pg_log_mon() INHERITS (monitor.pg_log) SERVER pg_log OPTIONS (filename '/pg/data/log/postgresql-Mon.csv', format 'csv');
CREATE FOREIGN TABLE IF NOT EXISTS monitor.pg_log_tue() INHERITS (monitor.pg_log) SERVER pg_log OPTIONS (filename '/pg/data/log/postgresql-Tue.csv', format 'csv');
CREATE FOREIGN TABLE IF NOT EXISTS monitor.pg_log_wed() INHERITS (monitor.pg_log) SERVER pg_log OPTIONS (filename '/pg/data/log/postgresql-Wed.csv', format 'csv');
CREATE FOREIGN TABLE IF NOT EXISTS monitor.pg_log_thu() INHERITS (monitor.pg_log) SERVER pg_log OPTIONS (filename '/pg/data/log/postgresql-Thu.csv', format 'csv');
CREATE FOREIGN TABLE IF NOT EXISTS monitor.pg_log_fri() INHERITS (monitor.pg_log) SERVER pg_log OPTIONS (filename '/pg/data/log/postgresql-Fri.csv', format 'csv');
CREATE FOREIGN TABLE IF NOT EXISTS monitor.pg_log_sat() INHERITS (monitor.pg_log) SERVER pg_log OPTIONS (filename '/pg/data/log/postgresql-Sat.csv', format 'csv');
CREATE FOREIGN TABLE IF NOT EXISTS monitor.pg_log_sun() INHERITS (monitor.pg_log) SERVER pg_log OPTIONS (filename '/pg/data/log/postgresql-Sun.csv', format 'csv');

加工日志

可以使用以下存储过程从日志消息中进一步提取语句的执行时间

CREATE OR REPLACE FUNCTION extract_duration(statement TEXT)
  RETURNS FLOAT AS $$
DECLARE
  found_duration BOOLEAN;
BEGIN
  SELECT position('duration' in statement) > 0
  into found_duration;
  IF found_duration
  THEN
    RETURN (SELECT regexp_matches [1] :: FLOAT
            FROM regexp_matches(statement, 'duration: (.*) ms')
            LIMIT 1);
  ELSE
    RETURN NULL;
  END IF;
END
$$
LANGUAGE plpgsql
IMMUTABLE;


CREATE OR REPLACE FUNCTION extract_statement(statement TEXT)
  RETURNS TEXT AS $$
DECLARE
  found_statement BOOLEAN;
BEGIN
  SELECT position('statement' in statement) > 0
  into found_statement;
  IF found_statement
  THEN
    RETURN (SELECT regexp_matches [1]
            FROM regexp_matches(statement, 'statement: (.*)')
            LIMIT 1);
  ELSE
    RETURN NULL;
  END IF;
END
$$
LANGUAGE plpgsql
IMMUTABLE;


CREATE OR REPLACE FUNCTION extract_ip(app_name TEXT)
  RETURNS TEXT AS $$
DECLARE
  ip TEXT;
BEGIN
  SELECT regexp_matches [1]
  into ip
  FROM regexp_matches(app_name, '(\d+\.\d+\.\d+\.\d+)')
  LIMIT 1;
  RETURN ip;
END
$$
LANGUAGE plpgsql
IMMUTABLE;

使用FIO测试磁盘性能

FIO可以很方便地测试磁盘IO性能

著： 冯若航（@Vonng） | 2018-02-06

Fio是一个很好用的磁盘性能测试工具，可以通过以下命令测试磁盘的读写性能。

fio --filename=/tmp/fio.data \
    -direct=1 \
    -iodepth=32 \
    -rw=randrw \
    --rwmixread=80 \
    -bs=4k \
    -size=1G \
    -numjobs=16 \
    -runtime=60 \
    -group_reporting \
    -name=randrw \
    --output=/tmp/fio_randomrw.txt \
    && unlink /tmp/fio.data

--8k  随机写
fio -name=8krandw  -runtime=120  -filename=/data/rand.txt -ioengine=libaio -direct=1  -bs=8K  -size=10g  -iodepth=128  -numjobs=1  -rw=randwrite -group_reporting -time_based
  
--8K  随机读
fio -name=8krandr  -runtime=120  -filename=/data/rand.txt -ioengine=libaio -direct=1  -bs=8K  -size=10g  -iodepth=128  -numjobs=1  -rw=randread -group_reporting -time_based
  
--8k  混合读写
fio -name=8krandrw  -runtime=120  -filename=/data/rand.txt -ioengine=libaio -direct=1  -bs=8k  -size=10g  -iodepth=128  -numjobs=1  -rw=randrw -rwmixwrite=30  -group_reporting -time_based
   
--1Mb  顺序写
fio -name=1mseqw  -runtime=120  -filename=/data/seq.txt -ioengine=libaio -direct=1  -bs=1024k  -size=20g  -iodepth=128  -numjobs=1  -rw=write -group_reporting -time_based
  
--1Mb  顺序读
fio -name=1mseqr  -runtime=120  -filename=/data/seq.txt -ioengine=libaio -direct=1  -bs=1024k  -size=20g  -iodepth=128  -numjobs=1  -rw=read -group_reporting -time_based
  
--1Mb  顺序读写
fio -name=1mseqrw  -runtime=120  -filename=/data/seq.txt -ioengine=libaio -direct=1  -bs=1024k  -size=20g  -iodepth=128  -numjobs=1  -rw=rw -rwmixwrite=30  -group_reporting -time_based

测试PostgreSQL相关的IO性能表现时，可以考虑以下参数组合。

3 Demension：RW Ratio, Block Size, N Jobs

RW Ratio: Pure Read, Pure Write, rwmixwrite=80, rwmixwrite=20
Block Size = 4KB (OS granular), 8KB (DB granular)
N jobs: 1 , 4 , 8 , 16 ,32

主要以8KB随机IO为主

使用sysbench测试PostgreSQL性能

尽管PostgreSQL提供了pgbench，但有时候为了吊打一下MySQL，还是需要用到sysbench的。

著： 冯若航（@Vonng） | 2018-02-06

sysbench首页：https://github.com/akopytov/sysbench

安装

二进制安装，在Mac上，使用brew安装sysbench。

brew install sysbench --with-postgresql

源代码编译（CentOS）：

yum -y install make automake libtool pkgconfig libaio-devel
# For MySQL support, replace with mysql-devel on RHEL/CentOS 5
yum -y install mariadb-devel openssl-devel
# For PostgreSQL support
yum -y install postgresql-devel

源代码编译

brew install automake libtool openssl pkg-config
# For MySQL support
brew install mysql
# For PostgreSQL support
brew install postgresql
# openssl is not linked by Homebrew, this is to avoid "ld: library not found for -lssl"
export LDFLAGS=-L/usr/local/opt/openssl/lib

编译：

./autogen.sh

# --with-pgsql --with-pgsql-libs --with-pgsql-includes
# -- without-mysql
./configure 

make -j
make install

准备

创建一个压测用PostgreSQL数据库：bench

初始化测试用数据库：

sysbench /usr/local/share/sysbench/oltp_read_write.lua \
	--db-driver=pgsql \
	--pgsql-host=127.0.0.1 \
	--pgsql-port=5432 \
	--pgsql-user=vonng \
	--pgsql-db=bench \
	--table_size=100000 \
	--tables=3 \
	prepare

输出：

Creating table 'sbtest1'...
Inserting 100000 records into 'sbtest1'
Creating a secondary index on 'sbtest1'...
Creating table 'sbtest2'...
Inserting 100000 records into 'sbtest2'
Creating a secondary index on 'sbtest2'...
Creating table 'sbtest3'...
Inserting 100000 records into 'sbtest3'
Creating a secondary index on 'sbtest3'...

压测

sysbench /usr/local/share/sysbench/oltp_read_write.lua \
	--db-driver=pgsql \
	--pgsql-host=127.0.0.1 \
	--pgsql-port=5432 \
	--pgsql-user=vonng \
	--pgsql-db=bench \
	--table_size=100000 \
    --tables=3 \
    --threads=4 \
    --time=12 \
    run

输出

sysbench 1.1.0-e6e6a02 (using bundled LuaJIT 2.1.0-beta3)

Running the test with following options:
Number of threads: 4
Initializing random number generator from current time


Initializing worker threads...

Threads started!

SQL statistics:
    queries performed:
        read:                            127862
        write:                           36526
        other:                           18268
        total:                           182656
    transactions:                        9131   (760.56 per sec.)
    queries:                             182656 (15214.20 per sec.)
    ignored errors:                      2      (0.17 per sec.)
    reconnects:                          0      (0.00 per sec.)

Throughput:
    events/s (eps):                      760.5600
    time elapsed:                        12.0056s
    total number of events:              9131

Latency (ms):
         min:                                    4.30
         avg:                                    5.26
         max:                                   15.20
         95th percentile:                        5.99
         sum:                                47995.39

Threads fairness:
    events (avg/stddev):           2282.7500/4.02
    execution time (avg/stddev):   11.9988/0.00

找出没用过的索引

索引很有用，但不是免费的。没用到的索引是一种浪费，使用这里的方法找出未使用的索引

著： 冯若航（@Vonng） | 2018-02-04

索引很有用，但不是免费的。没用到的索引是一种浪费，使用以下SQL找出未使用的索引：

首先要排除用于实现约束的索引（删不得）
表达式索引（pg_index.indkey中含有0号字段）
然后找出走索引扫描的次数为0的索引（也可以换个更宽松的条件，比如扫描小于1000次的）

找出没有使用的索引

视图名称：monitor.v_bloat_indexes
计算时长：1秒，适合每天检查/手工检查，不适合频繁拉取。
验证版本：9.3 ~ 10
功能：显示当前数据库索引膨胀情况。

在版本9.3与10.4上工作良好。视图形式

-- CREATE SCHEMA IF NOT EXISTS monitor;
-- DROP VIEW IF EXISTS monitor.pg_stat_dummy_indexes;

CREATE OR REPLACE VIEW monitor.pg_stat_dummy_indexes AS
SELECT s.schemaname,
       s.relname AS tablename,
       s.indexrelname AS indexname,
       pg_relation_size(s.indexrelid) AS index_size
FROM pg_catalog.pg_stat_user_indexes s
   JOIN pg_catalog.pg_index i ON s.indexrelid = i.indexrelid
WHERE s.idx_scan = 0      -- has never been scanned
  AND 0 <>ALL (i.indkey)  -- no index column is an expression
  AND NOT EXISTS          -- does not enforce a constraint
         (SELECT 1 FROM pg_catalog.pg_constraint c
          WHERE c.conindid = s.indexrelid)
ORDER BY pg_relation_size(s.indexrelid) DESC;

COMMENT ON VIEW monitor.pg_stat_dummy_indexes IS 'monitor unused indexes'

-- 人类可读的手工查询
SELECT s.schemaname,
       s.relname AS tablename,
       s.indexrelname AS indexname,
       pg_size_pretty(pg_relation_size(s.indexrelid)) AS index_size
FROM pg_catalog.pg_stat_user_indexes s
   JOIN pg_catalog.pg_index i ON s.indexrelid = i.indexrelid
WHERE s.idx_scan = 0      -- has never been scanned
  AND 0 <>ALL (i.indkey)  -- no index column is an expression
  AND NOT EXISTS          -- does not enforce a constraint
         (SELECT 1 FROM pg_catalog.pg_constraint c
          WHERE c.conindid = s.indexrelid)
ORDER BY pg_relation_size(s.indexrelid) DESC;

批量生成删除索引的命令

SELECT 'DROP INDEX CONCURRENTLY IF EXISTS "' 
	|| s.schemaname || '"."' || s.indexrelname || '";'
FROM pg_catalog.pg_stat_user_indexes s
   JOIN pg_catalog.pg_index i ON s.indexrelid = i.indexrelid
WHERE s.idx_scan = 0      -- has never been scanned
  AND 0 <>ALL (i.indkey)  -- no index column is an expression
  AND NOT EXISTS          -- does not enforce a constraint
         (SELECT 1 FROM pg_catalog.pg_constraint c
          WHERE c.conindid = s.indexrelid)
ORDER BY pg_relation_size(s.indexrelid) DESC;

找出重复的索引

检查是否有索引工作在相同的表的相同列上，但要注意条件索引。

SELECT
  indrelid :: regclass              AS table_name,
  array_agg(indexrelid :: regclass) AS indexes
FROM pg_index
GROUP BY
  indrelid, indkey
HAVING COUNT(*) > 1;

批量配置SSH免密登录

快速配置所有机器的免密登陆

著： 冯若航（@Vonng） | 2018-01-07

配置SSH是运维工作的基础，有时候还是要老生常谈一下。

生成公私钥对

理想的情况是全部通过公私钥认证，从本地免密码直接连接所有数据库机器。最好不要使用密码认证。

首先，使用ssh-keygen生成公私钥对

ssh-keygen -t rsa

注意权限

ssh内文件的权限应当设置为0600，.ssh目录的权限应当设置为0700，设置失当会导致免密登录无法使用。

配置ssh config穿透跳板机

把User换成自己的名字。放入.ssh/config，这里给出了有跳板机环境下配置生产网数据库免密直连的方式：

# Vonng's ssh config

# SpringBoard IP
Host <BastionIP>
	Hostname <your_ip_address>
	IdentityFile ~/.ssh/id_rsa

# Target Machine Wildcard (Proxy via Bastion)
Host 10.xxx.xxx.*
	ProxyCommand ssh <BastionIP> exec nc %h %p 2>/dev/null
	IdentityFile ~/.ssh/id_rsa

# Common Settings
Host *
	User xxxxxxxxxxxxxx
	PreferredAuthentications publickey,password
	Compression yes
	ServerAliveInterval 30
	ControlMaster auto
	ControlPath ~/.ssh/ssh-%r@%h:%p
	ControlPersist yes
	StrictHostKeyChecking no

将公钥拷贝到目标机器上

然后将公钥拷贝到跳板机，DBA工作机，所有数据库机器上。

ssh-copy-id <target_ip>

每次执行此命令都会要求输入密码，非常繁琐无聊，可以通过expect 脚本进行自动化，或者使用sshpass

使用expect自动化

将下列脚本中的<your password>替换为你自己的密码。如果服务器IP列表有变化，修改列表即可。

#!/usr/bin/expect
foreach id { 
     10.xxx.xxx.xxx
     10.xxx.xxx.xxx
     10.xxx.xxx.xxx
} {
    spawn ssh-copy-id $id
    expect {
    	"*(yes/no)?*"
    	{
            send "yes\n"
            expect "*assword:" { send "<your password>\n"}
    	}
     	"*assword*" { send "<your password>\n"}
    }
}

exit

更优雅的解决方案: `sshpass`

sshpass -i <your password> ssh-copy-id <target address>

当然缺点是，密码很有可能出现在bash历史记录中，执行完请及时清理痕迹。

PgSQL协议分析:网络抓包

Wireshark是一个很有用的工具，特别适合用来分析网络协议，这里简单介绍使用Wireshark抓包分析PostgreSQL协议的方法。

著： 冯若航（@Vonng） | 2018-01-05

Wireshark抓包

Wireshark是一个很有用的工具，特别适合用来分析网络协议。

这里简单介绍使用Wireshark抓包分析PostgreSQL协议的方法。

假设调试本地PostgreSQL实例：127.0.0.1:5432

快速开始

下载并安装Wireshark：下载地址
选择要抓包的网卡，如果是本地测试选择lo0即可。
添加抓包过滤器，如果PostgreSQL使用默认设置，使用port 5432即可。
开始抓包
添加显示过滤器pgsql，这样就可以滤除无关的TCP协议报文。
然后就可以执行一些操作，观察并分析协议了

抓包样例

我们先从最简单的case开始，不使用认证，也不使用SSL，执行以下命令建立一条到PostgreSQL的连接。

psql postgres://localhost:5432/postgres?sslmode=disable -c 'SELECT 1 AS a, 2 AS b;'

注意这里sslmode=disable是不能省略的，不然客户端会默认尝试发送SSL请求。localhost也是不能省略的，不然客户端会默认尝试使用unix socket。

这条Bash命令实际上在PostgreSQL对应着三个协议阶段与5组协议报文

启动阶段：客户端建立一条到PostgreSQL服务器的连接。
简单查询协议：客户端发送查询命令，服务器回送查询结果。
终止：客户端中断连接。

Wireshark内建了对PGSQL的解码，允许我们方便地查看PostgreSQL协议报文的内容。

启动阶段，客户端向服务端发送了一条StartupMessage (F)，而服务端回送了一系列消息，包括AuthenticationOK(R)， ParameterStatus(S), BackendKeyData(K) , ReadyForQuery(Z)。这里这几条消息都打包在同一个TCP报文中发送给客户端。

简单查询阶段，客户端发送了一条Query (F)消息，将SQL语句SELECT 1 AS a, 2 AS b;直接作为内容发送给服务器。服务器依次返回了RowDescription(T),DataRow(D),CommandComplete(C),ReadyForQuery(Z).

终止阶段，客户端发送了一条Terminate(X)消息，终止连接。

题外话：使用Mac进行无线网络嗅探

结论： Mac: airport, tcpdump Windows: Omnipeek Linux: tcpdump, airmon-ng

以太网里抓包很简单，各种软件一大把，什么Wireshark，Ethereal，Sniffer Pro 一抓一大把。不过如果是无线数据包，就要稍微麻烦一点了。网上找了一堆罗里吧嗦的文章，绕来绕去的,其实抓无线包一条命令就好了。

Windows下因为无线网卡驱动会拒绝进入混杂模式，所以比较蛋疼，一般是用Omnipeek去弄，不细说了。

Linux和Mac就很方便了。只要用tcpdump就可以，一般系统都自带了。最后-i选项的参数填想抓的网络设备名就行。Mac默认的WiFi网卡是en0。 tcpdump -Ine -i en0

主要就是指定-I参数，进入监控模式。 -I :Put the interface in "monitor mode"; this is supported only on IEEE 802.11 Wi-Fi interfaces, and supported only on some operating systems. 进入监控模式之后计算机用于监控的无线网卡就上不了网了，所以可以考虑买个外置无线网卡来抓包，上网抓包两不误。

抓了包能干很多坏事，比如WEP网络抓几个IV包就可以用aircrack破密码，WPA网络抓到一个握手包就能跑字典破无线密码了。如果在同一个网络内，还可以看到各种未加密的流量……什么小黄图啊，隐私照啊之类的……。

假如我已经知道某个手机的MAC地址，那么只要 tcpdump -Ine -i en0 | grep $MAC_ADDRESS 就过滤出该手机相关的WiFi流量。

具体帧的类型详情参看802.11协议，《802.11无线网络权威指南》等。

顺便解释以下混杂模式与监控模式的区别：混杂(promiscuous)模式是指：接收同一个网络中的所有数据包，无论是不是发给自己的。监控(monitor)模式是指：接收某个物理信道中所有传输着的数据包。

RFMON RFMON is short for radio frequency monitoring mode and is sometimes also described as monitor mode or raw monitoring mode. In this mode an 802.11 wireless card is in listening mode (“sniffer” mode).

The wireless card does not have to associate to an access point or ad-hoc network but can passively listen to all traffic on the channel it is monitoring. Also, the wireless card does not require the frames to pass CRC checks and forwards all frames (corrupted or not with 802.11 headers) to upper level protocols for processing. This can come in handy when troubleshooting protocol issues and bad hardware.

RFMON/Monitor Mode vs. Promiscuous Mode Promiscuous mode in wired and wireless networks instructs a wired or wireless card to process any traffic regardless of the destination mac address. In wireless networks promiscuous mode requires that the wireless card be associated to an access point or ad-hoc network. While in promiscuous mode a wireless card can transmit and receive but will only captures traffic for the network (SSID) to which it is associated.

RFMON mode is only possible for wireless cards and does not require the wireless card to be associated to a wireless network. While in monitor mode the wireless card can passively monitor traffic of all networks and devices within listening range (SSIDs, stations, access points). In most cases the wireless card is not able to transmit and does not follow the typical 802.11 protocol when receiving traffic (i.e. transmit an 802.11 ACK for received packet).

Both modes have to be supported by the driver of the wired or wireless card.

另外在研究抓包工具时，发现了Mac下有一个很好用的命令行工具airport，可以用来抓包，以及摆弄Macbook的WiFi。位置在 /System/Library/PrivateFrameworks/Apple80211.framework/Versions/Current/Resources/airport

可以创建一个符号链接方便使用： sudo ln -s /System/Library/PrivateFrameworks/Apple80211.framework/Versions/Current/Resources/airport /usr/sbin/airport

常用的命令有：显示当前网络信息：airport -I 扫描周围无线网络：airport -s 断开当前无线网络：airport -z 强制指定无线信道：airport -c=$CHANNEL

抓无线包，可以指定信道： airport en0 sniff [$CHANNEL] 抓到的包放在/tmp/airportSniffXXXXX.cap，可以用tcpdump, tshark, wireshark等软件来读。

最实用的功能还是扫描周围无线网络。

file_fdw妙用无穷——从数据库读取系统信息

通过file_fdw，轻松查看操作系统信息，拉取网络数据，把各种各样的数据源轻松喂进数据库里统一查看管理。

著： 冯若航（@Vonng） | 2017-12-01

PostgreSQL是最先进的开源数据库，其中一个非常给力的特性就是FDW：外部数据包装器（Foreign Data Wrapper）。通过FDW，用户可以用统一的方式从Pg中访问各类外部数据源。file_fdw就是其中随数据库附赠的两个fdw之一。随着pg10的更新，file_fdw也添加了一颗赛艇的功能：从程序输出读取。

小霸王妙用无穷，我们能通过file_fdw，轻松查看操作系统信息，拉取网络数据，把各种各样的数据源轻松喂进数据库里统一查看管理。

安装与配置

file_fdw是Pg自带的组件，不需要奇怪的配置，在数据库中执行以下命令即可启用file_fdw：

CREATE EXTENSION file_fdw;

启用FDW插件之后，需要创建一个实例，也是一行SQL搞定，创建一个名为fs的FDW Server实例。

CREATE SERVER fs FOREIGN DATA WRAPPER file_fdw;

创建外部表

举个栗子，如果我想从数据库中读取操作系统中正在运行的进程信息，该怎么做呢？

最典型，也是最常用的外部数据格式就是CSV啦。不过系统命令输出的结果并不是很规整：

>>> ps ux
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
vonng     2658  0.0  0.2 148428  2620 ?        S    11:51   0:00 sshd: vonng@pts/0,pts/2
vonng     2659  0.0  0.2 115648  2312 pts/0    Ss+  11:51   0:00 -bash
vonng     4854  0.0  0.2 115648  2272 pts/2    Ss   15:46   0:00 -bash
vonng     5176  0.0  0.1 150940  1828 pts/2    R+   16:06   0:00 ps -ux
vonng    26460  0.0  1.2 271808 13060 ?        S    10月26   0:22 /usr/local/pgsql/bin/postgres
vonng    26462  0.0  0.2 271960  2640 ?        Ss   10月26   0:00 postgres: checkpointer process
vonng    26463  0.0  0.2 271808  2148 ?        Ss   10月26   0:25 postgres: writer process
vonng    26464  0.0  0.5 271808  5300 ?        Ss   10月26   0:27 postgres: wal writer process
vonng    26465  0.0  0.2 272216  2096 ?        Ss   10月26   0:31 postgres: autovacuum launcher process
vonng    26466  0.0  0.1 126896  1104 ?        Ss   10月26   0:54 postgres: stats collector process
vonng    26467  0.0  0.1 272100  1588 ?        Ss   10月26   0:01 postgres: bgworker: logical replication launcher

可以通过awk，将ps的命令输出规整为分隔符为\x1F的csv格式。

ps aux | awk '{print $1,$2,$3,$4,$5,$6,$7,$8,$9,$10,substr($0,index($0,$11))}' OFS='\037'

正戏来啦！通过以下DDL创建一张外表定义

CREATE FOREIGN TABLE process_status (
  username TEXT,
  pid      INTEGER,
  cpu      NUMERIC,
  mem      NUMERIC,
  vsz      BIGINT,
  rss      BIGINT,
  tty      TEXT,
  stat     TEXT,
  start    TEXT,
  time     TEXT,
  command  TEXT
) SERVER fs OPTIONS (
PROGRAM $$ps aux | awk '{print $1,$2,$3,$4,$5,$6,$7,$8,$9,$10,substr($0,index($0,$11))}' OFS='\037'$$,
FORMAT 'csv', DELIMITER E'\037', HEADER 'TRUE');

这里，关键是通过CREATE FOREIGN TABLE OPTIONS (xxxx)中的OPTIONS提供相应的参数，在PROGRAM参数中填入上面的命令，pg就会在查询这张表的时候自动执行此命令，并读取其输出。FORMAT参数可以指定为CSV，DELIMITER参数指定为之前使用的\x1F，并通过HEADER 'TRUE'忽略CSV的第一行

那么结果如何呢？

有什么用

最简单的场景，原本系统指标监控需要编写各种监测脚本，部署在奇奇怪怪的地方。然后定期执行拉取metric，再存进数据库。现在通过file_fdw的方式，可以将感兴趣的指标直接录入数据库表，一步到位，而且维护方便，部署简单，更加可靠。在外表上加上视图，定期拉取聚合，将原本一个监控系统完成的事情，在数据库中一条龙解决了。

因为可以从程序输出读取结果，因此file_fdw可以与linux生态里各类强大的命令行工具配合使用，发挥出强大的威力。

其他栗子

诸如此类，实际上后来我发现Facebook貌似有一个类似的产品，叫OSQuery，也是干了差不多的事。通过SQL查询操作系统的指标。但明显PostgreSQL这种方法最简单粗暴高效啦，只要定义表结构，和命令数据源就能轻松对接指标数据，用不了一天就能做出一个功能差不多的东西来。

用于读取系统用户列表的DDL：

CREATE FOREIGN TABLE etc_password (
  username  TEXT,
  password  TEXT,
  user_id   INTEGER,
  group_id  INTEGER,
  user_info TEXT,
  home_dir  TEXT,
  shell     TEXT
) SERVER fs OPTIONS (
  PROGRAM $$awk -F: 'NF && !/^[:space:]*#/ {print $1,$2,$3,$4,$5,$6,$7}' OFS='\037' /etc/passwd$$, 
  FORMAT 'csv', DELIMITER E'\037'
);

用于读取磁盘用量的DDL：

CREATE FOREIGN TABLE disk_free (
  file_system TEXT,
  blocks_1m   BIGINT,
  used_1m     BIGINT,
  avail_1m    BIGINT,
  capacity    TEXT,
  iused       BIGINT,
  ifree       BIGINT,
  iused_pct   TEXT,
  mounted_on  TEXT
) SERVER fs OPTIONS (PROGRAM $$df -ml| awk '{print $1,$2,$3,$4,$5,$6,$7,$8,$9}' OFS='\037'$$, FORMAT 'csv', HEADER 'TRUE', DELIMITER E'\037'
);

当然，用file_fdw只是一个很Naive的FDW，譬如这里就只能读，不能改。

自己编写FDW实现增删改查逻辑也非常简单，例如Multicorn就是使用Python编写FDW的项目。

SQL over everything，让世界变的更简单~

Unix命令 iostat

Unix iostat 命令可以用于展示内存的使用情况

著： 冯若航（@Vonng） | 2017-09-07

汇报IO相关统计信息

摘要

iostat [ -c ] [ -d ] [ -N ] [ -n ] [ -h ] [ -k | -m ] [ -t ] [ -V ] [ -x ] [ -y ] [ -z ] [ -j { ID | LABEL | PATH | UUID | ... } [ device [...] | ALL ] ] [ device [...] | ALL ] [ -p [ device [,...] | ALL ] ] [interval [ count ] ]

默认情况下iostat会打印cpu信息和磁盘io信息，使用-d参数只显示IO部分，使用-x打印更多信息。

样例输出：

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           5.77    0.00    1.31    0.07    0.00   92.85

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sdb               0.00         0.00         0.00          0          0
sda               0.00         0.00         0.00          0          0
dfa            5020.00     15856.00     35632.00      15856      35632
dm-0              0.00         0.00         0.00          0          0

常用选项

使用-d参数只显示IO部分的信息，而-c参数则只显示CPU部分的信息。
使用-x会打印更详细的扩展信息
使用-k会使用KB替代块数目作为部分数值的单位，-m则使用MB。

输出说明

不带-x选项默认会为每个设备打印5列：

tps：该设备每秒的传输次数。（多个逻辑请求可能会合并为一个IO请求，传输量未知）
kB_read/s：每秒从设备读取的数据量；kB_wrtn/s：每秒向设备写入的数据量；kB_read：读取的总数据量；kB_wrtn：写入的总数量数据量；这些单位都为Kilobytes，这是使用-k参数的情况。默认则以块数为单位。

带有-x选项后，会打印更多信息：

rrqm/s：每秒这个设备相关的读取请求有多少被Merge了（当系统调用需要读取数据的时候，VFS将请求发到各个FS，如果FS发现不同的读取请求读取的是相同Block的数据，FS会将这个请求合并Merge）；
wrqm/s：每秒这个设备相关的写入请求有多少被Merge了。
r/s 与 w/s：（合并后）每秒读取/写入请求次数
rsec/s 与 wsec/s：每秒读取/写入扇区的数目
avgrq-sz：请求的平均大小（以扇区计）
avgqu-sz：平均请求队列长度
await：每一个IO请求的处理的平均时间（单位是毫秒）
r_await/w_await：读/写的平均响应时间。
%util：设备的带宽利用率，IO时间占比。在统计时间内所有处理IO时间。一般该参数是100%表示设备已经接近满负荷运行了。

常用方法

收集/dev/dfa的IO信息，按kB计算，每秒一次连续10次。

iostat -dxk /dev/dfa 1 10

数据来源

其实是从下面几个文件中提取信息的：

/proc/stat contains system statistics.

/proc/uptime contains system uptime.

/proc/partitions contains disk statistics (for pre 2.5 kernels that have been patched).

/proc/diskstats contains disks statistics (for post 2.5 kernels).

/sys contains statistics for block devices (post 2.5 kernels).

/proc/self/mountstats contains statistics for network filesystems.

/dev/disk contains persistent device names.

Unix命令: free

Unix free 命令可以用于展示内存的使用情况

著： 冯若航（@Vonng） | 2017-09-07

显示系统的内存使用情况

free -b | -k | -m | -g | -h -s delay  -a -l

其中-b | -k | -m | -g | -h 可用于控制显示大小时的单位（字节，KB,MB,GB，自动适配）
-s可以指定轮询周期，-c指定轮询次数。

输出样例

$ free -m
             total       used       free     shared    buffers     cached
Mem:        387491     379383       8107      37762        182     348862
-/+ buffers/cache:      30338     357153
Swap:        65535          0      65535

这里，总内存有378GB，使用370GB，空闲8GB。三者存在total=used+free的关系。共享内存占36GB。
buffers与cache由操作系统分配管理，用于提高I/O性能，其中Buffer是写入缓冲，而Cache是读取缓存。这一行表示，应用程序已使用的buffers/cached，以及理论上可使用的buffers/cache。
```
-/+ buffers/cache:      30338     357153
```
最后一行显示了SWAP信息，总的SWAP空间，实际使用的SWAP空间，以及可用的SWAP空间。只要没有用到SWAP（used = 0），就说明内存空间仍然够用。

`/proc/meminfo`

free实际上是通过cat /proc/meminfo获取信息的。

详细信息：https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/deployment_guide/s2-proc-meminfo

$ cat /proc/meminfo
MemTotal:       396791752 kB	# 总可用RAM, 物理内存减去内核二进制与保留位
MemFree:         7447460 kB		# 系统可用物理内存
Buffers:          186540 kB		# 磁盘快的临时存储大小
Cached:         357066928 kB	# 缓存
SwapCached:            0 kB		# 曾移入SWAP又移回内存的大小
Active:         260698732 kB	# 最近使用过，如非强制不会回收的内存。
Inactive:       112228764 kB	# 最近没怎么用过的内存，可能会回收
Active(anon):   53811184 kB		# 活跃的匿名内存(不与具体文件关联)
Inactive(anon):   532504 kB		# 不活跃的匿名内存
Active(file):   206887548 kB	# 活跃的文件缓存
Inactive(file): 111696260 kB	# 不活跃的文件缓存
Unevictable:           0 kB		# 不可淘汰的内存
Mlocked:               0 kB		# 被钉在内存中
SwapTotal:      67108860 kB		# 总SWAP
SwapFree:       67108860 kB		# 可用SWAP
Dirty:            115852 kB		# 被写脏的内存
Writeback:             0 kB		# 回写磁盘的内存
AnonPages:      15676608 kB		# 匿名页面
Mapped:         38698484 kB		# 用于mmap的内存，例如共享库
Shmem:          38668836 kB		# 共享内存
Slab:            6072524 kB		# 内核数据结构使用内存
SReclaimable:    5900704 kB		# 可回收的slab
SUnreclaim:       171820 kB		# 不可回收的slab
KernelStack:       25840 kB		# 内核栈使用的内存
PageTables:      2480532 kB		# 页表大小
NFS_Unstable:          0 kB		# 发送但尚未提交的NFS页面
Bounce:                0 kB		# bounce buffers
WritebackTmp:          0 kB
CommitLimit:    396446012 kB
Committed_AS:   57195364 kB
VmallocTotal:   34359738367 kB
VmallocUsed:     6214036 kB
VmallocChunk:   34353427992 kB
HardwareCorrupted:     0 kB
AnonHugePages:         0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:        5120 kB
DirectMap2M:     2021376 kB
DirectMap1G:    400556032 kB

其中，free与/proc/meminfo中指标的对应关系为：

total	= (MemTotal + SwapTotal)

used	= (total - free - buffers - cache)

free	= (MemFree + SwapFree)

shared	= Shmem

buffers	= Buffers

cache	= Cached

buffer/cached = Buffers + Cached

清理缓存

可以通过以下命令强制清理缓存：

$ sync # flush fs buffers
$ echo 1 > /proc/sys/vm/drop_caches	# drop page cache
$ echo 2 > /proc/sys/vm/drop_caches	# drop dentries & inode
$ echo 3 > /proc/sys/vm/drop_caches	# drop all

Unix命令: top

Unix top 命令可以用于展示系统当前运行的任务及其状态

著： 冯若航（@Vonng） | 2017-09-07

显示Linux任务

交互式操作

按下空格或回车强制刷新
使用h打开帮助
使用l,t,m收起摘要部分。
使用d修改刷新周期
使用z开启颜色高亮
使用u列出指定用户的进程
使用<>来改变排序列
使用P按CPU使用率排序
使用M按驻留内存大小排序
使用T按累计时间排序

1. 批处理模式

-b参数可以用于批处理模式，配合-n参数指定批次数目。同时-d参数可以指定批次的间隔时间

例如获取机器当前的负载使用情况，以0.1秒为间隔获取三次，获取最后一次的CPU摘要。

$ top -bn3 -d0.1 | grep Cpu | tail -n1
Cpu(s):  4.1%us,  1.0%sy,  0.0%ni, 94.8%id,  0.0%wa,  0.0%hi,  0.1%si,  0.0%st

2. 输出格式

top的输出分为两部分，上面几行是系统摘要，下面是进程列表，两者通过一个空行分割。下面是top命令的输出样例：

top - 12:11:01 up 401 days, 19:17,  2 users,  load average: 1.12, 1.26, 1.40
Tasks: 1178 total,   3 running, 1175 sleeping,   0 stopped,   0 zombie
Cpu(s):  5.4%us,  1.7%sy,  0.0%ni, 92.5%id,  0.1%wa,  0.0%hi,  0.4%si,  0.0%st
Mem:  396791756k total, 389547376k used,  7244380k free,   263828k buffers
Swap: 67108860k total,        0k used, 67108860k free, 366252364k cached

   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
  5094 postgres  20   0 37.2g 829m 795m S 14.2  0.2   0:04.11 postmaster
  5093 postgres  20   0 37.2g 926m 891m S 13.2  0.2   0:04.96 postmaster
165359 postgres  20   0 37.2g 4.0g 4.0g S 12.6  1.1   0:44.93 postmaster
 93426 postgres  20   0 37.2g 6.8g 6.7g S 12.2  1.8   1:32.94 postmaster
  5092 postgres  20   0 37.2g 856m 818m R 11.2  0.2   0:04.21 postmaster
 67634 root      20   0  569m 520m  328 S 11.2  0.1 140720:15 haproxy
 93429 postgres  20   0 37.2g 8.7g 8.7g S 11.2  2.3   2:12.23 postmaster
129653 postgres  20   0 37.2g 6.8g 6.7g S 11.2  1.8   1:27.92 postmaster

2.1摘要部分

摘要默认由三个部分，共计五行组成：

系统运行时间，平均负载，共计一行（l切换内容）
任务、CPU状态，各一行（t切换内容）
内存使用，Swap使用，各一行（m切换内容）

2.1.1 系统运行时间和平均负载

top - 12:11:01 up 401 days, 19:17,  2 users,  load average: 1.12, 1.26, 1.40

当前时间：12:11:01
系统已运行的时间：up 401 days
当前登录用户的数量：2 users
相应最近5、10和15分钟内的平均负载：load average: 1.12, 1.26, 1.40。

Load

Load表示操作系统的负载，即，当前运行的任务数目。而load average表示一段时间内平均的load，也就是过去一段时间内平均有多少个任务在运行。注意Load与CPU利用率并不是一回事。

2.1.2 任务

Tasks: 1178 total,   3 running, 1175 sleeping,   0 stopped,   0 zombie

第二行显示的是任务或者进程的总结。进程可以处于不同的状态。这里显示了全部进程的数量。除此之外，还有正在运行、睡眠、停止、僵尸进程的数量（僵尸是一种进程的状态）。

2.1.3 CPU状态

Cpu(s):  5.4%us,  1.7%sy,  0.0%ni, 92.5%id,  0.1%wa,  0.0%hi,  0.4%si,  0.0%st

下一行显示的是CPU状态。这里显示了不同模式下的所占CPU时间的百分比。这些不同的CPU时间表示:

us, user：运行(未调整优先级的) 用户进程的CPU时间
sy，system: 运行内核进程的CPU时间
ni，niced：运行已调整优先级的用户进程的CPU时间
id，idle：空闲CPU时间
wa，IO wait: 用于等待IO完成的CPU时间
hi：处理硬件中断的CPU时间
si: 处理软件中断的CPU时间
st：虚拟机被hypervisor偷去的CPU时间（如果当前处于一个虚拟机内，宿主机消耗的CPU处理时间）。

2.1.4 内存使用

Mem:  396791756k total, 389547376k used,  7244380k free,   263828k buffers
Swap: 67108860k total,        0k used, 67108860k free, 366252364k cached

内存部分：全部可用内存、已使用内存、空闲内存、缓冲内存。
SWAP部分：全部、已使用、空闲和缓冲交换空间。

2.2 进程部分

进程部分默认会显示一些关键信息

   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
  5094 postgres  20   0 37.2g 829m 795m S 14.2  0.2   0:04.11 postmaster
  5093 postgres  20   0 37.2g 926m 891m S 13.2  0.2   0:04.96 postmaster
165359 postgres  20   0 37.2g 4.0g 4.0g S 12.6  1.1   0:44.93 postmaster
 93426 postgres  20   0 37.2g 6.8g 6.7g S 12.2  1.8   1:32.94 postmaster
  5092 postgres  20   0 37.2g 856m 818m R 11.2  0.2   0:04.21 postmaster
 67634 root      20   0  569m 520m  328 S 11.2  0.1 140720:15 haproxy
 93429 postgres  20   0 37.2g 8.7g 8.7g S 11.2  2.3   2:12.23 postmaster
129653 postgres  20   0 37.2g 6.8g 6.7g S 11.2  1.8   1:27.92 postmaster

PID：进程ID，进程的唯一标识符

USER：进程所有者的实际用户名。

PR：进程的调度优先级。这个字段的一些值是’rt'。这意味这这些进程运行在实时态。

NI：进程的nice值（优先级）。越小的值意味着越高的优先级。

VIRT：进程使用的虚拟内存。

RES：驻留内存大小。驻留内存是任务使用的非交换物理内存大小。

SHR：SHR是进程使用的共享内存。

S这个是进程的状态。它有以下不同的值:

D - 不可中断的睡眠态。
R – 运行态
S – 睡眠态
T – Trace或Stop
Z – 僵尸态

%CPU：自从上一次更新时到现在任务所使用的CPU时间百分比。

%MEM：进程使用的可用物理内存百分比。

TIME+：任务启动后到现在所使用的全部CPU时间，单位为百分之一秒。

COMMAND：运行进程所使用的命令。

Linux进程的状态
static const char * const task_state_array[] = {
  "R (running)", /* 0 */
  "S (sleeping)", /* 1 */
  "D (disk sleep)", /* 2 */
  "T (stopped)", /* 4 */
  "t (tracing stop)", /* 8 */
  "X (dead)", /* 16 */
  "Z (zombie)", /* 32 */
};
R (TASK_RUNNING)，可执行状态。实际运行与Ready在Linux都算做Running状态

S(TASK_INTERRUPTIBLE)，可中断的睡眠态，进程等待事件，位于等待队列中。

D (TASK_UNINTERRUPTIBLE)，不可中断的睡眠态，无法响应异步信号，例如硬件操作，内核线程

T (TASK_STOPPED | TASK_TRACED)，暂停状态或跟踪状态，由SIGSTOP或断点触发

Z (TASK_DEAD)，子进程退出后，父进程还没有来收尸，留下task_structure的进程就处于这种状态。

Unix命令: vmstat

Unix vmstat 命令可以用于汇报虚拟内存统计信息

著： 冯若航（@Vonng） | 2017-09-07

汇报虚拟内存统计信息

摘要

vmstat [-a] [-n] [-t] [-S unit] [delay [ count]]
vmstat [-s] [-n] [-S unit]
vmstat [-m] [-n] [delay [ count]]
vmstat [-d] [-n] [delay [ count]]
vmstat [-p disk partition] [-n] [delay [ count]]
vmstat [-f]
vmstat [-V]

最常用的用法是：

vmstat <delay> <count>

例如vmstat 1 10就是以1秒为间隔，采样10次内存统计信息。

样例输出

$ vmstat 1 4 -S M
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 3  0      0   7288    170 344210    0    0   158   158    0    0  2  1 97  0  0
 5  0      0   7259    170 344228    0    0  7680 13292 38783 36814  6  1 93  0  0
 3  0      0   7247    170 344246    0    0  8720 21024 40584 39686  6  1 93  0  0
 1  0      0   7233    170 344255    0    0  6800 24404 39461 36984  6  1 93  0  0

Procs
    r: 等待运行的进程数目
    b: 处于不可中断睡眠状态的进程数(Block)
Memory
    swpd: 使用的交换区大小，大于0则说明内存过小
    free: 空闲内存
    buff: 缓冲区内存
    cache: 页面缓存
    inact: 不活跃内存 (-a 选项)
    active: 活跃内存 (-a 选项)
Swap
    si: 每秒从磁盘中换入的内存 (/s).
    so: 每秒从换出到磁盘的内存 (/s).
IO
    bi: 从块设备每秒收到的块数目 (blocks/s).
    bo: 向块设备每秒发送的快数目 (blocks/s).
System
    in: 每秒中断数，包括时钟中断
    cs: 每秒上下文切换数目
CPU
    总CPU时间的百分比
    us: 用户态时间 (包括nice的时间)
    sy: 内核态时间
    id: 空闲时间（在2.5.41前包括等待IO的时间）
    wa: 等待IO的时间（在2.5.41前包括在id里）
    st: 空闲时间（在2.6.11前没有）

数据来源

其实是从下面三个文件中提取信息的：

/proc/meminfo
/proc/stat
/proc/*/stat

输出

编译安装PostGIS

PostGIS是PG的杀手锏插件，但编译安装可不容易。

著： 冯若航（@Vonng） | 2017-09-07

使用Yum安装PostGIS

参考http://www.postgresonline.com/journal/archives/362-An-almost-idiots-guide-to-install-PostgreSQL-9.5,-PostGIS-2.2-and-pgRouting-2.1.0-with-Yum.html

1. 安装环境

CentOS 7
PostgreSQL10
PostGIS2.4
PGROUTING2.5.2

2. PostgreSQL10安装

2.1 确定系统环境

uname -a

Linux localhost.localdomain 3.10.0-693.el7.x86_64 #1 SMP Tue Aug 22 21:09:27 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

2.2 安装正确的rpm包

  rpm -ivh https://download.postgresql.org/pub/repos/yum/10/redhat/rhel-7-x86_64/pgdg-centos10-10-2.noarch.rpm

不同的系统使用不同的rpm源，你可以从 http://yum.postgresql.org/repopackages.php获取相应的平台链接。

2.3 查看rpm包是否正确安装

yum list | grep pgdg

pgdg-centos10.noarch                        10-2                       installed
CGAL.x86_64                                 4.7-1.rhel7                pgdg10
CGAL-debuginfo.x86_64                       4.7-1.rhel7                pgdg10
CGAL-demos-source.x86_64                    4.7-1.rhel7                pgdg10
CGAL-devel.x86_64                           4.7-1.rhel7                pgdg10
MigrationWizard.noarch                      1.1-3.rhel7                pgdg10
...

2.4 安装PG

yum install -y postgresql10 postgresql10-server postgresql10-libs postgresql10-contrib postgresql10-devel

你可以根据需要选择安装相应的rpm包。

2.5 启动服务

默认情况下，PG安装目录为/usr/pgsql-10/，data目录为/var/lib/pgsql/,系统默认创建用户postgres

passwd postgres # 为系统postgres设置密码
su - postgres 	# 切换到用户postgres
/usr/pgsql-10/bin/initdb -D /var/lib/pgsql/10/data/	# 初始化数据库
/usr/pgsql-10/bin/pg_ctl -D /var/lib/pgsql/10/data/ -l logfile start	# 启动数据库
/usr/pgsql-10/bin/psql postgres postgres	# 登录

3. PostGIS安装

yum install postgis24_10-client postgis24_10

如果遇到错误如下：

--> 解决依赖关系完成
错误：软件包：postgis24_10-client-2.4.2-1.rhel7.x86_64 (pgdg10)
          需要：libproj.so.0()(64bit)
错误：软件包：postgis24_10-2.4.2-1.rhel7.x86_64 (pgdg10)
          需要：gdal-libs >= 1.9.0

你可以尝试通过以下命令解决:yum -y install epel-release

4. fdw安装

yum install ogr_fdw10

5. pgrouting安装

yum install pgrouting_10

6. 验证测试

# 登录pg后执行以下命令，无报错则证明成功
CREATE EXTENSION postgis;
CREATE EXTENSION postgis_topology;
CREATE EXTENSION ogr_fdw;

SELECT postgis_full_version();

一些依赖组件的编译方式

编译工具

此类工具一般系统都自带。

GCC与G++，版本至少为4.x。
GNU Make，CMake， Autotools
Git

CentOS下直接通过sudo yum install gcc gcc-c++ git autoconf automake libtool m4 安装。

必选依赖

PostgreSQL

PostgreSQL是PostGIS的宿主平台。这里以10.1为例。

GEOS

GEOS是Geometry Engine, Open Source的缩写，是一个C++版本的几何库。是PostGIS的核心依赖。

PostGIS 2.4用到了GEOS 3.7的一些新特性。不过截止到现在，GEOS官方发布的最新版本是3.6.2，3.7版本的GEOS可以通过Nightly snapshot获取。所以目前如果希望用到所有新特性，需要从源码编译安装GEOS 3.7。

# 滚动的每日更新，此URL有可能过期，检查这里http://geos.osgeo.org/snapshots/
wget -P ./ http://geos.osgeo.org/snapshots/geos-20171211.tar.bz2
tar -jxf geos-20171211.tar.bz2
cd geos-20171211
./configure
make
sudo make install
cd ..

Proj

为PostGIS提供坐标投影支持，目前最新版本为4.9.3 ：下载

# 此URL有可能过期，检查这里http://proj4.org/download.html
wget -P . http://download.osgeo.org/proj/proj-4.9.3.tar.gz
tar -zxf proj-4.9.3.tar.gz
cd proj-4.9.3
make 
sudo make install

JSON-C

目前用于导入GeoJSON格式的数据，函数ST_GeomFromGeoJson用到了这个库。

编译json-c需要用到autoconf, automake, libtool。

git clone https://github.com/json-c/json-c
cd json-c
sh autogen.sh

./configure  # --enable-threading
make
make install

LibXML2

目前用于导入GML与KML格式的数据，函数ST_GeomFromGML和ST_GeomFromKML依赖这个库。

目前可以在这个FTP服务器上搞到，目前使用的版本是2.9.7

tar -zxf libxml2-sources-2.9.7.tar.gz
cd libxml2-sources-2.9.7
./configure
make 
sudo make install

GADL

wget -P . http://download.osgeo.org/gdal/2.2.3/gdal-2.2.3.tar.gz

SFCGAL

SFCGAL是CGAL的扩展包装，虽说是可选项，但是很多函数都会经常用到，因此这里也需要安装。下载页面

SFCGAL依赖的东西比较多。包括CMake, CGAL, Boost, MPFR, GMP等，其中，CGAL在上面手动安装过了。这里还需要手动安装BOOST

wget -P . https://github.com/Oslandia/SFCGAL/archive/v1.3.0.tar.gz

Boost

Boost是C++的常用库，SFCGAL依赖BOOST，下载页面

wget -P . https://dl.bintray.com/boostorg/release/1.65.1/source/boost_1_65_1.tar.gz
tar -zxf boost_1_65_1.tar.gz
cd boost_1_65_1
./bootstrap.sh
./b2

PostgreSQL MongoFDW安装部署

了解PostgreSQL中的黄金监控指标

著： 冯若航（@Vonng） | 2016-05-28

更新：最近MongoFDW已经由Cybertech接手维护，也许没有这么不堪了。

最近有业务要求通过PostgreSQL FDW去访问MongoDB。开始我觉得这是个很轻松的任务。但接下来的事真是让人恶心的吐了。MongoDB FDW编译起来真是要人命：混乱的依赖，临时下载和Hotpatch，错误的编译参数，以及最过分的是错误的文档。总算，我在生产环境(Linux RHEL7u2)和开发环境(Mac OS X 10.11.5)都编译成功了。赶紧记录下来，省的下次蛋疼。

环境概述

理论上编译这套东西，GCC版本至少为4.1。生产环境 (RHEL7.2 + PostgreSQL9.5.3 + GCC 4.8.5) 本地环境 (Mac OS X 10.11.5 + PostgreSQL9.5.3 + clang-703.0.31)

mongo_fdw的依赖

总的来说，能用包管理解决的问题，尽量用包管理解决。 mongo_fdw是我们最终要安装的包它的直接依赖有三个

总的来说，mongo_fdw是使用mongo提供的C驱动程序完成功能的。所以我们需要安装libbson与libmongoc。其中libmongoc就是MongoDB的C语言驱动库，它依赖于libbson。所以最后的安装顺序是： libbson → libmongoc → json-c→ mongo_fdw

间接依赖

默认依赖的GNU Build全家桶，文档是不会告诉你的。下面列出一些比较简单的，可以通过包管理解决的依赖。请一定按照以下顺序安装GNU Autotools

m4-1.4.17 → autoconf-2.69 → automake-1.15 → libtool-2.4.6 → pkg-config-0.29.1。总之，用yum也好，apt也好，homebrew也好，都是一行命令能搞定的事。还有一个依赖是libmongoc的依赖：openssl-devel，不要忘记装。

安装 `libbson-1.3.1`

git clone -b r1.3 https://github.com/mongodb/libbson;
cd libbson;
git checkout 1.3.1;
./autogen.sh;
make && sudo make install;
make test;

安装 `libmongoc-1.3.1`

git clone -b r1.3 https://github.com/mongodb/mongo-c-driver
cd mongo-c-driver;
git checkout 1.3.1;
./autogen.sh;
# 下一步很重要，一定要使用刚才安装好的系统中的libbson。
./configure --with-libbson=system;
make && sudo make install;

这里为什么要使用1.3.1的版本？这也是有讲究的。因为mongo_fdw中默认使用的是1.3.1的mongo-c-driver。但是它在文档里说只要1.0.0+就可以，其实是在放狗屁。mongo-c-driver与libbson版本是一一对应的。1.0.0版本的libbson脑子被驴踢了，使用了超出C99的特性，比如复数类型。要是用了默认版本就傻逼了。

安装`json-c`

首先，我们来解决json-c的问题

git clone https://github.com/json-c/json-c;
cd json-c
git checkout json-c-0.12

./configure完了可不要急着Make，这个版本的json-c编译参数有问题。 ** 打开Makefile，找到CFLAGS,在编译参数后面添加-fPIC ** 这样GCC会生成位置无关代码，不这样做的话mongo_fdw链接会报错。

安装 `Mongo FDW`

真正恶心的地方来咯。

git clone https://github.com/EnterpriseDB/mongo_fdw;

好了，如果这时候想当然的运行./autogen.sh --with-master，它就会去重新下一遍上面几个包了……，而且都是从墙外亚马逊的云主机去下。靠谱的方法就是手动一条条的执行autogen里面的命令。

首先把上面的json-c目录复制到mongo_fdw的根目录内。然后添加libbson和libmongoc的include路径。

export C_INCLUDE_PATH="/usr/local/include/libbson-1.0/:/usr/local/include/libmongoc-1.0:$C_INCLUDE_PATH"

查看autogen.sh，发现里面根据--with-legacy和--with-master的不同选项，会有不同的操作。具体来说，当指定--with-master选项时，它会创建一个config.h,里面定义了一个META_DRIVER的宏变量。当有这个宏变量时，mongo_fdw会使用mongoc.h头文件，也就是所谓的“master”，新版的mongo驱动。当没有时，则会使用"mongo.h"头文件，也就是老版的mongo驱动。这里，我们直接vi config.h，添加一行

#define META_DRIVER

这时候，基本上才能算万事大吉。在最终build之前，别忘了执行：ldconfig

[sudo] ldconfig

回到mongo_fdw根目录make，不出意外，这个mongo_fdw.so就出来了。

试一试吧？

sudo make install;
psql
admin=# CREATE EXTENSION mongo_fdw;

如果提示找不到libmongoc.so和libbson.so，直接把它们丢进pgsql的lib目录即可。

sudo cp /usr/local/lib/libbson* /usr/local/pgsql/lib/
sudo cp /usr/local/lib/libmongoc* /usr/local/pgsql/lib/

PgSQL: WAL与检查点

介绍PostgreSQL中的WAL与检查点机制。

著： 冯若航（@Vonng） |

数据库需要保证两个基本的特性：可靠性与可用性。通俗来讲：

可靠性就是：出了故障，既不会丢数据，也不会弄脏数据。

可用性就是：保证足够的读写性能，出了故障后，能够快速恢复服务。

朴素的数据库实现有两个选项：在内存中修改数据页，或者将事物变更直接写入磁盘。但这产生了一个两难困境：

内存支持随机读写，因此在性能上表现强悍，然而作为易失性存储，一旦故障就会丢数据。
硬盘恰恰相反，随机读写表现糟糕，但在故障时数据要可靠的多。

内存可用性强可靠性差，硬盘可用性差但可靠性强，如何解决这一对矛盾，让内存与硬盘取长补短，就是生产级数据库需要考虑的问题了。

0x1 核心思想

硬盘的随机写入性能很糟糕，但顺序写入的性能却非常可观。即使是SSD也符合这一规律，因为一次写入的擦除单位是Block（通常是几M），而操作系统的写入单元是Page（通常约4k）。如果每次事物提交都要直接将脏数据页落盘，性能表现肯定不会可观。但如果采用另一种方式，将数据的变更而不是变更后的最新数据本身落盘，就可以将随机写入变为顺序写入，从而极大地提高磁盘写入效率。

于是，预写式日志（WAL，Write Ahead Log）出现了，所谓日志，在最朴素的意义上来讲，就是一个Append-Only的数据文件，记录了操作的内容。只要保留了WAL，数据库就是可靠的，可以恢复的。从一个给定的状态，例如空数据库开始，回放所有的操作日志到当前的时间点，就可以恢复出当前数据库应有的状态。与此同时，如果日志已经落盘确保了可靠性，数据页就不需要在每次提交时落盘了。数据页的读写可以完全在内存进行，从而提供强悍的性能支持。

但可用性不仅仅包括足够的性能，当发生故障时能够快速恢复也是可用性要求的一部分。考虑最极端的情况，从数据库创建之初所有数据页就在内存里一直飘着，只有操作日志落了盘。现在数据库运行了一整年，突然崩溃了，这时候要想恢复就需要重放一整年的操作日志，也许需要几个小时，也许需要好几天。对于生产环境，这是无法接受的，检查点（Checkpoint）解决了这个问题。

检查点（Checkpoint）类似于游戏中存档的概念，远古时期的很多游戏没有存档，一旦Game Over就要重头再来。后来的游戏有了记忆和存档，当挑战Boss失败时，只要读取最近的存档，就可以避免从头开始。

数据库中的检查点代表这样一种操作，在某一个检查点时，所有脏数据页会写回到磁盘中，使得磁盘和内存中的数据保持一致。这样当故障恢复时，只需要从该检查点开始回放操作日志即可。

例如，每个整点执行一次检查点，存档一次，那么当故障时，只需要从本小时开始的检查点开始回放WAL，就可以完成恢复。同时，检查点还有一个好处是，当数据页落盘之后，在这个检查点之前的WAL日志就可以不用了。对于高负载数据库，例如每小时产生TB级别WAL的数据库，使用检查点能够极大地减少恢复的时间和磁盘的用量。

通过检查点和预写式日志，数据库可以同时保证高度的可靠性和可用性。

0x2 WAL概述

预写式日志（WAL）是保证数据完整性的一种标准方法。对其详尽的描述几乎可以在所有（如果不是全部）有关事务处理的书中找到。简单来说，WAL的中心概念是数据文件（存储着表和索引）的修改必须在这些动作被日志记录之后才被写入，即在描述这些改变的日志记录被刷到持久存储以后。如果我们遵循这种过程，我们不需要在每个事务提交时刷写数据页面到磁盘，因为我们知道在发生崩溃时可以使用日志来恢复数据库：任何还没有被应用到数据页面的改变可以根据其日志记录重做（这是前滚恢复，也被称为REDO）。

使用WAL可以显著降低磁盘的写次数，因为只有日志文件需要被刷出到磁盘以保证事务被提交，而被事务改变的每一个数据文件则不必被刷出。日志文件被按照顺序写入，因此同步日志的代价要远低于刷写数据页面的代价。在处理很多影响数据存储不同部分的小事务的服务器上这一点尤其明显。此外，当服务器在处理很多小的并行事务时，日志文件的一个fsync可以提交很多事务。

##异步提交

异步提交是一个允许事务能更快完成的选项，代价是在数据库崩溃时最近的事务会丢失。在很多应用中这是一个可接受的交换。

如前一节所述，事务提交通常是同步的：服务器等到事务的WAL记录被刷写到持久存储之后才向客户端返回成功指示。因此客户端可以确保那些报告已被提交的事务确会被保存，即便随后马上发生了一次服务器崩溃。但是，对于短事务来说这种延迟是其总执行时间的主要部分。选择异步提交模式意味着服务器将在事务被逻辑上提交后立刻返回成功，而此时由它生成的WAL记录还没有被真正地写到磁盘上。这将为小型事务的生产力产生显著地提升。

异步提交会带来数据丢失的风险。在向客户端报告事务完成到事务真正被提交（即能保证服务器崩溃时它也不会被丢失）之间有一个短的时间窗口。因此如果客户端将会做一些要求其事务被记住的外部动作，就不应该用异步提交。例如，一个银行肯定不会使用异步提交事务来记录一台ATM的现金分发。但是在很多情境中不需要这种强的保证，例如事件日志。

使用异步提交带来的风险是数据丢失，而不是数据损坏。如果数据库可能崩溃，它会通过重放WAL到被刷写的最后一个记录来进行恢复。数据库将因此被恢复到一个自身一致状态，但是任何还没有被刷写到磁盘的事务将不会反映在该状态中。因此其影响就是丢失了最后的少量事务。由于事务按照提交顺序被重放，所以不会出现任何不一致性 — 例如一个事务B按照前面一个事务A的效果来进行修改，则不会出现A的效果丢失而B的效果被保留的情况。

用户可以选择每一个事务的提交模式，这样可以有同步提交和异步提交的事务并行运行。这允许我们灵活地在性能和事务持久性之间进行权衡。提交模式由用户可设置的参数synchronous_commit控制，它可以使用任何一种修改配置参数的方法进行设置。一个事务真正使用的提交模式取决于当事务提交开始时synchronous_commit的值。

特定的实用命令，如DROP TABLE，被强制按照同步提交而不考虑synchronous_commit的设定。这是为了确保服务器文件系统和数据库逻辑状态之间的一致性。支持两阶段提交的命令页总是同步提交的，如PREPARE TRANSACTION。

如果数据库在异步提交和事务WAL记录写入之间的风险窗口期间崩溃，在该事务期间所作的修改将丢失。风险窗口的持续时间是有限制的，因为一个后台进程（“WAL写进程”）每wal_writer_delay毫秒会把未写入的WAL记录刷写到磁盘。风险窗口实际的最大持续时间是wal_writer_delay的3倍，因为WAL写进程被设计成倾向于在忙时一次写入所有页面。

一个立刻关闭等同于一次服务器崩溃，因此也将会导致未刷写的异步提交丢失。

异步提交提供的行为与配置fsync = off不同。fsync是一个服务器范围的设置，它将会影响所有事务的行为。它禁用了PostgreSQL中所有尝试同步写入到数据库不同部分的逻辑，并且因此一次系统崩溃（即，一个硬件或操作系统崩溃，不是PostgreSQL本身的失败）可能造成数据库状态的任意损坏。在很多情境中，带来大部分性能提升的异步提交可以通过关闭fsync来获得，而且不会带来数据损坏的风险。

commit_delay也看起来很像异步提交，但它实际上是一种同步提交方法（事实上，commit_delay在异步提交时被忽略）。commit_delay会使事务在刷写WAL到磁盘之前有一个延迟，它期望由一个这样的事务所执行的刷写能够也服务于其他同时提交的事务。该设置可以被看成是一种时间窗口，在其期间事务可以参与到一次单一的刷写中，这种方式用于在多个事务之间摊销刷写的开销。

0x3 查看WAL状态

0x5 流复制

0x6 Checkpoint

WAL相关视图与函数

Checkpoint相关参数

安全的删除WAL

如果想要删除wal日志，要么让pg在CHECKPOINT的时候自己删除，或者使用pg_archivecleanup。除了以下三种情况，pg会自动清除不再需要的wal日志：

archive_mond=on，但是archive_commandfailed，这样pg会一直保留wal日志，直到重试成功。
wal_keep_segments需要保留一定的数据。
9.4之后，可能会因为replication slot保留；

如果都不符合上述情况，我们想要清理wal日志，可以通过执行CHECKPOINT来清理当前不需要的wal。

在一些非寻常情况下，可能需要pg_archivecleanup命令，比如由于wal归档失败导致的wal堆积引起的磁盘空间溢出。你可能使用这个命令来清理归档wal日志，但是永远不要手动删除wal段；

故障

关于PostgreSQL的一些故障记录

故障档案:时间回溯导致的Patroni故障

机器因为故障重启，NTP服务在PG启动后修复了PG的时间，导致Patroni无法启动。

著： 冯若航（@Vonng） | 2021-02-22

【草稿】

机器因为故障重启，NTP服务在PG启动后修复了PG的时间，导致Patroni无法启动。

Patroni中的故障信息如下所示。

patroni 进程启动时间和pid时间不一致。就会认为：postgres is not running。

两个时间相差超过30秒。patroni就尿了。

还发现了Patroni里的一个BUG：https://github.com/zalando/patroni/issues/811

错误信息里两个时间戳打反了。

故障档案：PG安装Extension导致无法连接

今天遇到一个比较有趣的Case，客户报告说数据库连不上了，发现是扩展导致的。

著： 冯若航（@Vonng） | 2019-06-13

今天遇到一个比较有趣的Case，客户报告说数据库连不上了。报这个错：

psql: FATAL:  could not load library "/export/servers/pgsql/lib/pg_hint_plan.so": /export/servers/pgsql/lib/pg_hint_plan.so: undefined symbol: RINFO_IS_PUSHED_DOWN

当然，这种错误一眼就知道是插件没编译好，报符号找不到。因此数据库后端进程在启动时尝试加载pg_hint_plan插件时就GG了，报FATAL错误直接退出。

通常来说这个问题还是比较好解决的，这种额外的扩展通常都是在shared_preload_libraries中指定的，只要把这个扩展名称去掉就好了。

结果……

客户说是通过ALTER ROLE|DATABASE SET session_preload_libraries = pg_hint_plan的方式来启用扩展的。

这两条命令会在使用特定用户，或连接到特定数据库时覆盖系统默认参数，去加载pg_hint_plan插件。

ALTER DATABASE postgres SET session_preload_libraries = pg_hint_plan;
ALTER ROLE postgres SET session_preload_libraries = pg_hint_plan;

如果是这样的话，也是可以解决的，通常来说只要有其他的用户或者其他的数据库可以正常登陆，就可以通过ALTER TABLE语句把这两行配置给去掉。

但坏事就坏在，所有的用户和数据库都配了这个参数，以至于没有任何一条连接能连到数据库了。

这种情况下，数据库就成了植物人状态，postmaster还活着，但任何新创建的后端服务器进程都会因为扩展失效自杀……。即使dropdb这种外部自带的二进制命令也无法工作。

于是……

无法建立到数据库的连接，那么常规手段就都失效了……，只能Dirty hack了。

如果我们从二进制层面把用户和数据库级别的配置项给抹掉，那么就可以连接到数据库，把扩展给清理掉了。

DB与Role级别的配置存储在系统目录pg_db_role_setting中，这个表有着固定的OID = 2964，存储在数据目录下global/2964里。关闭数据库，使用二进制编辑器打开pg_db_role_setting对应的文件

# vim打开后使用 :%!xxd 编辑二进制
# 编辑完成后使用 :%!xxd -r转换回二进制，再用:wq保存
vi ${PGDATA}/global/2964

这里，将所有的pg_hint_plan字符串都替换成等长的^@二进制零字符即可。当然如果不在乎原来的配置，更省事的做法是直接把这个文件截断成零长文件。

重启数据库，终于又能连接上了。

复现

这个问题复现起来也非常简单，初始化一个新数据库实例

initdb -D /pg/test -U postgres && pg_ctl -D /pg/test start

然后执行以下语句，就可以体会这种酸爽了。

psql postgres postgres -c 'ALTER ROLE postgres SET session_preload_libraries = pg_hint_plan;'

教训……

安装扩展后，一定要先验证扩展本身可以正常工作，再启用扩展
凡事留一线，日后好相见：一个紧急备用的纯洁的su，或者一个无污染的可连接数据库，都不至于这么麻烦。

故障档案：pg_dump导致的连接池污染

有时候，组件之间的相互作用会以微妙的形式表现出来。例如使用pg_dump从连接池中导出数据，就可能产生连接池污染的问题。

著： 冯若航（@Vonng） | 2018-12-11

PostgreSQL很棒，但这并不意味着它是Bug-Free的。这一次在线上环境中，我又遇到了一个很有趣的Case：由pg_dump导致的线上故障。这是一个非常微妙的Bug，由Pgbouncer，search_path，以及特殊的pg_dump操作所触发。

背景知识

连接污染

在PostgreSQL中，每条数据库连接对应一个后端进程，会持有一些临时资源（状态），在连接结束时会被销毁，包括：

本会话中修改过的参数。RESET ALL;
准备好的语句。 DEALLOCATE ALL
打开的游标。CLOSE ALL;
监听的消息信道。UNLISTEN *
执行计划的缓存。DISCARD PLANS;
预分配的序列号值及其缓存。DISCARD SEQUENCES;
临时表。DISCARD TEMP

Web应用会频繁建立大量的数据库连接，故在实际应用中通常都会使用连接池，复用连接，以减小连接创建与销毁的开销。除了使用各种语言/驱动内置的连接池外，Pgbouncer是最常用的第三方中间件连接池。Pgbouncer提供了一种Transaction Pooling的模式，即：每当客户端事务开始时，连接池会为客户端连接分配一个服务端连接，当事务结束时，服务端连接会被放回到池中。

事务池化模式也存在一些问题，例如连接污染。当某个客户端修改了连接的状态，并将该连接放回池中，其他的应用遍可能受到非预期的影响。如下图所示：

假设有四条客户端连接（前端连接）C1、C2、C3、C4，和两条服务器连接（后端连接）S1，S2。数据库默认搜索路径被配置为：app,$user,public，应用知道该假设，并使用SELECT * FROM tbl;的方式，来默认访问模式app下的表app.tbl。现在假设客户端C2在使用了服务器连接S2的过程中，执行了set search_path = ''清空了连接S2上的搜索路径。当S2被另一个客户端C3复用时，C3执行SELECT * FROM tbl时就会因为search_path中找不到对应的表而报错。

当客户端对于连接的假设被打破时，很容易出现各种错误。

故障排查

线上应用突然大量报错触发熔断，错误内容为大量的对象（表，函数）找不到。

第一直觉就是连接池被污染了：某个连接在修改完search_path之后将连接放回池中，当这个后端连接被其他前端连接复用时，就会出现找不到对象的情况。

连接至相应的Pool中，发现确实存在连接的search_path被污染的情况，某些连接的search_path被置空了，因此使用这些连接的应用就找不到对象了。

psql -p6432 somedb
# show search_path; \watch 0.1

在Pgbouncer中使用管理员账户执行RECONNECT命令，强制重连所有连接，search_path重置为默认值，问题解决。

reconnect somedb

不过问题就来了，究竟是什么应用修改了search_path呢？如果问题来源没有排查清楚，难免以后会重犯。有几种可能：业务代码修改，应用的驱动Bug，人工操作，或者连接池本身的Bug。嫌疑最大的当然是手工操作，有人如果使用生产账号用psql连到连接池，手工修改了search_path，然后退出，这个连接就会被放回到生产池中，导致污染。

首先检查数据库日志，发现报错的日志记录全都来自同一条服务器连接5c06218b.2ca6c，即只有一条连接被污染。找到这条连接开始持续报错的临界时刻：

cat postgresql-Tue.csv | grep 5c06218b.2ca6c

2018-12-04 14:44:42.766 CST,"xxx","xxx-xxx",182892,"127.0.0.1:60114",5c06218b.2ca6c,36,"SELECT",2018-12-04 14:41:15 CST,24/0,0,LOG,00000,"duration: 1067.392 ms  statement: SELECT xxxx FROM x",,,,,,,,,"app - xx.xx.xx.xx:23962"

2018-12-04 14:45:03.857 CST,"xxx","xxx-xxx",182892,"127.0.0.1:60114",5c06218b.2ca6c,37,"SELECT",2018-12-04 14:41:15 CST,24/368400961,0,ERROR,42883,"function upsert_xxxxxx(xxx) does not exist",,"No function matches the given name and argument types. You might need to add explicit type casts.",,,,"select upsert_phone_plan('965+6628',1,0,0,0,1,0,'2018-12-03 19:00:00'::timestamp)",8,,"app - 10.191.160.49:46382"

这里5c06218b.2ca6c是该连接的唯一标识符，而后面的数字36,37则是该连接所产生日志的行号。一些操作并不会记录在日志中，但这里幸运的是，正常和出错的两条日志时间相差只有21秒，可以比较精确地定位故障时间点。

通过扫描所有白名单机器上该时刻的命令操作记录，精准定位到了一条执行记录：

pg_dump --host master.xxxx --port 6432 -d somedb -t sometable

嗯？pg_dump不是官方自带的工具吗，难道会修改search_path？不过直觉告诉我，还真不是没可能。例如我想起了一个有趣的行为，因为schema本质上是一个命名空间，因此位于不同schema内的对象可以有相同的名字。在老版本在使用-t转储特定表时，如果提供的表名参数不带schema前缀，pg_dump默认会默认转储所有同名的表。

查阅pg_dump的源码，发现还真有这种操作，以10.5版本为例，发现在setup_connection的时候，确实修改了search_path。

// src/bin/pg_dump/pg_dump.c line 287
int main(int argc, char **argv);

// src/bin/pg_dump/pg_dump.c line 681 main
setup_connection(fout, dumpencoding, dumpsnapshot, use_role);

// src/bin/pg_dump/pg_dump.c line 1006 setup_connection
PQclear(ExecuteSqlQueryForSingleRow(AH, ALWAYS_SECURE_SEARCH_PATH_SQL));

// include/server/fe_utils/connect.h
#define ALWAYS_SECURE_SEARCH_PATH_SQL \
   "SELECT pg_catalog.set_config('search_path', '', false)"

Bug复现

接下来就是复现该BUG了。但比较奇怪的是，在使用PostgreSQL11的时候并没能复现出该Bug来，于是我看了一下肇事司机的全部历史记录，还原了其心路历程（发现pg_dump和服务器版本不匹配，来回折腾），使用不同版本的pg_dump终于复现了该BUG。

使用一个现成的数据库，名为data进行测试，版本为11.1。使用的Pgbouncer配置如下，为了便于调试，连接池的大小已经改小，只允许两条服务端连接。

[databases]
postgres = host=127.0.0.1

[pgbouncer]
logfile = /Users/vonng/pgb/pgbouncer.log
pidfile = /Users/vonng/pgb/pgbouncer.pid
listen_addr = *
listen_port = 6432
auth_type = trust
admin_users = postgres
stats_users = stats, postgres
auth_file = /Users/vonng/pgb/userlist.txt
pool_mode = transaction
server_reset_query =
max_client_conn = 50000
default_pool_size = 2

reserve_pool_size = 0
reserve_pool_timeout = 5

log_connections = 1
log_disconnections = 1
application_name_add_host = 1

ignore_startup_parameters = extra_float_digits

启动连接池，检查search_path，正常的默认配置。

$ psql postgres://vonng:123456@:6432/data -c 'show search_path;'
     search_path
-----------------------
 app, "$user", public

使用10.5版本的pg_dump，从6432端口发起Dump

/usr/local/Cellar/postgresql/10.5/bin/pg_dump \
	postgres://vonng:123456@:6432/data \
	-t geo.pois -f /dev/null
pg_dump: server version: 11.1; pg_dump version: 10.5
pg_dump: aborting because of server version mismatch

虽然Dump失败，但再次检查所有连接的search_path时，就会发现池里的连接已经被污染了，一条连接的search_path已经被修改为空

$ psql postgres://vonng:123456@:6432/data -c 'show search_path;'
 search_path
-------------

(1 row)

解决方案

同时配置pgbouncer的server_reset_query以及server_reset_query_always参数，可以彻底解决此问题。

server_reset_query = DISCARD ALL
server_reset_query_always = 1

在TransactionPooling模式下，server_reset_query默认是不执行的，因此需要通过配置server_reset_query_always=1使每次事务执行完后强制执行DISCARD ALL清空连接的所有状态。不过，这样的配置是有代价的，DISCARD ALL实质上执行了以下操作：

SET SESSION AUTHORIZATION DEFAULT;
RESET ALL;
DEALLOCATE ALL;
CLOSE ALL;
UNLISTEN *;
SELECT pg_advisory_unlock_all();
DISCARD PLANS;
DISCARD SEQUENCES;
DISCARD TEMP;

如果每个事务后面都要多执行这些语句，确实会带来一些额外的性能开销。

当然，也有其他的方法，譬如从管理上解决，杜绝使用pg_dump访问6432端口的可能，将数据库账号使用专门的加密配置中心管理。或者要求业务方使用带schema限定名的name访问数据库对象。但都可能产生漏网之鱼，不如强制配置来的直接。

微信公众号原文

PostgreSQL数据页面损坏修复

采用二进制编辑的方式修复PostgreSQL数据页，以及如何让一条主键查询出现两条记录来。

著： 冯若航（@Vonng） | 2018-11-29

PostgreSQL是一个很可靠的数据库，但是再可靠的数据库，如果碰上了不可靠的硬件，恐怕也得抓瞎。本文介绍了在PostgreSQL中，应对数据页面损坏的方法。

最初的问题

线上有一套统计库跑离线任务，业务方反馈跑SQL的时候碰上一个错误：

ERROR:  invalid page in block 18858877 of relation base/16400/275852

看到这样的错误信息，第一直觉就是硬件错误导致的关系数据文件损坏，第一步要检查定位具体问题。

这里，16400是数据库的oid，而275852则是数据表的relfilenode，通常等于OID。

somedb=# select 275852::RegClass;
      regclass
---------------------
 dailyuseractivities
 
-- 如果relfilenode与oid不一致，则使用以下查询
somedb=# select relname from pg_class where pg_relation_filenode(oid) = '275852';
       relname
---------------------
 dailyuseractivities
(1 row)

定位到出问题的表之后，检查出问题的页面，这里错误提示区块号为18858877的页面出现问题。

somedb=# select * from dailyuseractivities where ctid = '(18858877,1)';
ERROR:  invalid page in block 18858877 of relation base/16400/275852

-- 打印详细错误位置
somedb=# \errverbose
ERROR:  XX001: invalid page in block 18858877 of relation base/16400/275852
LOCATION:  ReadBuffer_common, bufmgr.c:917

通过检查，发现该页面无法访问，但该页面前后两个页面都可以正常访问。使用errverbose可以打印出错误所在的源码位置。搜索PostgreSQL源码，发现这个错误信息只在一处位置出现：https://github.com/postgres/postgres/blob/master/src/backend/storage/buffer/bufmgr.c。可以看到，错误发生在页面从磁盘加载到内存共享缓冲区时。PostgreSQL认为这是一个无效的页面，因此报错并中止事务。

/* check for garbage data */
if (!PageIsVerified((Page) bufBlock, blockNum))
{
    if (mode == RBM_ZERO_ON_ERROR || zero_damaged_pages)
    {
        ereport(WARNING,
                (errcode(ERRCODE_DATA_CORRUPTED),
                 errmsg("invalid page in block %u of relation %s; zeroing out page",
                        blockNum,
                        relpath(smgr->smgr_rnode, forkNum))));
        MemSet((char *) bufBlock, 0, BLCKSZ);
    }
    else
        ereport(ERROR,
                (errcode(ERRCODE_DATA_CORRUPTED),
                 errmsg("invalid page in block %u of relation %s",
                        blockNum,
                        relpath(smgr->smgr_rnode, forkNum))));
}

进一步检查PageIsVerified函数的逻辑：

/* 这里的检查并不能保证页面首部是正确的，只是说它看上去足够正常
 * 允许其加载至缓冲池中。后续实际使用该页面时仍然可能会出错，这也
 * 是我们提供校验和选项的原因。*/

if ((p->pd_flags & ~PD_VALID_FLAG_BITS) == 0 &&
    p->pd_lower <= p->pd_upper &&
    p->pd_upper <= p->pd_special &&
    p->pd_special <= BLCKSZ &&
    p->pd_special == MAXALIGN(p->pd_special))
    header_sane = true;

if (header_sane && !checksum_failure)
    return true;

接下来就要具体定位问题了，那么第一步，首先要找到问题页面在磁盘上的位置。这其实是两个子问题：在哪个文件里，以及在文件里的偏移量地址。这里，关系文件的relfilenode是275852，在PostgreSQL中，每个关系文件都会被默认切割为1GB大小的段文件，并用relfilenode, relfilenode.1, relfilenode.2, …这样的规则依此命名。

因此，我们可以计算一下，第18858877个页面，每个页面8KB，一个段文件1GB。偏移量为18858877 * 2^13 = 154491920384。

154491920384 / (1024^3) = 143
154491920384 % (1024^3) = 946839552 = 0x386FA000

由此可得，问题页面位于第143个段内，偏移量0x386FA000处。

落实到具体文件，也就是${PGDATA}/base/16400/275852.143。

hexdump 275852.143 | grep -w10 386fa00

386f9fe0 003b 0000 0100 0000 0100 0000 4b00 07c8
386f9ff0 9b3d 5ed9 1f40 eb85 b851 44de 0040 0000
386fa000 0000 0000 0000 0000 0000 0000 0000 0000
*
386fb000 62df 3d7e 0000 0000 0452 0000 011f c37d
386fb010 0040 0003 0b02 0018 18f6 0000 d66a 0068

使用二进制编辑器打开并定位至相应偏移量，发现该页面的内容已经被抹零，没有抢救价值了。好在线上的数据库至少都是一主一从配置，如果是因为主库上的坏块导致的页面损坏，从库上应该还有原来的数据。在从库上果然能找到对应的数据：

386f9fe0:3b00 0000 0001 0000 0001 0000 004b c807  ;............K..
386f9ff0:3d9b d95e 401f 85eb 51b8 de44 4000 0000  =..^@...Q..D@...
386fa000:e3bd 0100 70c8 864a 0000 0400 f801 0002  ....p..J........
386fa010:0020 0420 0000 0000 c09f 7a00 809f 7a00  . . ......z...z.
386fa020:409f 7a00 009f 7a00 c09e 7a00 809e 7a00  @.z...z...z...z.
386fa030:409e 7a00 009e 7a00 c09d 7a00 809d 7a00  @.z...z...z...z.

当然，如果页面是正常的，在从库上执行读取操作就不会报错。因此可以直接通过CTID过滤把损坏的数据找回来。

到现在为止，数据虽然找回来，可以松一口气了。但主库上的坏块问题仍然需要处理，这个就比较简单了，直接重建该表，并从从库抽取最新的数据即可。有各种各样的方法，VACUUM FULL，pg_repack，或者手工重建拷贝数据。

不过，我注意到在判定页面有效性的代码中出现了一个从来没见过的参数zero_damaged_pages，查阅文档才发现，这是一个开发者调试用参数，可以允许PostgreSQL忽略损坏的数据页，将其视为全零的空页面。用WARNING替代ERROR。这引发了我的兴趣。毕竟有时候，对于一些粗放的统计业务，跑了几个小时的SQL因为一两条脏数据中断，恐怕要比错漏那么几条记录更令人抓狂。这个参数可不可以满足这样的需求呢？

zero_damaged_pages (boolean)

PostgreSQL在检测到损坏的页面首部时通常会报告一个错误，并中止当前事务。将参数zero_damaged_pages配置为on，会使系统取而代之报告一个WARNING，并将内存中的页面抹为全零。然而该操作会摧毁数据，也就是说损坏页面上的行全都会丢失。不过，这样做确实能允许你略过错误并从未损坏的页面中获取表中未受损的行。当出现软件或硬件导致的数据损坏时，该选项可用于恢复数据。通常情况下只有当您放弃从受损的页面中恢复数据时，才应当使用该选项。抹零的页面并不会强制刷回磁盘，因此建议在重新关闭该选项之前重建受损的表或索引。本选项默认是关闭的，且只有超级用户才能修改。

毕竟，当重建表之后，原来的坏块就被释放掉了。如果硬件本身没有提供坏块识别与筛除的功能，那么这就是一个定时炸弹，很可能将来又会坑到自己。不幸的是，这台机器上的数据库有14TB，用的16TB的SSD，暂时没有同类型的机器了。只能先苟一下，因此需要研究一下，这个参数能不能让查询在遇到坏页时自动跳过。

苟且的办法

如下，在本机搭建一个测试集群，配置一主一从。尝试复现该问题，并确定

# tear down
pg_ctl -D /pg/d1 stop
pg_ctl -D /pg/d2 stop
rm -rf /pg/d1 /pg/d2

# master @ port5432
pg_ctl -D /pg/d1 init
pg_ctl -D /pg/d1 start
psql postgres -c "CREATE USER replication replication;"

# slave @ port5433
pg_basebackup -Xs -Pv -R -D /pg/d2 -Ureplication 
pg_ctl -D /pg/d2 start -o"-p5433"

连接至主库，创建样例表并插入555条数据，约占据三个页面。

-- psql postgres
DROP TABLE IF EXISTS test;
CREATE TABLE test(id varchar(8) PRIMARY KEY);
ANALYZE test;

-- 注意，插入数据之后一定要执行checkpoint确保落盘
INSERT INTO test SELECT generate_series(1,555)::TEXT;
CHECKPOINT;

现在，让我们模拟出现坏块的情况，首先找出主库中test表的对应文件。

SELECT pg_relation_filepath(oid) FROM pg_class WHERE relname = 'test';

base/12630/16385

$ hexdump /pg/d1/base/12630/16385 | head -n 20
0000000 00 00 00 00 d0 22 02 03 00 00 00 00 a0 03 c0 03
0000010 00 20 04 20 00 00 00 00 e0 9f 34 00 c0 9f 34 00
0000020 a0 9f 34 00 80 9f 34 00 60 9f 34 00 40 9f 34 00
0000030 20 9f 34 00 00 9f 34 00 e0 9e 34 00 c0 9e 36 00
0000040 a0 9e 36 00 80 9e 36 00 60 9e 36 00 40 9e 36 00
0000050 20 9e 36 00 00 9e 36 00 e0 9d 36 00 c0 9d 36 00
0000060 a0 9d 36 00 80 9d 36 00 60 9d 36 00 40 9d 36 00
0000070 20 9d 36 00 00 9d 36 00 e0 9c 36 00 c0 9c 36 00

上面已经给出了PostgreSQL判断页面是否“正常”的逻辑，这里我们就修改一下数据页面，让页面变得“不正常”。页面的第12~16字节，也就是这里第一行的最后四个字节a0 03 c0 03，是页面内空闲空间上下界的指针。这里按小端序解释的意思就是本页面内，空闲空间从0x03A0开始，到0x03C0结束。符合逻辑的空闲空间范围当然需要满足上界小于等于下界。这里我们将上界0x03A0修改为0x03D0，超出下界0x03C0，也就是将第一行的倒数第四个字节由A0修改为D0。

# vim打开后使用 :%!xxd 编辑二进制
# 编辑完成后使用 :%!xxd -r转换回二进制，再用:wq保存
vi /pg/d1/base/12630/16385

# 查看修改后的结果。
$ hexdump /pg/d1/base/12630/16385 | head -n 2
0000000 00 00 00 00 48 22 02 03 00 00 00 00 d0 03 c0 03
0000010 00 20 04 20 00 00 00 00 e0 9f 34 00 c0 9f 34 00

这里，虽然磁盘上的页面已经被修改，但页面已经缓存到了内存中的共享缓冲池里。因此从主库上仍然可以正常看到页面1中的结果。接下来重启主库，清空其Buffer。不幸的是，当关闭数据库或执行检查点时，内存中的页面会刷写会磁盘中，覆盖我们之前编辑的结果。因此，首先关闭数据库，重新执行编辑后再启动。

pg_ctl -D /pg/d1 stop
vi /pg/d1/base/12630/16385
pg_ctl -D /pg/d1 start

psql postgres -c 'select * from test;'
ERROR:  invalid page in block 0 of relation base/12630/16385

psql postgres -c "select * from test where id = '10';"
ERROR:  invalid page in block 0 of relation base/12630/16385

psql postgres -c "select * from test where ctid = '(0,1)';"
ERROR:  invalid page in block 0 of relation base/12630/16385

$ psql postgres -c "select * from test where ctid = '(1,1)';"
 id
-----
 227

可以看到，修改后的0号页面无法被数据库识别出来，但未受影响的页面1仍然可以正常访问。

虽然主库上的查询因为页面损坏无法访问了，这时候在从库上执行类似的查询，都可以正常返回结果

$ psql -p5433 postgres -c 'select * from test limit 2;'
 id
----
 1
 2

$ psql -p5433 postgres -c "select * from test where id = '10';"
 id
----
 10

$ psql -p5433 postgres -c "select * from test where ctid = '(0,1)';"
 id
----
 1
(1 row)

接下来，让我们打开zero_damaged_pages参数，现在在主库上的查询不报错了。取而代之的是一个警告，页面0中的数据蒸发掉了，返回的结果从第1页开始。

postgres=# set zero_damaged_pages = on ;
SET
postgres=# select * from test;
WARNING:  invalid page in block 0 of relation base/12630/16385; zeroing out page
 id
-----
 227
 228
 229
 230
 231

第0页确实已经被加载到内存缓冲池里了，而且页面里的数据被抹成了0。

create extension pg_buffercache ;

postgres=# select relblocknumber,isdirty,usagecount from pg_buffercache where relfilenode = 16385;
 relblocknumber | isdirty | usagecount
----------------+---------+------------
              0 | f       |          5
              1 | f       |          3
              2 | f       |          2

zero_damaged_pages参数需要在实例级别进行配置：

# 确保该选项默认打开，并重启生效
psql postgres -c 'ALTER SYSTEM set zero_damaged_pages = on;'
pg_ctl -D /pg/d1 restart
psql postgres -c 'show zero_damaged_pages;'

zero_damaged_pages
--------------------
 on

这里，通过配置zero_damaged_pages，能够让主库即使遇到坏块，也能继续应付一下。

垃圾页面被加载到内存并抹零之后，如果执行检查点，这个全零的页面是否又会被重新刷回磁盘覆盖原来的数据呢？这一点很重要，因为脏数据也是数据，起码有抢救的价值。为了一时的方便产生永久性无法挽回的损失，那肯定也是无法接受的。

psql postgres -c 'checkpoint;'
hexdump /pg/d1/base/12630/16385 | head -n 2
0000000 00 00 00 00 48 22 02 03 00 00 00 00 d0 03 c0 03
0000010 00 20 04 20 00 00 00 00 e0 9f 34 00 c0 9f 34 00

可以看到，无论是检查点还是重启，这个内存中的全零页面并不会强制替代磁盘上的损坏页面，留下了抢救的希望，又能保证线上的查询可以苟一下。甚好，甚好。这也符合文档中的描述：“抹零的页面并不会强制刷回磁盘”。

微妙的问题

就当我觉得实验完成，可以安心的把这个开关打开先对付一下时。突然又想起了一个微妙的事情，主库和从库上读到的数据是不一样的，这就很尴尬了。

psql -p5432 postgres -Atqc 'select * from test limit 2;'
2018-11-29 22:31:20.777 CST [24175] WARNING:  invalid page in block 0 of relation base/12630/16385; zeroing out page
WARNING:  invalid page in block 0 of relation base/12630/16385; zeroing out page
227
228

psql -p5433 postgres -Atqc 'select * from test limit 2;'
1
2

更尴尬的是，在主库上是看不到第0页中的元组的，也就是说主库认为第0页中的记录都不存在，因此，即使表上存在主键约束，仍然可以插入同一个主键的记录：

# 表中已经有主键 id = 1的记录了，但是主库抹零了看不到！
psql postgres -c "INSERT INTO test VALUES(1);"
INSERT 0 1

# 从从库上查询，夭寿了！主键出现重复了！
psql postgres -p5433 -c "SELECT * FROM test;"

 id
-----
 1
 2
 3
...
 555
 1
 
# id列真的是主键……
$ psql postgres -p5433 -c "\d test;"
                      Table "public.test"
 Column |         Type         | Collation | Nullable | Default
--------+----------------------+-----------+----------+---------
 id     | character varying(8) |           | not null |
Indexes:
    "test_pkey" PRIMARY KEY, btree (id)

如果把这个从库Promote成新的主库，这个问题在从库上依然存在：一条主键能返回两条记录！真是夭寿啊……。

此外，还有一个有趣的问题，VACUUM会如何处理这样的零页面呢？


# 对表进行清理
psql postgres -c 'VACUUM VERBOSE;'

INFO:  vacuuming "public.test"
2018-11-29 22:18:05.212 CST [23572] WARNING:  invalid page in block 0 of relation base/12630/16385; zeroing out page
2018-11-29 22:18:05.212 CST [23572] WARNING:  relation "test" page 0 is uninitialized --- fixing
WARNING:  invalid page in block 0 of relation base/12630/16385; zeroing out page
WARNING:  relation "test" page 0 is uninitialized --- fixing
INFO:  index "test_pkey" now contains 329 row versions in 5 pages
DETAIL:  0 index row versions were removed.
0 index pages have been deleted, 0 are currently reusable.
CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s.

VACUUM把这个页面“修好了”？但杯具的是，VACUUM自作主张修好了脏数据页，并不一定是一件好事…。因为当VACUUM完成修复时，这个页面就被视作一个普通的页面了，就会在CHECKPOINT时被刷写回磁盘中……，从而覆盖了原始的脏数据。如果这种修复并不是你想要的结果，那么数据就有可能会丢失。

总结

复制，备份是应对硬件损坏的最佳办法。
当出现数据页面损坏时，可以找到对应的物理页面，进行比较，尝试修复。
当页面损坏导致查询无法进行时，参数zero_damaged_pages可以临时用于跳过错误。
参数zero_damaged_pages极其危险
打开抹零时，损坏页面会被加载至内存缓冲池中并抹零，且在检查点时不会覆盖磁盘原页面。
内存中被抹零的页面会被VACUUM尝试修复，修复后的页面会被检查点刷回磁盘，覆盖原页面。
抹零页面内的内容对数据库不可见，因此可能会出现违反约束的情况出现。

微信公众号原文地址

故障档案：PostgreSQL事务号回卷

XID WrapAround也许是PostgreSQL特有的一种故障

著： 冯若航（@Vonng） | 2018-07-20

遇到一次磁盘坏块导致的事务回卷故障：

主库（PostgreSQL 9.3）磁盘坏块导致几张表上的VACUUM FREEZE执行失败。
无法回收老旧事务ID，导致整库事务ID濒临用尽，数据库进入自我保护状态不可用。
磁盘坏块导致手工VACUUM抢救不可行。
提升从库后，需要紧急VACUUM FREEZE才能继续服务，进一步延长了故障时间。
主库进入保护状态后提交日志（clog）没有及时复制到从库，从库产生存疑事务拒绝服务。

摘要

这是一个即将下线老旧库，疏于管理。坏块征兆在一周前就已经出现，没有及时跟进年龄。
通常AutoVacuum会保证很难出现这种故障，但一旦出现往往意味着祸不单行…让救火更加困难了……

背景

PostgreSQL实现了快照隔离（Snapshot Isolation），每个事务开始时都能获取数据库在该时刻的快照（也就是只能看到过去事务提交的结果，看不见后续事务提交的结果）。这一强大的功能是通过MVCC实现的，但也引入了额外复杂度，例如事务ID回卷问题。

事务ID（xid）是用于标识事务的32位无符号整型数值，递增分配，其中值0,1,2为保留值，溢出后回卷为3重新开始。事务ID之间的大小关系决定了事务的先后顺序。

/*
 * TransactionIdPrecedes --- is id1 logically < id2?
 */
bool
TransactionIdPrecedes(TransactionId id1, TransactionId id2)
{
	/*
	 * If either ID is a permanent XID then we can just do unsigned
	 * comparison.  If both are normal, do a modulo-2^32 comparison.
	 */
	int32		diff;

	if (!TransactionIdIsNormal(id1) || !TransactionIdIsNormal(id2))
		return (id1 < id2);

	diff = (int32) (id1 - id2);
	return (diff < 0);
}

xid-wrap-around

可以将xid的取值域视为一个整数环，但刨除0,1,2三个特殊值。0代表无效事务ID，1代表系统事务ID，2代表冻结事务ID。特殊的事务ID比任何普通事务ID小。而普通事务ID之间的比较可参见上图：它取决于两个事务ID的差值是否超出INT32_MAX。对任意一个事务ID，都有约21亿个位于过去的事务和21亿个位于未来的事务。

xid不仅仅存在于活跃的事务上，xid会影响所有的元组：事务会给自己影响的元组打上自己的xid作为记号。每个元组都会用(xmin, xmax)来标识自己的可见性，xmin 记录了最后写入（INSERT, UPDATE）该元组的事务ID，而xmax记录了删除或锁定该元组的事务ID。每个事务只能看见由先前事务提交（xmin < xid）且未被删除的元组（从而实现快照隔离）。

如果一个元组是由很久很久以前的事务产生的，那么在数据库的例行VACUUM FREEZE时，会找出当前活跃事务中最老的xid，将所有xmin < xid的元组的xmin标记为2，也就是冻结事务ID。这意味着这条元组跳出了这个比较环，比所有普通事务ID都要小，所以能被所有的事务看到。通过清理，数据库中最老的xid会不断追赶当前的xid，从而避免事务回卷。

数据库或表的年龄（age），定义为当前事务ID与数据库/表中存在最老的xid之差。最老的xid可能来自一个持续了几天的超长事务。也可能来自几天前老事务写入，但尚未被冻结的元组中。如果数据库的年龄超过了INT32_MAX，灾难性情况就发生了。过去的事务变成了未来的事务，过去事务写入的元组将变得不可见。

为了避免这种情况，需要避免超长事务与定期VACUUM FREEZE冻结老元组。如果单库在平均3万TPS的超高负载下，20亿个事务号一整天内就会用完。在这样的库上就无法执行一个超过一天的超长事务。而如果由于某种原因，自动清理工作无法继续进行，一天之内就可能遇到事务回卷。

9.4之后对FREEZE的机制进行了修改，FREEZE使用元组中单独的标记位来表示。

PostgreSQL应对事务回卷有自我保护机制。当临界事务号还剩一千万时，会进入紧急状态。

查询

查询当前所有表的年龄，SQL 语句如下：

SELECT c.oid::regclass as table_name,
     greatest(age(c.relfrozenxid),age(t.relfrozenxid)) as age
FROM pg_class c
LEFT JOIN pg_class t ON c.reltoastrelid = t.oid
WHERE c.relkind IN ('r', 'm') order by 2 desc;

查询数据库的年龄，SQL语句如下：

SELECT *, age(datfrozenxid) FROM pg_database;

清理

执行VACUUM FREEZE可以冻结老旧事务的ID

set vacuum_cost_limit = 10000;
set vacuum_cost_delay = 0;

VACUUM FREEZE VERBOSE;

可以针对特定的表进行VACUUM FREEZE，抓主要矛盾。

问题

通常来说，PostgreSQL的AutoVacuum机制会自动执行FREEZE操作，冻结老旧事务的ID，从而降低数据库的年龄。因此一旦出现事务ID回卷故障，通常祸不单行，意味着vacuum机制可能被其他的故障挡住了。

目前遇到过三种触发事务ID回卷故障的情况

IDLE IN TRANSACTION

空闲事务会阻塞VACUUM FREEZE老旧元组。

解决方法很简单，干掉IDEL IN TRANSACTION的长事务然后执行VACUUM FREEZE即可。

存疑事务

clog损坏，或没有复制到从库，会导致相关表进入事务存疑状态，拒绝服务。

需要手工拷贝，或使用dd生成虚拟的clog来强行逃生。

磁盘/内存坏块

因为坏块导致的无法VACUUM比较尴尬。

需要通过二分法定位并跳过脏数据，或者干脆直接抢救从库。

注意事项

紧急抢救的时候，不要整库来，按照年龄大小降序挨个清理表会更快。

注意当主库进入事务回卷保护状态时，从库也会面临同样的问题。

解决方案

AutoVacuum参数配置

年龄监控

[未完待续]

故障档案：序列号消耗过快导致整型溢出

如果您在表上用了Interger的序列号，最好还是考虑一下可能溢出的情况。

著： 冯若航（@Vonng） | 2018-07-20

0x01 概览

故障表现：
- 某张使用自增列的表序列号涨至整型上限，无法写入。
- 发现表中的自增列存在大量空洞，很多序列号没有对应记录就被消耗掉了。
故障影响：非核心业务某表，10分钟左右无法写入。
故障原因：
- 内因：使用了INTEGER而不是BIGINT作为主键类型。
- 外因：业务方不了解SEQUENCE的特性，执行大量违背约束的无效插入，浪费了大量序列号。
修复方案：
- 紧急操作：降级线上插入函数为直接返回，避免错误扩大。
- 应急方案：创建临时表，生成5000万个浪费空洞中的临时ID，修改插入函数，变为先检查再插入，并从该临时ID表中取ID。
- 解决方案：执行模式迁移，将所有相关表的主键与外键类型更新为Bigint。

原因分析

内因：类型使用不当

业务使用32位整型作为主键自增ID，而不是Bigint。

除非有特殊的理由，主键，自增列都应当使用BIGINT类型。

外因：不了解Sequence的特性

非要使用如果会频繁出现无效插入，或频繁使用UPSERT，需要关注Sequence的消耗问题。
可以考虑使用自定义发号函数（类Snowflake）

在PostgreSQL中，Sequence是一个比较特殊的类型。特别是，在事务中消耗的序列号不会回滚。因为序列号能被并发地获取，不存在逻辑上合理的回滚操作。

在生产中，我们就遇到了这样一种故障。有一张表直接使用了Serial作为主键：

CREATE TABLE sample(
	id   	SERIAL PRIMARY KEY,
	name  	TEXT UNIQUE,
    value   INTEGER
);

而插入的时候是这样的：

INSERT INTO sample(name, value) VALUES(?,?)

当然，实际上由于name列上的约束，如果插入了重复的name字段，事务就会报错中止并回滚。然而序列号已经被消耗掉了，即使事务回滚了，序列号也不会回滚。

vonng=# INSERT INTO sample(name, value) VALUES('Alice',1);
INSERT 0 1
vonng=# SELECT currval('sample_id_seq'::RegClass);
 currval
---------
       1
(1 row)

vonng=# INSERT INTO sample(name, value) VALUES('Alice',1);
ERROR:  duplicate key value violates unique constraint "sample_name_key"
DETAIL:  Key (name)=(Alice) already exists.
vonng=# SELECT currval('sample_id_seq'::RegClass);
 currval
---------
       2
(1 row)

vonng=# BEGIN;
BEGIN
vonng=# INSERT INTO sample(name, value) VALUES('Alice',1);
ERROR:  duplicate key value violates unique constraint "sample_name_key"
DETAIL:  Key (name)=(Alice) already exists.
vonng=# ROLLBACK;
ROLLBACK
vonng=# SELECT currval('sample_id_seq'::RegClass);
 currval
---------
       3

因此，当执行的插入有大量重复，即有大量的冲突时，可能会导致序列号消耗的非常快。出现大量空洞！

另一个需要注意的点在于，UPSERT操作也会消耗序列号！从表现上来看，这就意味着即使实际操作是UPDATE而不是INSERT，也会消耗一个序列号。

vonng=# INSERT INTO sample(name, value) VALUES('Alice',3) ON CONFLICT(name) DO UPDATE SET value = EXCLUDED.value;
INSERT 0 1
vonng=# SELECT currval('sample_id_seq'::RegClass);
 currval
---------
       4
(1 row)

vonng=# INSERT INTO sample(name, value) VALUES('Alice',4) ON CONFLICT(name) DO UPDATE SET value = EXCLUDED.value;
INSERT 0 1
vonng=# SELECT currval('sample_id_seq'::RegClass);
 currval
---------
       5
(1 row)

解决方案

线上所有查询与插入都使用存储过程。非核心业务，允许接受短暂的写入失效。首先降级插入函数，避免错误影响AppServer。因为该表存在大量依赖，无法直接修改其类型，需要一个临时解决方案。

检查发现ID列中存在大量空洞，每10000个序列号中实际只有1%被使用。因此使用下列函数生成临时ID表。

CREATE TABLE sample_temp_id(id INTEGER PRIMARY KEY);

-- 插入约5000w个临时ID，够用十几天了。
INSERT INTO sample_temp_id
SELECTT generate_series(2000000000,2100000000) as id EXCEPT SELECT id FROM sample;

-- 修改插入的存储过程，从临时表中Pop出ID。
DELETE FROM sample_temp_id WHERE id = (SELECT id FROM sample_temp_id FOR UPDATE LIMIT 1) RETURNING id;

修改插入存储过程，每次从临时ID表中取一个ID，显式插入表中。

经验与教训

故障档案:移除负载导致过载

最近发生了一起匪夷所思的故障，某数据库切走了一半的数据量和负载，结果却因为负载变大被打挂了。

著： 冯若航（@Vonng） | 2018-04-08

最近发生了一起匪夷所思的故障，某数据库切走了一半的数据量和负载。

其他什么都没变，本来还好；压力减小，却在高峰期陷入濒死状态，完全不符合直觉。

但正如福尔摩斯所说，当你排除掉一切不可能之后，剩下的即使再离奇，也是事实。

一、摘要

某日凌晨4点，进行了核心库进行分库迁移，拆走一半的表和一半的查询负载，原库节点规模不变。

当日晚高峰核心库所有热备库（15台）出现连接堆积，压力暴涨，针对性地清理慢查询不再起效。

无差别持续杀查询，有立竿见影的救火效果（22:30后），且暂停后故障立刻重现（22:48），杀至高峰期结束。

匪夷所思的是，移走了表（数据量减半），移走了负载（TPS减半），其他什么都没变竟然会导致压力上升？

二、现象

CPU使用率的正常水位在25%，警戒水位在45%，极限水位在80%。故障期间所有从库飙升至极限水位。

PostgreSQL连接数发生暴涨，通常5~10个左右的数据库连接就足够撑起所有流量，连接池的最大连接数为100。

pg-conn

pgbouncer连接池平均响应时间平时在500μs左右，故障期间飙升至百毫秒级别。

pgb-time

故障期间，数据库TPS发生显著下滑。进行杀查询抢救后恢复，但处于剧烈抖动状态。

故障期间，两个函数的执行时间发生显著恶化，从几百微秒劣化至几十毫秒。

故障期间，复制延迟显著上升，开始出现GB级别的复制延迟，业务指标出现显著下滑。

开始杀查询后，大部分指标恢复，但一旦停止马上重新开始出现（22:48尝试性停止故障恢复）。

三、原因分析

【表因】：所有从库连接池被打满，连接被慢查询占据，快查询无法执行，发生连接堆积。

【主内因】：两个函数的并发数增大到30左右时，性能会发生急剧劣化，变为慢查询（500μs到100ms）。

【副内因】：后端与数据库没有合理的超时取消机制，断路器会放大故障。

【外因】：分库后，快查询比例下降，导致特定查询的相对比例上升，并发数增大至临界点。恶化为慢查询。

表因：连接打满

故障的表因是数据库连接池被打满，产生大量堆积连接。进而新连接无法建立，拒绝服务。

原理

数据库配置的最大连接数max_connections = 100，一个连接实质上就是一个数据库进程。机器能够负载的实际数据库进程数目与查询类型高度相关：如果全是在1ms内的快查询，几百上千个链接都是可以的（生产环境中的正常情况）。而如果全都是CPU和IO密集的慢查询，则最大支持的连接数可能只有（48 * 80% ≈ 38）个左右。

在生产环境中使用了连接池，正常情况下5~10个实际数据库连接就可以支撑起所有快查询。然而一旦有大量慢查询持续进入，长期占用了活跃连接，那么快查询就会排队等待发生堆积，连接池进而启动更多实际数据库的连接，而这些连接上的快查询很快就会执行完毕，最终仍然会被不断进入的慢查询占据。最终导致约100个实际数据库连接都在执行CPU/IO密集的慢查询（max_pool_size=100），CPU暴涨，进一步恶化情况。

证据

连接池活跃连接数

pgb-active-conn-5888653

连接池排队连接数

pgb-wait-conn

数据库后端连接数

pg-conn

修复

持续地无差别杀掉所有数据库活跃连接，能起到很好的治标效果，且对业务指标影响很小。

但杀掉连接（pg_terminate_backend）会导致连接池重连，更好的做法是取消查询（pg_cancel_backend）

因为快查询走的快，卡在后端实际连接上执行的查询极大概率都是慢查询，这时候无差别取消所有查询命中的绝大多数都是慢查询。杀查询能将连接释放给快查询使用，让应用苟活下去，但必须持续不断的杀才有效果，因为用不了零点几秒，慢查询就会重新占据活跃连接。

使用psql执行以下SQL，每隔0.5秒取消所有活跃查询。

SELECT pg_cancel_backend(pid) FROM pg_stat_activity WHERE application_name != 'psql' \watch 0.5

解决方案：调整了连接池的后端最大连接数，进行快慢分离，强制所有批量任务与慢查询走离线从库。

主内因：并行恶化

故障的主内因是两个函数的执行时间在并行数增大时发生恶化。

原理

故障的直接导火索是这两个函数劣化为慢查询。经过单独的压力测试，这两个函数随着并行执行数增高，发生急剧的性能劣化，阈值点为约30个并发进程。（因为所有进程只执行同一个查询，所以可认为并行数等于并发数）

证据

图：故障期间函数平均执行时间出现明显飙升

图：在不同并行数下压测该函数能达到的最大QPS

degenerate-5889931

修复

优化函数执行逻辑，将该函数的执行时间优化至原来的一半（最大QPS翻倍）。
新增五台从库，进一步降低单机负载。

副内因：没有超时

故障的副内因在于没有合理的超时取消机制，查询不会因为超时被取消，是发生堆积的必要条件。

原理

发生查询超时时，应用层的合理行为是

直接返回，报错。
进行若干次重试（在高峰期可以考虑直接返回错误）

查询等待超出合理范围的时间却不取消，就会导致连接堆积。抛弃返回结果并无法取消已经发出的查询，客户端需要主动Cancel Request。Go1.7后的标准实践是通过context包与database/sql提供的QueryContext/ExecContext进行超时控制。

数据库端和连接池端可以配置语句超时(statement_timeout)，但实践表明这样的操作很容易误杀查询。

手动杀灭能够立竿见影地治标，但它本质上是一种人工超时取消机制。稳健的系统应当有自动化的超时取消机制，这需要在数据库、连接池、应用多个层次协同解决。

检视后端使用的驱动代码，发现pg.v3 pg.v5并没有真正意义上的查询超时机制，超时参数不过是为net.Conn加上的TCP超时（通常在分钟级别）。

修复

建议使用github.com/jackc/pgx与 github.com/go-pg/pg 第六版驱动替代现有驱动
使用circuit-breaker会导致故障效应被放大，建议后端使用主动超时替代断路器。
建议在应用层面对连接的使用进行更精细的控制。

外因：分库迁移

分库导致了原库中的快慢查询比例发生变化，诱发了两个函数的劣化。

问题函数在迁移前后的全局调用次数占比由1/6 变为1/2，导致问题函数的并行数增大。

原理

迁走的函数全都是快查询，原本问题函数：普通函数的比例为1：5
迁移负载后，快查询迁走了大半。问题函数：普通函数超过1：1
问题函数的比例大幅升高，导致高峰期其并发数超出阈值点，出现劣化。

证据

通过分析分库迁移前后的数据库全量日志，回放查询流量进行压测，重现了现象，确认了问题原因。

指标	迁移前	迁移后
问题函数占比	1/6	5/9
最大QPS	40k	8k

QPS/TPS是一个极具误导性的指标，只有在负载类型不变的清空下，比较QPS才有意义。当系统负载类型发生变化时，QPS的水位点也需要重新进行评估测试。

在本例中，在负载变化后，系统的最大QPS水位点已经发生了戏剧性的变化，因为问题函数并发劣化，最大QPS变为原来的五分之一。

修复

对问题函数进行了改写优化，提高了一倍的性能。

通过测试，确定了迁移后的系统水位值，并进行了相应的优化与容量调整。

四、经验与教训

在故障排查中，走了一些弯路。比如一开始认为是某个离线批量任务拖慢了查询（根据日志中观察到的前后相关性），也排查了API调用量突增，外部恶意访问，其他变更因素，未知线上操作等。虽然分库迁移被列入怀疑对象，但因为直觉上认为负载小了，系统的Capacity怎么可能会下降？就没有列为优先排查对象。现实马上就给我们上了一课：

当你排除掉一切不可能之后，剩下的即使再离奇，也是事实。

原理

关于PostgreSQL的内部原理

2019-06-01

购买《PG Internal》

关于PostgreSQL内核的一本书

2019-05-31

点击下面的图片前往京东购买《PostgreSQL指南：内幕探索》(博文视点出品) [The Internals of PostgreSQL for Database Administr]

作者序

《PG Internal译者序》

著： 鈴木啓修（Hironobu Suzuki） | 2019-06-01

序

中国的PostgreSQL用户们，你们好！

本书详细解释了PostgreSQL的内部工作细节，目标读者为DBA与系统开发人员。理解数据库内部机制很有挑战，愿本书能在您精通PostgreSQL的道路上有所助益。

本书能出中文版，我真的感到非常高兴，我这样认为是有原因的。

这是我的书中，第一本被翻译成外语的。当自己的书出版时，心情愉悦自不必说，而自己的一部作品能翻译成外语出版，更是一件非常令人激动的事情。

首先, 这是我翻译的第一本书。不用说, 当我的一本书出版的时候, 总是让人高兴的。此外, 让我的一部作品翻译成外语是一件非常令人激动的事情。

其次，我收到了来自世界各地的电子邮件，请求将这本书翻译成各种外语。实际上，至少有一半的邮件来自中国。许多邮件跟我说”这本书对中国PostgreSQL用户很有必要“，因此，我很高兴终于能对他们的要求作出回应。

而最重要的原因与我的家族史有关。先父于多年前去世，他在中国的哈尔滨住过好几年。此后他回到日本，而我出生了。他患心脏病已经很长时间了，因此脾气很差。我对他的印象很差，除了一件事。当我还是孩子的时候，父亲每晚睡觉前都会给我和妹妹讲他在中国的经历。在讲这些时，他总是显得非常高兴，经常说中国人民帮助了他。

他的故事给我留下了深刻的印象，当然也影响了我的人生。因为这些故事，我从小就对这个世界和未知的事物有强烈的好奇心，而我的好奇心也引领我走向软件工程的道路。而现在，我已经在中国出版了我的第一本书。简而言之，这是一个关于日本家庭与中国之间让爱接力传递的故事。

我很高兴终于能把这份情还给中国人民了。当然，这本书是一份很小的礼物。然而，我愿充满感激之情地将它献给您。

2017年，我有幸访问中国，亲眼目睹了中国令人惊叹的发展。对我而言，这是一次非常难忘的经历。我希望能再去中国，如果有机会，我也想在中国工作。

无论如何，让我们享受PostgreSQL吧！

2018年11月

致谢

本书的出版离不开出版社工作人员与译者们巨大的努力与付出，对此我深表感激。

作者

Hironobu Suzuki 日语：鈴木啓修

我毕业于信息工程研究生院（信息工程硕士），曾在多家公司担任软件开发人员和技术经理/技术主管。我在数据库和系统集成领域出版了七本书（3本PostgreSQL书和3本MySQL书）。

作为日本PostgreSQL用户组的主任（2010-2016），我连续六年组织了日本规模最大的（非商业）PostgreSQL技术研讨会，并担任日本2013年PostgreSQL大会的委员会主席，以及2008年和2009年的委员会成员。

当我年轻时，曾在厄瓜多尔住了两年，有时我会回到那里去。

目前我住在爱尔兰，都柏林。

译者序

《PG Internal译者序》

著： 冯若航（@Vonng） | 2019-06-01

译者序

各位读者你们好，相信能选择这本书的读者，大多已经对PostgreSQL有所了解了。本书从PostgreSQL的整体架构展开，依次介绍了各个功能模块的来龙去脉，对于DBA与数据库系统开发人员了解数据库内部原理，阅读学习PostgreSQL源码是不可多得的一本好书。

数据库是信息系统的核心组件，关系型数据库则是数据库皇冠上的明珠，而PostgreSQL的Title是”世界上最先进的开源关系型数据库“。PostgreSQL在各行各业，各种场景下都有着广泛应用。但会用，只是”知其然“，知道背后的原理，才能“知其所以然”。对数据库原理，及其具体实现的理解，能让架构师以最小的复杂度代价实现所需的功能，能让程序员以最少的复杂度代价写出更可靠高效的代码，能让DBA在遇到疑难杂症时带来精准的直觉与深刻的洞察。

数据库是一个博大精深的领域，存储I/O计算无所不包。PostgreSQL可以视作关系型数据库实现的典范，用100万行不到的C代码实现了功能如此丰富的软件系统可谓凝练无比。它的每一个功能模块都值得用一本甚至几本书的篇幅去介绍。本书限于篇幅虽无法一一深入所有细节，但它为读者进一步深入理解PostgreSQL提供了一副全局的概念地图。读者完全可以顺着各个章节的线索，以点破面，深入挖掘源码背后的设计思路。

我偶然发现了这本书，读完之后感觉受益匪浅。这么好的书没有中文翻译，实在是遗憾，遂萌生了翻译的念头。某不才，愿为PostgreSQL在中国的发展贡献一份力量。译者水平有限，翻译如有疏漏，还望读者海涵。

[译者]

冯若航，刘阳明，张文升

探探PostgreSQL DBA

数据库集簇，数据库，数据表

著： 鈴木啓修（Hironobu Suzuki） | 2019-06-01

第一章和第二章简单介绍了一些PostgreSQL的基础知识，有助于读者理解后续章节的内容。本章包括以下几个主题：

数据库集簇（database cluster） 的逻辑结构
数据库集簇的物理结构
堆表（heap table） 文件的内部布局
从表中读写数据的方式

如果你已经熟悉这些内容，可以跳过本章。

1.1 数据库集簇的逻辑结构

数据库集簇（database cluster）是一组数据库（database） 的集合，由一个PostgreSQL服务器管理。第一次听到这个定义也许会令人疑惑，PostgreSQL中的术语“数据库集簇”，并非意味着“一组数据库服务器”。一个PostgreSQL服务器只会在单机上运行并管理单个数据库集簇。

图1.1展示了一个数据库集簇的逻辑结构。 数据库（database） 是 数据库对象（database objects） 的集合。在关系型数据库理论中，数据库对象是用于存储或引用数据的数据结构。（堆）表是一个典型的例子，还有更多种对象，例如索引，序列，视图，函数等。在PostgreSQL中数据库本身也是数据库对象，并在逻辑上彼此分离。所有其他的数据库对象（例如表，索引等）归属于各自相应的数据库。

图1.1 数据库集簇的逻辑结构

在PostgreSQL内部，所有的数据库对象都通过相应的 对象标识符（Object Identifiers, OID） 进行管理，这些标识符是无符号的4字节整型。数据库对象与相应OID之间的关系存储在相应的系统目录中，依具体的对象类型而异。例如数据库和堆表对象的OID分别存储在pg_database和pg_class中，因此当你希望找出OID时，可以执行以下查询：

sampledb=# SELECT datname, oid FROM pg_database WHERE datname = 'sampledb';
 datname  |  oid  
----------+-------
 sampledb | 16384
(1 row)

sampledb=# SELECT relname, oid FROM pg_class WHERE relname = 'sampletbl';
  relname  |  oid  
-----------+-------
 sampletbl | 18740 
(1 row)

1.2 数据库集簇的物理结构

数据库集簇在本质上就是一个文件目录，名曰基础目录（base directory），包含着一系列子目录与文件。执行 initdb 命令会在指定目录下创建基础目录从而初始化一个新的数据库集簇。通常会将基础目录的路径配置到环境变量PGDATA中，但这并不是必须的。

图1.2 展示了一个PostgreSQL数据库集簇的例子。 base子目录中的每一个子目录都对应一个数据库，数据库中每个表和索引都会在相应子目录下存储为（至少）一个文件；还有几个包含特定数据的子目录，以及配置文件。虽然PostgreSQL支持表空间（Tablespace），但该术语的含义与其他RDBMS不同。 PostgreSQL中的表空间对应一个包含基础目录之外数据的目录。

图1.2 数据库集簇示例

后续小节将描述数据库集簇的布局，数据库的布局，表和索引对应的文件布局，以及PostgreSQL中表空间的布局。

1.2.1 数据库集簇的布局

官方文档中描述了数据库集簇的布局。表1.1中列出了主要的文件与子目录：

表 1.1 基本目录下的数据库文件和子目录的布局（参考官方文档）

文件	描述
`PG_VERSION`	包含PostgreSQL主版本号
`pg_hba.conf`	控制PosgreSQL客户端认证
`pg_ident.conf`	控制PostgreSQL用户名映射
`postgresql.conf`	配置参数
`postgresql.auto.conf`	存储使用`ALTER SYSTEM`修改的配置参数（9.4或更新版本）
`postmaster.opts`	记录服务器上次启动的命令行选项

子目录	描述
`base/`	每个数据库对应的子目录存储于此
`global/`	数据库集簇范畴的表（例如`pg_database`），以及`pg_control`文件。
`pg_commit_ts/`	事务提交的时间戳数据（9.5及更新版本）。
`pg_clog/ (9.6-)`	事务提交状态数据（9.6及更老版本），在版本10中被重命名为`pg_xact`。CLOG将在5.4节中描述
`pg_dynshmem/`	动态共享内存子系统中使用的文件（9.4或更新版本）。
`pg_logical/`	逻辑解码的状态数据（9.4或更新版本）。
`pg_multixact/`	多事务状态数据
`pg_notify/`	`LISTEN`/`NOTIFY`状态数据
`pg_repslot/`	复制槽数据（9.4或更新版本）。
`pg_serial/`	已提交的可串行化事务相关信息（9.1或更新版本）
`pg_snapshots/`	导出快照（9.2或更新版本）。 PostgreSQL函数`pg_export_snapshot`在此子目录中创建快照信息文件。
`pg_stat/`	统计子系统的永久文件
`pg_stat_tmp/`	统计子系统的临时文件
`pg_subtrans/`	子事务状态数据
`pg_tblspc/`	指向表空间的符号链接
`pg_twophase/`	两阶段事务（prepared transactions）的状态文件
`pg_wal/ (10+)`	WAL（ Write Ahead Logging）段文件（10或更新版本），从`pg_xlog`重命名而来。
`pg_xact/ (10+)`	事务提交状态数据，（10或更新版本），从`pg_clog`重命名而来。CLOG将在5.4节中描述。
pg_xlog/ (9.6-)	WAL（Write Ahead Logging）段文件（9.6及更老版本），它在版本10中被重命名为`pg_wal`。

1.2.2 数据库布局

一个数据库与base子目录下的一个子目录对应；且该子目录的名称与相应数据库的OID相同。例如当数据库sampledb的OID为16384时，它对应的子目录名称即为16384。

$ cd $PGDATA
$ ls -ld base/16384
drwx------  213 postgres postgres  7242  8 26 16:33 16384

1.2.3 表与索引相关文件的布局

每个小于1GB的表或索引都在相应的数据库目录中存储为单个文件。在数据库内部，表和索引作为数据库对象是通过OID来管理的，而这些数据文件则由变量relfilenode管理。表和索引的relfilenode值通常与其OID一致，但也有例外，下面将详细展开。

让我们看一看表sampletbl的oid和relfilenode：

sampledb=# SELECT relname, oid, relfilenode FROM pg_class WHERE relname = 'sampletbl';
  relname  |  oid  | relfilenode
-----------+-------+-------------
 sampletbl | 18740 |       18740 
(1 row)

从上面的结果可以看出oid和relfilenode值相等。还可以看到表sampletbl的数据文件路径是base/16384/18740。

$ cd $PGDATA
$ ls -la base/16384/18740
-rw------- 1 postgres postgres 8192 Apr 21 10:21 base/16384/18740

表和索引的relfilenode值会被一些命令（例如TRUNCATE，REINDEX，CLUSTER）所改变。例如对表 sampletbl执行TRUNCATE，PostgreSQL会为表分配一个新的relfilenode（18812），删除旧的数据文件（18740），并创建一个新的数据文件（18812）。

sampledb=# TRUNCATE sampletbl;
TRUNCATE TABLE

sampledb=# SELECT relname, oid, relfilenode FROM pg_class WHERE relname = 'sampletbl';
  relname  |  oid  | relfilenode
-----------+-------+-------------
 sampletbl | 18740 |       18812 
(1 row)

在9.0或更高版本中，内建函数pg_relation_filepath能够根据OID或名称返回关系对应的文件路径，非常实用。
sampledb=# SELECT pg_relation_filepath('sampletbl');
pg_relation_filepath 
----------------------
base/16384/18812
(1 row)

当表和索引的文件大小超过1GB时，PostgreSQL会创建并使用一个名为relfilenode.1的新文件。如果新文件也填满了，则会创建下一个名为relfilenode.2的新文件，依此类推。

译者注：数据库系统中的表（Table） 与关系代数中的关系（Relation） 关系紧密但又不尽相同。在PostgreSQL中，表，索引，TOAST表都归类为关系。

$ cd $PGDATA
$ ls -la -h base/16384/19427*
-rw------- 1 postgres postgres 1.0G  Apr  21 11:16 data/base/16384/19427
-rw------- 1 postgres postgres  45M  Apr  21 11:20 data/base/16384/19427.1
...

在构建PostgreSQL时，可以使用配置选项--with-segsize更改表和索引的最大文件大小。

仔细观察数据库子目录就会发现，每个表都有两个与之相关联的文件，后缀分别为_fsm和_vm。这些实际上是空闲空间映射（free space map）和可见性映射（visibility map） 文件，分别存储了表文件每个页面上的空闲空间信息与可见性信息（更多细节见第5.3.4节和第6.2节）。索引没有可见性映射文件，只有空闲空间映射文件。

一个具体的示例如下所示：

$ cd $PGDATA
$ ls -la base/16384/18751*
-rw------- 1 postgres postgres  8192 Apr 21 10:21 base/16384/18751
-rw------- 1 postgres postgres 24576 Apr 21 10:18 base/16384/18751_fsm
-rw------- 1 postgres postgres  8192 Apr 21 10:18 base/16384/18751_vm

在数据库系统内部，这些文件（主体数据文件，空闲空间映射文件，可见性映射文件等）也被称为相应关系的分支（fork）；空闲空间映射是表/索引数据文件的第一个分支（分支编号为1），可见性映射表是数据文件的第二个分支（分支编号为2），数据文件的分支编号为0。

译者注：每个 关系（relation） 可能会有四种分支，分支编号分别为0，1，2，3，0号分支main为关系数据文件本体，1号分支fsm保存了main分支中空闲空间的信息，2号分支vm保存了main分支中可见性的信息，3号分支init是很少见的特殊分支，通常用于不被日志记录（unlogged）的表与索引。

每个分支都会被存储为磁盘上的一到多个文件：PostgreSQL会将过大的分支文件切分为若干个段，以免文件的尺寸超过某些特定文件系统允许的大小，也便于一些归档工具进行并发复制，默认的段大小为1GB。

1.2.4 表空间

PostgreSQL中的表空间（Tablespace） 是基础目录之外的附加数据区域。在8.0版本中引入了该功能。

图1.3展示了表空间的内部布局，以及表空间与主数据区域的关系。

图 1.3 数据库集簇的表空间

执行CREATE TABLESPACE语句会在指定的目录下创建表空间。而在该目录下还会创建版本特定的子目录（例如PG_9.4_201409291）。版本特定的命名方式为：

PG_主版本号_目录版本号

举个例子，如果在/home/postgres/tblspc中创建一个表空间new_tblspc，其oid为16386，则会在表空间下创建一个名如PG_9.4_201409291的子目录。

$ ls -l /home/postgres/tblspc/
total 4
drwx------ 2 postgres postgres 4096 Apr 21 10:08 PG_9.4_201409291

表空间目录通过pg_tblspc子目录中的符号链接寻址，链接名称与表空间的OID值相同。

$ ls -l $PGDATA/pg_tblspc/
total 0
lrwxrwxrwx 1 postgres postgres 21 Apr 21 10:08 16386 -> /home/postgres/tblspc

如果在该表空间下创建新的数据库（OID为16387），则会在版本特定的子目录下创建相应目录。

$ ls -l /home/postgres/tblspc/PG_9.4_201409291/
total 4
drwx------ 2 postgres postgres 4096 Apr 21 10:10 16387

如果在该表空间内创建一个新表，但新表所属的数据库却创建在基础目录下，那么PG会首先在版本特定的子目录下创建名称与现有数据库OID相同的新目录，然后将新表文件放置在刚创建的目录下。

sampledb=# CREATE TABLE newtbl (.....) TABLESPACE new_tblspc;

sampledb=# SELECT pg_relation_filepath('newtbl');
             pg_relation_filepath             
----------------------------------------------
 pg_tblspc/16386/PG_9.4_201409291/16384/18894

1.3 堆表文件的内部布局

在数据文件（堆表，索引，也包括空闲空间映射和可见性映射）内部，它被划分为固定长度的页（pages），或曰 区块（blocks），大小默认为8192字节（8KB）。每个文件中的页从0开始按顺序编号，这些数字称为区块号（block numbers）。如果文件已填满，PostgreSQL通过在文件末尾追加一个新的空页来增长文件。

页面内部的布局取决于数据文件的类型。本节会描述表的页面布局，因为理解接下来的几章需要这些知识。

图 1.4. 堆表文件的页面布局

表的页面包含了三种类型的数据：

堆元组（heap tuples） —— 堆元组就是数据记录本身。它们从页面底部开始依序堆叠。第5.2节与第9章会描述元组的内部结构，这一知识对于理解PostgreSQL并发控制与WAL机制是必须的。
行指针（line pointer） —— 每个行指针占4个字节，保存着指向堆元组的指针。它们也被称为项目指针（item pointer）。行指针简单地组织为一个数组，扮演了元组索引的角色。每个索引项从1开始依次编号，称为偏移号（offset number）。当向页面中添加新元组时，一个相应的新行指针也会被放入数组中，并指向新添加的元组。

首部数据（header data） —— 页面的起始位置分配了由结构PageHeaderData定义的首部数据。它的大小为24个字节，包含关于页面的元数据。该结构的主要成员变量为：

pd_lsn —— 本页面最近一次变更所写入XLOG记录对应的LSN。它是一个8字节无符号整数，与WAL机制相关，第9章将详细展开。
pd_checksum —— 本页面的校验和值。（注意只有在9.3或更高版本才有此变量，早期版中该字段用于存储页面的时间线标识）
pd_lower，pd_upper —— pd_lower指向行指针的末尾，pd_upper指向最新堆元组的起始位置。
pd_special —— 在索引页中会用到该字段。在堆表页中它指向页尾。（在索引页中它指向特殊空间的起始位置，特殊空间是仅由索引使用的特殊数据区域，包含特定的数据，具体内容依索引的类型而定，如B树，GiST，GiN等。

/* @src/include/storage/bufpage.h */

/*
 * 磁盘页面布局
 *
 * 对任何页面都适用的通用空间管理信息
 *
 *		pd_lsn		- 本页面最近变更对应xlog记录的标识。
 *		pd_checksum - 页面校验和
 *		pd_flags	- 标记位
 *		pd_lower	- 空闲空间开始位置
 *		pd_upper	- 空闲空间结束位置
 *		pd_special	- 特殊空间开始位置
 *		pd_pagesize_version - 页面的大小，以及页面布局的版本号
 *		pd_prune_xid - 本页面中可以修剪的最老的元组中的XID.
 *
 * 缓冲管理器使用LSN来强制实施WAL的基本规则："WAL需先于数据写入"。直到xlog刷盘位置超过
 * 本页面的LSN之前，不允许将缓冲区的脏页刷入磁盘。
 *
 * pd_checksum 存储着页面的校验和，如果本页面配置了校验。0是一个合法的校验和值。如果页面
 * 没有使用校验和，我们就不会设置这个字段的值；通常这意味着该字段值为0，但如果数据库是从早于
 * 9.3版本从 pg_upgrade升级而来，也可能会出现非零的值。因为那时候这块地方用于存储页面最后
 * 更新时的时间线标识。 注意，并没有标识告诉你页面的标识符到底是有效还是无效的，也没有与之关
 * 联的标记为。这是特意设计成这样的，从而避免了需要依赖页面的具体内容来决定是否校验页面本身。
 *
 * pd_prune_xid是一个提示字段，用于帮助确认剪枝是否有用。目前对于索引页没用。
 *
 * 页面版本编号与页面尺寸被打包成了单个uint16字段，这是有历史原因的：在PostgreSQL7.3之前
 * 并没有页面版本编号这个概念，这样做能让我们假装7.3之前的版本的页面版本编号为0。我们约束页面
 * 的尺寸必须为256的倍数，留下低8位用于页面版本编号。
 *
 * 最小的可行页面大小可能是64字节，能放下页的首部，空闲空间，以及一个最小的元组。当然在实践中
 * 肯定要大得多(默认为8192字节)，所以页面大小必需是256的倍数并不是一个重要限制。而在另一端，
 * 我们最大只能支持32KB的页面，因为 lp_off/lp_len字段都是15bit。
 */
typedef struct PageHeaderData
{
	PageXLogRecPtr 	pd_lsn;			/* 最近应用至本页面XLog记录的LSN */
	uint16			pd_checksum;	/* 校验和 */
	uint16		  	pd_flags;		/* 标记位，详情见下 */
	LocationIndex 	pd_lower;		/* 空闲空间起始位置 */
	LocationIndex 	pd_upper;		/* 空闲空间终止位置 */
	LocationIndex 	pd_special;		/* 特殊用途空间的开始位置 */
	uint16		  	pd_pagesize_version;
	TransactionId 	pd_prune_xid; 	/* 最老的可修剪XID, 如果没有设置为0 */
	ItemIdData		pd_linp[FLEXIBLE_ARRAY_MEMBER]; /* 行指针的数组 */
} PageHeaderData;


/* 缓冲区页中的项目指针(item pointer)，也被称为行指针(line pointer)。
 *
 * 在某些情况下，项目指针处于 “使用中”的状态，但在本页中没有任何相关联的存储区域。
 * 按照惯例，lp_len == 0 表示该行指针没有关联存储。独立于其lp_flags的状态. 
 */
typedef struct ItemIdData
{
	unsigned	lp_off:15,		/* 元组偏移量 (相对页面起始处) */
             lp_flags:2,		/* 行指针的状态，见下 */
             lp_len:15;		/* 元组的长度，以字节计 */
} ItemIdData;

/* lp_flags有下列可能的状态，LP_UNUSED的行指针可以立即重用，而其他状态的不行。 */
#define LP_UNUSED		0		/* unused (lp_len必需始终为0) */
#define LP_NORMAL		1		/* used (lp_len必需始终>0) */
#define LP_REDIRECT		2		/* HOT 重定向 (lp_len必需为0) */
#define LP_DEAD			3		/* 死元组，有没有对应的存储尚未可知 */

行指针的末尾与最新元组起始位置之间的空余空间称为空闲空间（free space）或空洞（hole）。

为了识别表中的元组，数据库内部会使用元组标识符（tuple identifier, TID）。TID由一对值组成：元组所属页面的区块号，及指向元组的行指针的偏移号。TID的一种典型用途是索引，更多细节参见第1.4.2节。

结构体PageHeaderData定义于src/include/storage/bufpage.h中。

此外，大小超过约2KB（8KB的四分之一）的堆元组会使用一种称为 TOAST（The Oversized-Attribute Storage Technique，超大属性存储技术） 的方法来存储与管理。详情请参阅PostgreSQL文档。

1.4 读写元组的方式

本章的最后将描述读取与写入堆元组的方式。

1.4.1 写入堆元组

让我们假设有一个表，仅由一个页面组成，且该页面只包含一个堆元组。此页面的pd_lower指向第一个行指针，而该行指针和pd_upper都指向第一个堆元组。如图1.5(a)所示。

当第二个元组被插入时，它会被放在第一个元组之后。第二个行指针被插入到第一个行指针的后面，并指向第二个元组。 pd_lower更改为指向第二个行指针，pd_upper更改为指向第二个堆元组，如图1.5(b)。页面内的首部数据（例如pd_lsn，pg_checksum，pg_flag）也会被改写为适当的值，细节在第5.3节和第9章中描述。

图1.5 堆元组的写入

1.4.2 读取堆元组

这里简述两种典型的访问方式：顺序扫描与B树索引扫描：

顺序扫描 —— 通过扫描每一页中的行指针，依序读取所有页面中的所有元组，如图1.6(a)。
B树索引扫描 —— 索引文件包含着索引元组，索引元组由一个键值对组成，键为被索引的列值，值为目标堆元组的TID。进行索引查询时，首先使用键进行查找，如果找到了对应的索引元组，PostgreSQL就会根据相应值中的TID来读取对应的堆元组（使用B树索引找到索引元组的方法请参考相关资料，这一部分属于数据库系统的通用知识，限于篇幅这里不再详细展开）。例如在图1.6(b)中，所获索引元组中TID的值为（区块号 = 7，偏移号 = 2），这意味着目标堆元组是表中第7页的第2个元组，因而PostgreSQL可以直接读取所需的堆元组，而避免对页面做不必要的扫描。

图 1.6 顺序扫描和索引扫描

PostgreSQL还支持TID扫描，位图扫描（Bitmap-Scan）和仅索引扫描（Index-Only-Scan）。

TID扫描是一种通过使用所需元组的TID直接访问元组的方法。例如要在表中找到第0个页面中的第1个元组，可以执行以下查询：
sampledb=# SELECT ctid, data FROM sampletbl WHERE ctid = '(0,1)';
 ctid  |   data    
-------+-----------
 (0,1) | AAAAAAAAA
(1 row)

sampledb=# EXPLAIN SELECT ctid, data FROM sampletbl WHERE ctid = '(0,1)';
                        QUERY PLAN
----------------------------------------------------------
 Tid Scan on sampletbl  (cost=0.00..1.11 rows=1 width=38)
   TID Cond: (ctid = '(0,1)'::tid)
仅索引扫描将在第7章中详细介绍。

进程和内存架构

著： 鈴木啓修（Hironobu Suzuki） | 2019-06-01

本章总结了PostgreSQL中进程与内存的架构，有助于读者理解后续章节。如果读者已经熟悉这些内容，可以直接跳过本章。

2.1 进程架构

PostgreSQL是一个客户端/服务器风格的关系型数据库管理系统，采用多进程架构，运行在单台主机上。

我们通常所谓的“ PostgreSQL服务器（PostgreSQL Server）” 实际上是一系列协同工作的进程集合，包含着下列进程：

postgres服务器进程（Postgres Server Process） 是所有数据库集簇管理进程的父进程。
每个后端进程（Backend Process） 负责处理客户端发出的查询和语句。
各种后台进程（Background Process） 负责执行各种数据库管理任务（例如清理过程与检查点过程）。
各种 复制相关（Replication Associated Process） 的进程负责流复制，流复制的细节会在第11章中介绍。
后台工作进程（Background Worker Process） 在9.3版被引入，它能执行任意由用户实现的处理逻辑。这里不详述，请参阅官方文档。

以下几小节将详细描述前三种进程。

图2.1 PostgreSQL的进程架构示例

本图展示了PostgreSQL服务器包含的进程：postgres服务器进程，两个后端进程，七个后台进程，以及两个客户端进程。也画出了数据库集簇，共享内存，以及两个客户端。

2.1.1 Postgres服务器进程

如上所述，postgres服务器进程（postgres server process） 是PostgreSQL服务器中所有进程的父进程，在早期版本中它被称为 “postmaster“。

带start参数执行pg_ctl实用程序会启动一个postgres服务器进程。它会在内存中分配共享内存区域，启动各种后台进程，如有必要还会启动复制相关进程与后台工作进程，并等待来自客户端的连接请求。每当接收到来自客户端的连接请求时，它都会启动一个后端进程（然后由启动的后端进程处理该客户端发出的所有查询）。

一个postgres服务器进程只会监听一个网络端口，默认端口为5432。如果要在同一台主机上运行多个PostgreSQL服务器，则应为每个服务器配置不同的监听端口，如5432，5433等。

2.1.2 后端进程

每个后端进程（也称为 ”postgres“ ）由postgres服务器进程启动，并处理连接另一侧的客户端发出的所有查询。它通过单条TCP连接与客户端通信，并在客户端断开连接时终止。

因为一条连接只允许操作一个数据库，因此必须在连接到PostgreSQL服务器时显式指定要连接的数据库。

PostgreSQL允许多个客户端同时连接；配置参数max_connections用于控制最大客户端连接数（默认为100）。

因为PostgreSQL没有原生的连接池功能，因此如果许多客户端频繁地重复与PostgreSQL服务器建立断开连接（譬如WEB应用），则会导致建立连接与创建后端进程的开销变大。这种情况对数据库服务器的性能有负面影响，通常可以使用池化中间件（pgbouncer或pgpool-II）来避免该问题。

2.1.3 后台进程

表2.1是后台进程的列表。比起postgres服务器和后端进程，后台进程的种类要多很多。想要简单地解释每种后台进程的具体功能是不现实的，因为这些功能有赖PostgreSQL的内部机制与特定的独立特性。依赖于各个特定的特性以及PostgreSQL的内部机制。因此在本章中仅做简要介绍。细节将在后续章节中描述。

表2.1 后台进程

进程	概述	参考
background writer	本进程负责将共享缓冲池中的脏页逐渐刷入持久化存储中（例如，HDD，SSD）（在9.1及更旧版本中，它还负责处理检查点（checkpoint））	8.6
checkpointer	在9.2及更新版本中，该进程负责处理检查点。	8.6, 9.7
autovacuum launcher	周期性地启动自动清理工作进程（更准确地说，它向Postgres服务器请求创建自动清理工作进程）	6.5
WAL writer	本进程周期性地将WAL缓冲区中的WAL数据刷入持久存储中。	9.9
statistics collector	本进程负责收集统计信息，用于诸如`pg_stat_activity`，`pg_stat_database`等系统视图。
logging collector (logger)	本进程负责将错误消息写入日志文件。
archiver	本进程负责将日志归档。	9.10

这里展示了PostgreSQL服务器包含的实际进程。在以下示例中有一个postgres服务器进程（pid为9687），两个后端进程（pid为9697和9717），以及表2.1中列出的几个后台进程正在运行，亦见图2.1。

postgres> pstree -p 9687
-+= 00001 root /sbin/launchd
 \-+- 09687 postgres /usr/local/pgsql/bin/postgres -D /usr/local/pgsql/data
   |--= 09688 postgres postgres: logger process     
   |--= 09690 postgres postgres: checkpointer process     
   |--= 09691 postgres postgres: writer process     
   |--= 09692 postgres postgres: wal writer process     
   |--= 09693 postgres postgres: autovacuum launcher process     
   |--= 09694 postgres postgres: archiver process     
   |--= 09695 postgres postgres: stats collector process     
   |--= 09697 postgres postgres: postgres sampledb 192.168.1.100(54924) idle  
   \--= 09717 postgres postgres: postgres sampledb 192.168.1.100(54964) idle in transaction

2.2 内存架构

PostgreSQL的内存架构可以分为两部分：

本地内存区域 —— 由每个后端进程分配，供自己使用。
共享内存区域 —— 供PostgreSQL服务器的所有进程使用。

下面一小节简要介绍了这两部分架构。

图2.2 PostgreSQL的内存架构

2.2.1 本地内存区域

每个后端进程都会分配一块本地内存区域用于查询处理。该区域会分为几个子区域 —— 子区域的大小有的固定，有的可变。表2.2列出了主要的子区域。详细信息将在后续章节中介绍。

表2.2 本地内存区域

子区域	描述	参考
`work_mem`	执行器在执行`ORDER BY`和`DISTINCT`时使用该区域对元组做排序，以及存储归并连接和散列连接中的连接表。	第3章
`maintenance_work_mem`	某些类型的维护操作使用该区域（例如`VACUUM`，`REINDEX`）。	6.1
`temp_buffers`	执行器使用此区域存储临时表。

2.2.2 共享内存区域

PostgreSQL服务器启动时会分配共享内存区域。该区域分为几个固定大小的子区域。表2.3列出了主要的子区域。详细信息将在后续章节中介绍。

表2.3 共享内存区域

子区域	描述	参考
`shared buffer pool`	PostgreSQL将表和索引中的页面从持久存储加载至此，并直接操作它们。	第8章
`WAL buffer`	为确保服务故障不会导致任何数据丢失，PostgreSQL实现了WAL机制。 WAL数据（也称为XLOG记录）是PostgreSQL中的事务日志；WAL缓冲区是WAL数据在写入持久存储之前的缓冲区。	第9章
`commit log`	提交日志（Commit Log, CLOG）为并发控制（CC）机制保存了所需的所有事务状态（例如进行中，已提交，已中止等）。	5.4

除了上面这些，PostgreSQL还分配了这几个区域：

用于访问控制机制的子区域（例如信号量，轻量级锁，共享和排他锁等）。
各种后台进程使用的子区域，例如checkpointer和autovacuum。
用于事务处理的子区域，例如保存点（save-point） 与 两阶段提交（2PC）。

诸如此类。

查询处理

著： 鈴木啓修（Hironobu Suzuki） | 2019-06-01

查询处理是PostgreSQL中最为复杂的子系统。如PostgreSQL官方文档所述，PostgreSQL支持SQL2011标准中的大多数特性，查询处理子系统能够高效地处理这些SQL。本章概述了查询处理的流程，特别关注了查询优化的部分。

本章包括下列三个部分：

第一部分：3.1节

这一节会简单介绍PostgreSQL中查询处理的流程。
第二部分：3.2~3.4节

这一部分会描述获取单表查询上最优执行计划的步骤。3.2节讨论代价估计的过程，3.3节描述创建计划树的过程，3.4节将简要介绍执行器的工作过程。
第三部分：3.5~3.6节

这一部分会描述获取多表查询上最优执行计划的步骤。3.5节介绍了三种连接算法：嵌套循环连接（Nested Loop Join），归并连接（Merge Join） ，散列连接（Hash Join）。3.6节将介绍为多表查询创建计划树的过程。

PostgreSQL支持三种技术上很有趣，而且也很实用的功能：外部数据包装（Foreign Data Wrapper, FDW），并行查询，以及版本11即将支持的JIT编译。前两者将在第4章中描述，JIT编译超出范围本书的范围，详见官方文档。

3.1 概览

尽管PostgreSQL在9.6版本后有了基于多个后台工作进程的并行查询，但大体上来讲，还是每个连接对应一个后端进程。后端进程由五个子系统组成，如下所示：

解析器（Parser）

解析器根据SQL语句生成一颗语法解析树（parse tree） 。
分析器（Analyzer）

分析器对语法解析树进行语义分析，生成一颗查询树（query tree）。
重写器（Rewriter）

重写器按照规则系统中存在的规则，对查询树进行改写。
计划器（Planner）

计划器基于查询树，生成一颗执行效率最高的计划树（plan tree）。
执行器（Executor）

执行器按照计划树中的顺序访问表和索引，执行相应查询。

图3.1 查询处理

QueryProcessing

本节将概述这些子系统。计划器和执行器很复杂，后面的章节会对这些函数的细节进行描述。

PostgreSQL的查询处理在官方文档中有详细的描述

3.1.1 解析器（Parser）

解析器基于SQL语句的文本，生成一颗后续子系统可以理解的语法解析树。下面是一个具体的例子。

考虑以下查询：

testdb=# SELECT id, data FROM tbl_a WHERE id < 300 ORDER BY data;

语法解析树的根节点是一个定义在parsenodes.h中的SelectStmt数据结构。图3.2(a)展示了一个查询，而图3.2(b)则是该查询对应的语法解析树。

typedef struct SelectStmt
{
        NodeTag         type;

        /* 这些字段只会在SelectStmts“叶节点”中使用 */
        List       *distinctClause;     /* NULL, DISTINCT ON表达式列表, 或
                                       对所有的(SELECT DISTINCT)为lcons(NIL,NIL) */
        IntoClause *intoClause;         /* SELECT INTO 的目标 */
        List       *targetList;         /* 结果目标列表 (ResTarget) */
        List       *fromClause;         /* FROM 子句 */
        Node       *whereClause;        /* WHERE 限定条件 */
        List       *groupClause;        /* GROUP BY 子句 */
        Node       *havingClause;       /* HAVING 条件表达式 */
        List       *windowClause;       /* WINDOW window_name AS (...), ... */

        /*  在一个表示值列表的叶节点中，上面的字段全都为空，而这个字段会被设置。
         * 注意这个子列表中的元素仅仅是表达式，没有ResTarget的修饰，还需要注意列表元素可能为
         * DEFAULT (表示一个 SetToDefault 节点)，而无论值列表的上下文。 
         * 由分析阶段决定否合法并拒绝。      */
        List       *valuesLists;        /* 未转换的表达式列表 */

        /* 这些字段会同时在SelectStmts叶节点与SelectStmts上层节点中使用 */
        List       *sortClause;         /* 排序子句 (排序依据的列表) */
        Node       *limitOffset;        /* 需要跳过的元组数目 */
        Node       *limitCount;         /* 需要返回的元组数目 */
        List       *lockingClause;      /* FOR UPDATE (锁子句的列表) */
        WithClause *withClause;         /* WITH 子句 */

        /* 这些字段只会在上层的 SelectStmts 中出现 */
        SetOperation op;                /* set 操作的类型 */
        bool            all;            /* 是否指明了 ALL 选项? */
        struct SelectStmt *larg;        /* 左子节点 */
        struct SelectStmt *rarg;        /* 右子节点 */
} SelectStmt;

图3.2. 语法解析树的例子

ParseTree

SELECT查询中的元素和语法解析树中的元素有着对应关系。比如，(1)是目标列表中的一个元素，与目标表的'id'列相对应，(4)是一个WHERE子句，诸如此类。

当解析器生成语法分析树时只会检查语法，只有当查询中出现语法错误时才会返回错误。解析器并不会检查输入查询的语义，举个例子，如果查询中包含一个不存在的表名，解析器并不会报错，语义检查由分析器负责。

3.1.2 分析器（Analyzer）

分析器对解析器产出的语法解析树（parse tree）进行语义分析，并产出一颗查询树（query tree）。

查询树的根节点是parsenode.h中定义的Query数据结构，这个结构包含着对应查询的元数据，比如命令的类型（SELECT/INSERT等），还包括了一些叶子节点，叶子节点由列表或树组成，包含了特定子句相应的数据。

/*
 * Query -
 *	  解析与分析过程会将所有的语句转换为一颗查询树，供重写器与计划器用于进一步的处理。
 *    功能语句（即不可优化的语句）会设置utilityStmt字段，而Query结构本身基本上是空的。
 *	  DECLARE CURSOR 是一个特例：它的形式与SELECT类似，但原始的DeclareCursorStmt会
 *    被放在 utilityStmt 字段中。
 *    计划过程会将查询树转换为一颗计划树，计划树的根节点是一个PlannedStmt结构
 *    执行器不会用到查询树结构
 */
typedef struct Query
{
	NodeTag		type;
	CmdType		commandType;		/* select|insert|update|delete|utility */
	QuerySource querySource;		/* 我来自哪里? */
	uint32		queryId;		    /* 查询标识符 (可由插件配置) */

	bool		canSetTag;		    /* 我设置了命令结果标签吗? */
	Node	   	*utilityStmt;		/* 如果这是一条DECLARE CURSOR或不可优化的语句 */
	int		resultRelation; 	    /* 对增删改语句而言是目标关系的索引; SELECT为0 */
	bool		hasAggs;		    /* 是否在目标列表或having表达式中指定了聚合函数 */
	bool		hasWindowFuncs; 	/* tlist是否包含窗口函数 */
	bool		hasSubLinks;		/* 是否包含子查询SubLink */
	bool		hasDistinctOn;		/* 是否包含来自DISTINCT ON的distinct子句 */
	bool		hasRecursive;		/* 是否制定了WITH RECURSIVE */
	bool		hasModifyingCTE;	/* 是否在WITH子句中包含了INSERT/UPDATE/DELETE */
	bool		hasForUpdate;		/* 是否指定了FOR [KEY] UPDATE/SHARE*/
	bool		hasRowSecurity; 	/* 是否应用了行安全策略 */
	List	   	*cteList;		    /* CTE列表 */
	List	   	*rtable;		    /* 范围表项目列表 */
	FromExpr   	*jointree;		    /* 表连接树 (FROM 与 WHERE 子句) */
	List	   	*targetList;		/* 目标列表 (TargetEntry的列表) */
	List	   	*withCheckOptions;	/* WithCheckOption的列表 */
	OnConflictExpr 	*onConflict; 	/* ON CONFLICT DO [NOTHING | UPDATE] */
	List	   	*returningList;		/* 返回值列表(TargetEntry的列表) */
	List	   	*groupClause;		/* SortGroupClause的列表 */
	List	   	*groupingSets;		/* 如果有，GroupingSet的列表 */
	Node	   	*havingQual;		/* 分组的Having条件列表 */
	List	   	*windowClause;		/* 窗口子句列表 */
	List	   	*distinctClause; 	/* SortGroupClause列表 */
	List	   	*sortClause;		/* SortGroupClause列表 */
	Node	   	*limitOffset;		/* Offset跳过元组数目 (int8 表达式) */
	Node	   	*limitCount;		/* Limit返回元组数目 (int8 表达式) */
	List	   	*rowMarks;          /* RowMarkClause列表 */
	Node	   	*setOperations;		/* 如果是UNION/INTERSECT/EXCEPT的顶层查询，
	                                   则为集合操作列表 */
	List	   	*constraintDeps; 	/* 确认查询语义是否合法时，所依赖约束对象的OID列表 */
} Query;

图3.3 查询树一例

QueyTree

简要介绍一下上图中的查询树：

targetlist 是查询结果中**列（Column）**的列表。在本例中该列表包含两列：id 和data。如果在输入的查询树中使用了*（星号），那么分析器会将其显式替换为所有具体的列。
范围表rtable是该查询所用到关系的列表。本例中该变量包含了表tbl_a的信息，如该表的表名与oid。
连接树jointree存储着FROM和WHERE子句的相关信息。
排序子句sortClause是SortGroupClause结构体的列表。

官方文档描述了查询树的细节。

3.1.3 重写器（Rewriter）

PostgreSQL的规则系统正是基于重写器实现的；当需要时，重写器会根据存储在pg_rules中的规则对查询树进行转换。规则系统本身也是一个很有趣的系统，不过本章略去了关于规则系统和重写器的描述，以免内容过于冗长。

视图

在PostgreSQL中，视图是基于规则系统实现的。当使用CREATE VIEW命令定义一个视图时，PostgreSQL就会创建相应的规则，并存储到系统目录中。

假设下面的视图已经被定义，而pg_rule中也存储了相应的规则。
sampledb=# CREATE VIEW employees_list 
sampledb-#   AS SELECT e.id, e.name, d.name AS department 
sampledb-#      FROM employees AS e, departments AS d WHERE e.department_id = d.id;
当执行一个包含该视图的查询，解析器会创建一颗如图3.4(a)所示的语法解析树。
sampledb=# SELECT * FROM employees_list;
在该阶段，重写器会基于pg_rules中存储的视图规则将rangetable节点重写为一颗查询子树，与子查询相对应。

图3.4 重写阶段一例

因为PostgreSQL使用这种机制实现视图，直到9.2版本，视图都是不能更新的。虽然9.3版本后可以对视图进行更新，但对视图的更新仍然存在很多限制，具体细节请参考官方文档。

3.1.4 计划器与执行器

计划器从重写器获取一颗查询树（query tree），基于查询树生成一颗能被执行器高效执行的（查询）计划树（plan tree）。

在PostgreSQL中，计划器是完全基于代价估计（cost-based）的；它不支持基于规则的优化与提示（hint）。计划器是RDBMS中最为复杂的部分，因此本章的后续内容会对计划器做一个概述。

pg_hint_plan

PostgreSQL不支持SQL中的提示（hint），并且永远也不会去支持。如果你想在查询中使用提示，可以考虑使用pg_hint_plan扩展，细节请参考官方站点。

与其他RDBMS类似，PostgreSQL中的EXPLAIN命令会显示命令的计划树。下面给出了一个具体的例子。

testdb=# EXPLAIN SELECT * FROM tbl_a WHERE id < 300 ORDER BY data;
                          QUERY PLAN                           
---------------------------------------------------------------
 Sort  (cost=182.34..183.09 rows=300 width=8)
   Sort Key: data
   ->  Seq Scan on tbl_a  (cost=0.00..170.00 rows=300 width=8)
         Filter: (id < 300)
(4 rows)

图3.5展示了结果相应的计划树。

图3.5 一个简单的计划树以及其与EXPLAIN命令的关系

planTree

计划树由许多称为**计划节点（plan node）**的元素组成，这些节点挂在PlannedStmt结构对应的计划树上。这些元素的定义在plannodes.h中，第3.3.3节与第3.5.4.2会解释相关细节。

每个计划节点都包含着执行器进行处理所必需的信息，在单表查询的场景中，执行器会按照从终端节点往根节点的顺序依次处理这些节点。

比如图3.5中的计划树就是一个列表，包含一个排序节点和一个顺序扫描节点；因而执行器会首先对表tbl_a执行顺序扫描，并对获取的结果进行排序。

执行器会通过第8章将介绍的缓冲区管理器来访问数据库集簇的表和索引。当处理一个查询时，执行器会使用预先分配的内存空间，比如temp_buffers和work_mem，必要时还会创建临时文件。

图3.6 执行器，缓冲管理器，临时文件之间的关系

除此之外，当访问元组的时候，PostgreSQL还会使用并发控制机制来维护运行中事务的一致性和隔离性。第五章介绍了并发控制机制。

3.2 单表查询的代价估计

PostgreSQL的查询优化是基于**代价（Cost）**的。代价是一个无量纲的值，它并不是一种绝对的性能指标，但可以作为比较各种操作代价时的相对性能指标。

costsize.c中的函数用于估算各种操作的代价。所有被执行器执行的操作都有着相应的代价函数。例如，函数cost_seqscan() 和 cost_index()分别用于估算顺序扫描和索引扫描的代价。

在PostgreSQL中有三种代价：启动（start-up） ， 运行（run）和总和（total）。总代价是启动代价和运行代价的和；因此只有启动代价和运行代价是单独估计的。

启动代价（start-up）：在读取到第一条元组前花费的代价，比如索引扫描节点的启动代价就是读取目标表的索引页，取到第一个元组的代价
运行代价（run）：获取全部元组的代价
总代价（total）：前两者之和

EXPLAIN命令显示了每个操作的启动代价和总代价，下面是一个简单的例子：

testdb=# EXPLAIN SELECT * FROM tbl;
                       QUERY PLAN                        
---------------------------------------------------------
 Seq Scan on tbl  (cost=0.00..145.00 rows=10000 width=8)
(1 row)

在第4行显示了顺序扫描的相关信息。代价部分包含了两个值：0.00和145.00。在本例中，启动代价和总代价分别为0.00和145.00。

在本节中，我们将详细介绍顺序扫描，索引扫描和排序操作的代价是如何估算的。

在接下来的内容中，我们使用下面这个表及其索引作为例子。

testdb=# CREATE TABLE tbl (id int PRIMARY KEY, data int);
testdb=# CREATE INDEX tbl_data_idx ON tbl (data);
testdb=# INSERT INTO tbl SELECT generate_series(1,10000),generate_series(1,10000);
testdb=# ANALYZE;
testdb=# \d tbl
      Table "public.tbl"
 Column |  Type   | Modifiers 
--------+---------+-----------
 id     | integer | not null
 data   | integer | 
Indexes:
    "tbl_pkey" PRIMARY KEY, btree (id)
    "tbl_data_idx" btree (data)

3.2.1 顺序扫描

顺序扫描的代价是通过函数cost_seqscan()估计的。本节将研究顺序扫描代价是如何估计的，以下面的查询为例：

testdb=# SELECT * FROM tbl WHERE id < 8000;

在顺序扫描中，启动代价等于0，而运行代价由以下公式定义： $$ \begin{align} \verb|run_cost| &= \verb|cpu_run_cost| + \verb|disk_run_cost | \
&= (\verb|cpu_tuple_cost| + \verb|cpu_operator_cost|) × N_{\verb|tuple|} + \verb|seq_page_cost| × N_{\verb|page|}, \end{align} $$ 其中seq_page_cost，cpu_tuple_cost和cpu_operator_cost是在*postgresql.conf* 中配置的参数，默认值分别为1.0，0.01和0.0025。$N_{\verb|tuple|}$ 和$N_{\verb|page|}$ 分别是表中的元组总数与页面总数，这两个值可以使用以下查询获取。

testdb=# SELECT relpages, reltuples FROM pg_class WHERE relname = 'tbl';
 relpages | reltuples 
----------+-----------
       45 |     10000
(1 row)

$$ \begin{equation}\tag{1} N_{\verb|tuple|}=10000 \end{equation} $$

$$ \begin{equation}\tag{2} N_{\verb|page|}=45 \end{equation} $$

因此： $$ \begin{align} \verb|run_cost| &= (0.01 + 0.0025) × 10000 + 1.0 × 45 = 170.0. \end{align} $$

最终： $$ \verb|total_cost| = 0.0 + 170.0 = 170.0 $$

作为验证，下面是该查询的EXPLAIN结果：

testdb=# EXPLAIN SELECT * FROM tbl WHERE id < 8000;
                       QUERY PLAN                       
--------------------------------------------------------
 Seq Scan on tbl  (cost=0.00..170.00 rows=8000 width=8)
   Filter: (id < 8000)
(2 rows)

在第4行中可以看到，启动代价和总代价分别是0.00和170.0，且预计全表扫描返回行数为8000条（元组）。

在第5行显示了一个顺序扫描的过滤器Filter:(id < 8000)。更精确地说，它是一个表级过滤谓词（table level filter predicate）。注意这种类型的过滤器只会在读取所有元组的时候使用，它并不会减少需要扫描的表页面数量。

从优化运行代价的角度来看，PostgreSQL假设所有的物理页都是从存储介质中获取的；即，PostgreSQL不会考虑扫描的页面是否来自共享缓冲区。

3.2.2 索引扫描

尽管PostgreSQL支持很多索引方法，比如B树，GiST，GIN和BRIN，不过索引扫描的代价估计都使用一个共用的代价函数：cost_index()。

本节将研究索引扫描的代价是如何估计的，以下列查询为例。

testdb=# SELECT id, data FROM tbl WHERE data < 240;

在估计该查询的代价之前，下面的查询能获取$N_{\verb|index|,\verb|page|}$和$N_{\verb|index|,\verb|tuple|}$的值：

testdb=# SELECT relpages, reltuples FROM pg_class WHERE relname = 'tbl_data_idx';
 relpages | reltuples 
----------+-----------
       30 |     10000
(1 row)

$$ \begin{equation}\tag{3} N_{\verb|index|,\verb|tuple|} = 10000 \end{equation} $$

$$ \begin{equation}\tag{4} N_{\verb|index|,\verb|page|} = 30 \end{equation} $$

3.2.2.1 启动代价

索引扫描的启动代价就是读取索引页以访问目标表的第一条元组的代价，由下面的公式定义： $$ \begin{equation} \verb| start-up_cost| = {\mathrm{ceil}(\log_2 (N_{\verb|index|,\verb|tuple|})) + (H_{\verb|index|} + 1) × 50} × \verb|cpu_operator_cost| \end{equation} $$ 其中$H_{\verb|index|}$是索引树的高度。

在本例中，套用公式(3)，$N_{\verb|index,tuple|}$是10000；$H_{\verb|index|}$是1；$\verb|cpu_operator_cost|$是0.0025（默认值）。因此 $$ \begin{equation}\tag{5} \verb|start-up_cost| = {\mathrm{ceil}(\log_2(10000)) + (1 + 1) × 50} × 0.0025 = 0.285 \end{equation} $$

3.2.2.2 运行代价

索引扫描的运行代价是表和索引的CPU代价与IO代价之和。 $$ \begin{align} \verb|run_cost| &= (\verb|index_cpu_cost| + \verb|table_cpu_cost|) + (\verb|index_io_cost| + \verb|table_io_cost|). \end{align} $$

如果使用仅索引扫描，则不会估计table_cpu_cost与table_io_cost，仅索引扫描将在第七章中介绍。

前三个代价（即index_cpu_cost，table_cpu_cost和index_io_cost）如下所示：

$$ \begin{align} \verb|index_cpu_cost| &= \verb|Selectivity| × N_{\verb|index|,\verb|tuple|} × (\verb|cpu_index_tuple_cost| + \verb|qual_op_cost|) \
\verb|table_cpu_cost| &= \verb|Selectivity| × N_{\verb|tuple|}× \verb|cpu_tuple_cost| \
\verb|index_io_cost| &= \mathrm{ceil}(\verb|Selectivity| × N_{\verb|index|,\verb|page|}) ×\verb|random_page_cost| \end{align} $$

以上公式中的cpu_index_tuple_cost和random_page_cost在postgresql.conf中配置（默认值分别为0.005和4.0）。$\verb|qual_op_cost|$粗略来说就是索引求值的代价，默认值是0.0025，这里不再展开。**选择率（Selectivity）**是一个0到1之间的浮点数，代表查询指定的WHERE子句在索引中搜索范围的比例。举个例子，$(\verb|Selectivity| × N_{\verb|tuple|})$就是需要读取的表元组数量，$(\verb|Selectivity| × N_{\verb|index|,\verb|tuple|})$就是需要读取的索引元组数量，诸如此类。

选择率（Selectivity）

查询谓词的选择率是通过**直方图界值（histogram_bounds）与高频值（Most Common Value, MCV）**估计的，这些信息都存储在系统目录pg_statistics中，并可通过pg_stats视图查询。这里通过一个具体的例子来简要介绍选择率的计算方法，细节可以参考官方文档。

表中每一列的高频值都在pg_stats视图的most_common_vals和most_common_freqs中成对存储。

高频值（most_common_vals）：该列上最常出现的取值列表

高频值频率（most_common_freqs）：高频值相应出现频率的列表

下面是一个简单的例子。表countries有两列：一列country存储国家名，一列continent存储该国所属大洲。
testdb=# \d countries
   Table "public.countries"
  Column   | Type | Modifiers 
-----------+------+-----------
 country   | text | 
 continent | text | 
Indexes:
    "continent_idx" btree (continent)

testdb=# SELECT continent, count(*) AS "number of countries", 
testdb-#     (count(*)/(SELECT count(*) FROM countries)::real) AS "number of countries / all countries"
testdb-#       FROM countries GROUP BY continent ORDER BY "number of countries" DESC;
   continent   | number of countries | number of countries / all countries 
---------------+---------------------+-------------------------------------
 Africa        |                  53 |                   0.274611398963731
 Europe        |                  47 |                   0.243523316062176
 Asia          |                  44 |                   0.227979274611399
 North America |                  23 |                   0.119170984455959
 Oceania       |                  14 |                  0.0725388601036269
 South America |                  12 |                  0.0621761658031088
(6 rows)
考虑下面的查询，该查询带有WHERE条件continent = 'Asia'。
testdb=# SELECT * FROM countries WHERE continent = 'Asia';
这时候，计划器使用continent列上的高频值来估计索引扫描的代价，列上的most_common_vals与 most_common_freqs如下所示：
testdb=# \x
Expanded display is on.
testdb=# SELECT most_common_vals, most_common_freqs FROM pg_stats 
testdb-#                  WHERE tablename = 'countries' AND attname='continent';
-[ RECORD 1 ]-----+-----------------------------------------------------------
most_common_vals  | {Africa,Europe,Asia,"North America",Oceania,"South America"}
most_common_freqs | {0.274611,0.243523,0.227979,0.119171,0.0725389,0.0621762}
与most_common_vals中Asia值对应的most_common_freqs为0.227979。因此0.227979会在估算中被用作选择率。

如果高频值不可用，就会使用目标列上的直方图界值来估计代价。

**直方图值（histogram_bounds）**是一系列值，这些值将列上的取值划分为数量大致相同的若干个组。

下面是一个具体的例子。这是表tbl中data列上的直方图界值；
testdb=# SELECT histogram_bounds FROM pg_stats WHERE tablename = 'tbl' AND attname = 'data';
        			     	      histogram_bounds
------------------------------------------------------------------------------
 {1,100,200,300,400,500,600,700,800,900,1000,1100,1200,1300,1400,1500,1600,1700,1800,1900,2000,2100,
2200,2300,2400,2500,2600,2700,2800,2900,3000,3100,3200,3300,3400,3500,3600,3700,3800,3900,4000,4100,
4200,4300,4400,4500,4600,4700,4800,4900,5000,5100,5200,5300,5400,5500,5600,5700,5800,5900,6000,6100,
6200,6300,6400,6500,6600,6700,6800,6900,7000,7100,7200,7300,7400,7500,7600,7700,7800,7900,8000,8100,
8200,8300,8400,8500,8600,8700,8800,8900,9000,9100,9200,9300,9400,9500,9600,9700,9800,9900,10000}
(1 row)
默认情况下，直方图界值会将列上的取值划分入100个桶。图3.7展示了这些桶及其对应的直方图界值。桶从0开始编号，每个桶保存了（大致）相同数量的元组。直方图界值就是相应桶的边界。比如，直方图界值的第0个值是1，意即这是bucket_0中的最小值。第1个值是100，意即bucket_1中的最小值是100，等等。

图3.7 桶和直方图界值

然后本节例子中选择率计算如下所示。假设查询带有WHERE子句data < 240，而值240落在第二个桶中。在本例中可以通过线性插值推算出相应的选择率。因此查询中data列的选择率可以套用下面的公式计算： $$ \verb|Selectivity| = \frac{2+(240-hb[2])/(hb[3]-hb[2])}{100}=\frac{2+(240-200)/(300-200)}{100}=\frac{2+40/100}{100}=0.024 \ (6) $$

因此，根据公式(1)，(3)，(4)和(6)，有 $$ \begin{equation}\tag{7} \verb|index_cpu_cost| = 0.024× 10000 × (0.005+0.0025)=1.8 \end{equation} $$ $$ \begin{equation}\tag{8} \verb|table_cpu_cost| = 0.024 × 10000 × 0.01 = 2.4 \end{equation} $$

$$ \begin{equation}\tag{9} \verb|index_io_cost| = \mathrm{ceil}(0.024 × 30) × 4.0 = 4.0 \end{equation} $$

$\verb|table_io_cost|$ 由下面的公式定义： $$ \begin{equation} \verb|table_io_cost| = \verb|max_io_cost| + \verb|indexCorerelation|^2 × (\verb|min_io_cost|-\verb|max_io_cost|) \end{equation} $$

$\verb|max_io_cost_io_cost|$ 是最差情况下的I/O代价，即，随机扫描所有数据页的代价；这个代价由以下公式定义： $$ \begin{equation} \verb|max_io_cost| = N_{\verb|page|} × \verb|random_page_cost| \end{equation} $$

在本例中，由(2)，$N_{\verb|page|}=45$，得 $$ \begin{equation}\tag{10} \verb|max_io_cost| = 45 × 4.0 = 180.0 \end{equation} $$

$\verb|min_io_cost|$是最优情况下的I/O代价，即，顺序扫描选定的数据页；这个代价由以下公式定义： $$ \begin{equation} \verb|min_io_cost| = 1 × \verb|random_page_cost| + (\mathrm{ceil}(\verb|Selectivity| × N_{\verb|page|})-1) × \verb|seq_page_cost| \end{equation} $$ 在本例中， $$ \begin{equation} \tag{11} \verb|min_io_cost| \ = 1 × 4.0 + (\mathrm{ceil}(0.024 × 45)-1) × 1.0 \end{equation} $$

下文详细介绍$\verb|indexCorrelation|$，在本例中， $$ \begin{equation} \tag{12} \verb|indexCorrelation| = 1.0 \end{equation} $$

由(10)，(11)和(12)，得 $$ \begin{equation} \tag{13} \verb|table_io_cost| = 180.0+1.0^2 × (5.0-180.0)=5.0 \end{equation} $$

综上，由(7)，(8)，(9)和(13)得 $$ \begin{equation}\tag{14} \verb|run_cost| = (1.8+2.4)+(4.0+5.0)=13.2 \end{equation} $$

索引相关性（index correlation）

索引相关性是列值在物理上的顺序和逻辑上的顺序的统计相关性（引自官方文档）。索引相关性的取值范围从$-1$到$+1$。下面的例子有助于理解索引扫描和索引相关性的关系。

表tbl_corr有5个列：两个列为文本类型，三个列为整数类型。这三个整数列保存着从1到12的数字。在物理上表tbl_corr包含三个页，每页有4条元组。每个数字列有一个名如index_col_asc的索引。

testdb=# \d tbl_corr
    Table "public.tbl_corr"
  Column  |  Type   | Modifiers 
----------+---------+-----------
 col      | text    | 
 col_asc  | integer | 
 col_desc | integer | 
 col_rand | integer | 
 data     | text    |
Indexes:
    "tbl_corr_asc_idx" btree (col_asc)
    "tbl_corr_desc_idx" btree (col_desc)
    "tbl_corr_rand_idx" btree (col_rand)

testdb=# SELECT col,col_asc,col_desc,col_rand 
testdb-#                         FROM tbl_corr;
   col    | col_asc | col_desc | col_rand 
----------+---------+----------+----------
 Tuple_1  |       1 |       12 |        3
 Tuple_2  |       2 |       11 |        8
 Tuple_3  |       3 |       10 |        5
 Tuple_4  |       4 |        9 |        9
 Tuple_5  |       5 |        8 |        7
 Tuple_6  |       6 |        7 |        2
 Tuple_7  |       7 |        6 |       10
 Tuple_8  |       8 |        5 |       11
 Tuple_9  |       9 |        4 |        4
 Tuple_10 |      10 |        3 |        1
 Tuple_11 |      11 |        2 |       12
 Tuple_12 |      12 |        1 |        6
(12 rows)

这些列的索引相关性如下：

testdb=# SELECT tablename,attname, correlation FROM pg_stats WHERE tablename = 'tbl_corr';
 tablename | attname  | correlation 
-----------+----------+-------------
 tbl_corr  | col_asc  |           1
 tbl_corr  | col_desc |          -1
 tbl_corr  | col_rand |    0.125874
(3 rows)

当执行下列查询时，由于所有的目标元组都在第一页中，PostgreSQL只会读取第一页，如图3.8(a)所示。

testdb=# SELECT * FROM tbl_corr WHERE col_asc BETWEEN 2 AND 4;

而执行下列查询时则不然，PostgreSQL需要读所有的页，如图3.8(b)所示。

testdb=# SELECT * FROM tbl_corr WHERE col_rand BETWEEN 2 AND 4;

如此可知，索引相关性是一种统计上的相关性。在索引扫描代价估计中，索引相关性体现了索引顺序和物理元组顺序扭曲程度给随机访问性能造成的影响大小。

图3.8 索引相关性

indexcor

3.2.2.3 整体代价

由(3)和(14)可得 $$ \begin{equation}\tag{15} \verb|total_cost| = 0.285 + 13.2 = 13.485 \end{equation} $$

作为确认，上述SELECT查询的EXPLAIN结果如下所示：

testdb=# EXPLAIN SELECT id, data FROM tbl WHERE data < 240;
                                QUERY PLAN                                 
---------------------------------------------------------------------------
 Index Scan using tbl_data_idx on tbl  (cost=0.29..13.49 rows=240 width=8)
   Index Cond: (data < 240)
(2 rows)

在第4行可以看到启动代价和总代价分别是0.29和13.49，预估有240条元组被扫描。

在第5行显示了一个索引条件Index Cond:(data < 240)。更准确地说，这个条件叫做访问谓词（access predicate），它表达了索引扫描的开始条件与结束条件。

根据这篇文章，PostgreSQL中的EXPLAIN命令不会区分访问谓词（access predicate）和索引过滤谓词（index filter predicate）。因此当分析EXPLAIN的输出时，即使看到了“IndexCond”，也应当注意一下预估返回行数。

seq_page_cost和random_page_cost

seq_page_cost和random_page_cost的默认值分别为1.0和4.0。这意味着PostgreSQL假设随机扫描比顺序扫描慢4倍；显然，PostgreSQL的默认值是基于HDD（普通硬盘）设置的。

另一方面，近年来SSD得到了广泛的应用，random_page_cost的默认值就显得太大了。使用SSD时如果仍然采用random_page_cost的默认值，则计划器有可能会选择低效的计划。因此当使用SSD时最好将random_page_cost的值设为1.0。

这篇文章报告了使用random_page_cost默认值导致的问题。

3.2.3 排序

排序路径（sort path） 会在排序操作中被使用。排序操作包括ORDER BY，归并连接的预处理操作，以及其他函数。函数cost_sort()用于估计排序操作的代价。

如果能在工作内存中放下所有元组，那么排序操作会选用快速排序算法。否则的话则会创建临时文件，使用文件归并排序算法。

排序路径的启动代价就是对目标表的排序代价，因此代价就是$O(N_{\verb|sort|}× \log_2(N_{\verb|sort|})$，这里$N_{\verb|sort|}$就是待排序的元组数。排序路径的运行代价就是读取已经排好序的元组的代价，因而代价就是$O(N_{sort})$。

本节将研究以下查询排序代价的估计过程。假设该查询只使用工作内存，不使用临时文件。

testdb=# SELECT id, data FROM tbl WHERE data < 240 ORDER BY id;

在本例中，启动代价由以下公式定义： $$ \begin{equation} \verb|start-up_cost| = \verb|C|+ \verb|comparison_cost| × N_{\verb|sort|} × \log_2(N_{\verb|sort|}) \end{equation} $$

这里$C$就是上一次扫描的总代价，即上次索引扫描的总代价；由(15)可得C等于13.485；$N_{\verb|sort|}=240$；$\verb|comparison_cost|$ 定义为$2 × \verb|cpu_operator_cost|$。因此有

$$ \begin{equation} \verb|start-up_cost| = 13.485+(2×0.0025)×240.0×\log_2(240.0)=22.973 \end{equation} $$

运行代价是在内存中读取排好序的元组的代价，即： $$ \begin{equation} \verb|run_cost| = \verb|cpu_operator_cost| × N_{\verb|sort|} = 0.0025 × 240 = 0.6 \end{equation} $$ 综上： $$ \begin{equation} \verb|total_cost|=22.973+0.6=23.573 \end{equation} $$ 作为确认，以上SELECT查询的EXPLAIN命令结果如下：

testdb=# EXPLAIN SELECT id, data FROM tbl WHERE data < 240 ORDER BY id;
                                   QUERY PLAN                                    
---------------------------------------------------------------------------------
 Sort  (cost=22.97..23.57 rows=240 width=8)
   Sort Key: id
   ->  Index Scan using tbl_data_idx on tbl  (cost=0.29..13.49 rows=240 width=8)
         Index Cond: (data < 240)
(4 rows)

在第4行可以看到启动代价和运行代价分别为22.97和23.57。

3.3 创建单表查询的计划树

计划器非常复杂，故本节仅描述最简单的情况，即单表查询的计划树创建过程。更复杂的查询，换而言之即多表查询，其计划树创建过程将在第3.6节中阐述。

PostgreSQL中的计划器会执行三个处理步骤：

执行预处理
在所有可能的访问路径中，找出代价最小的访问路径
按照代价最小的路径，创建计划树

访问路径（access path）是估算代价时的处理单元；比如，顺序扫描，索引扫描，排序以及各种连接操作都有其对应的路径。访问路径只在计划器创建查询计划树的时候使用。最基本的访问路径数据结构就是relation.h中定义的Path结构体。它就相当于是顺序扫描。所有其他的访问路径都基于该结构，下面会介绍细节。

计划器为了处理上述步骤，会在内部创建一个PlannerInfo数据结构。在该数据结构中包含着查询树，查询所涉及关系信息，访问路径等等。

typedef struct PathKey {
    NodeTag type;
    EquivalenceClass *pk_eclass; /* 值是否有序 */
    Oid pk_opfamily;             /* 用于定义顺序的B树操作符族 */
    int pk_strategy;             /* 排序方向(ASC or DESC) */
    bool pk_nulls_first;         /* NULL是否排序在常规值之前？ */
} PathKey;

typedef struct Path {
    NodeTag type;
    NodeTag pathtype;          /* 标识 scan/join 方法的标签 */
    RelOptInfo *parent;        /* 路径所基于的关系 */
    PathTarget *pathtarget;    /* Vars/Exprs的列表, 代价, 宽度 */
    ParamPathInfo *param_info; /* 参数化信息, 如果没有则为NULL */
    bool parallel_aware;       /* 涉及到并行相关的逻辑？ */
    bool parallel_safe;        /* 是否能作为并行执行计划的一部分? */
    int parallel_workers;      /* 期待的并行工作进程数量； 0表示没有并行 */

    /* 估计路径的尺寸或代价 (更多详情参考costsize.c) */
    double rows;       /* 预估结果元组数目 */
    Cost startup_cost; /* 获取任何元组前需要花费的代价 */
    Cost total_cost;   /* 总代价 (假设获取所有元组所需代价) */
    List *pathkeys;    /* 路径输出的排序顺序 */
    /* pathkeys 是PathKey节点的列表，PathKey定义见上面 */
} Path;

typedef struct PlannerInfo {
    NodeTag type;
    Query *parse;                    /* 被计划的查询 */
    PlannerGlobal *glob;             /* 当前计划器运行时的全局信息 */
    Index query_level;               /* 最外层查询为1 */
    struct PlannerInfo *parent_root; /* 最外层查询为NULL */

    /* plan_params包含着当前计划中的查询层次需要对低层查询暴露的表达式。
     * outer_params包含着PARAM_EXEC参数中的paramId列表，这些参数是外
     * 部查询层次对当前查询层次所暴露的。*/
    List *plan_params; /* PlannerParamItems的列表, 见下 */
    Bitmapset *outer_params;

    /* simple_rel_array 持有着指向“基础关系”与“其他关系”的指针 (详情参考
     * RelOptInfo的注释)。它由rangetable index所索引（因此第0项总是废值）。
     * 当RTE并不与基础关系相对应，譬如连接的RTE，或未引用的视图RTE，或该
     * RelOptInfo还没有产生时，里面的项目可能为NULL。*/
    struct RelOptInfo **simple_rel_array; /* 所有单个关系的RelOptInfos */
    int simple_rel_array_size;            /* 数组分配的大小 */

    /* simple_rte_array 与simple_rel_array 长度相同，且持有指向关联范围表项的指针。
     * 这使得我们能避免执行rt_fetch(), 当需要展开很大的继承集时会很慢。 */
    RangeTblEntry **simple_rte_array; /* rangetable的数组 */

    /* all_baserels是所有查询所涉及基本关系的关系ID列表（但不含“其他关系”的ID）
     * 也就是说，最终连接时，所需构建的关系标识符。该字段是由make_one_rel计算的。
     * 计算发生于计算Paths之前。*/
    Relids all_baserels;

    /* nullable_baserels 是在进行外连接的jointree中那些可空的基础关系的ID集合。
     * 这些关系可能在WHERE子句，SELECT目标列表或其他地方产生空值。该字段由函数
     * deconstruct_jointree负责计算。*/
    Relids nullable_baserels;

    /* join_rel_list是一个列表，在计划过程中连接关系的RelOptInfos都放在这里。
     * 对于比较小的问题，我们只是简单的扫过这个列表来完成查找。但当连接很多关系时，
     * 我们会使用散列表来加速查询。散列表当且仅当join_rel_hash不为空时存在且
     * 有效。注意即使用散列表查找时，我们依然会维护列表，这会简化GEQO的相关问题。*/
    List *join_rel_list;        /* 连接关系的RelOptInfos */
    struct HTAB *join_rel_hash; /* 连接关系的散列表，可选 */

    /* 当使用动态规划进行连接搜索时，join_rel_level[k]是第k层的连接关系RelOptInfos列表。
     * 新的连接关系RelOptInfos会自动添加到join_rel_level[join_cur_level]中，
     * 而join_cur_level为当前层级。如果没用到动态规划，join_rel_level则为空。*/
    List **join_rel_level;    /* 连接关系RelOptInfo的列表 */
    int join_cur_level;       /* 待追加列表的序号 */
    List *init_plans;         /* 查询的初始SubPlans */
    List *cte_plan_ids;       /* 子计划的ID列表，每个CTE对应一个 */
    List *multiexpr_params;   /* MULTIEXPR子查询输出用到的双层嵌套参数列表 */
    List *eq_classes;         /* 活跃的EquivalenceClasses列表 */
    List *canon_pathkeys;     /* "标准" PathKeys 的列表 */
    List *left_join_clauses;  /* RestrictInfos列表，用于左连接子句 */
    List *right_join_clauses; /* RestrictInfos列表，用于右连接子句 */
    List *full_join_clauses;  /* RestrictInfos列表，用于完全连接子句 */
    List *join_info_list;     /* SpecialJoinInfos 的列表 */
    List *append_rel_list;    /* AppendRelInfos 的列表 */
    List *rowMarks;           /* PlanRowMarks 的列表 */
    List *placeholder_list;   /* PlaceHolderInfos 的列表 */
    List *fkey_list;          /* ForeignKeyOptInfos 的列表 */
    List *query_pathkeys;     /* query_planner()期望的pathkeys */
    List *group_pathkeys;     /* groupClause的pathkeys, 如果有的话 */
    List *window_pathkeys;    /* 底部窗口的pathkeys, 如果有的话 */
    List *distinct_pathkeys;  /* distinctClause的pathkeys, 如果有的话 */
    List *sort_pathkeys;      /* sortClause的pathkeys, 如果有的话 */
    List *initial_rels;       /* 我们现在正在尝试连接的RelOptInfos */

    /* 使用fetch_upper_rel()来获取任意特定的上层关系 */
    List *upper_rels[UPPERREL_FINAL + 1]; /* upper-rel RelOptInfos */

    /* grouping_planner针对上层处理过程选择的目标列表 */
    struct PathTarget *upper_targets[UPPERREL_FINAL + 1];

    /* grouping_planner会将最终处理过后的targetlist回传至此。在最终计划最顶层的目标列表中会用到 */
    List *processed_tlist;

    /* create_plan()期间填充的字段，定义于setrefs.c */
    AttrNumber *grouping_map;    /* 针对GroupingFunc的修补 */
    List *minmax_aggs;           /* MinMaxAggInfos列表 */
    MemoryContext planner_cxt;   /* 持有PlannerInfo的上下文 */
    double total_table_pages;    /* 查询涉及到所有表的页面总数 */
    double tuple_fraction;       /* 传递给查询计划器的tuple_fraction */
    double limit_tuples;         /* 传递给查询计划器的limit_tuples */
    bool hasInheritedTarget;     /* 若parse->resultRelation为继承的子关系则为真 */
    bool hasJoinRTEs;            /* 如果任意RTEs为RTE_JOIN类别则为真 */
    bool hasLateralRTEs;         /* 如果任意RTEs被标记为LATERAL则为真 */
    bool hasDeletedRTEs;         /* 如果任意RTEs从连接树中被删除则为真 */
    bool hasHavingQual;          /* 如果havingQual非空则为真 */
    bool hasPseudoConstantQuals; /* 如果任意RestrictInfo包含
    								pseudoconstant = true则为真 */
    bool hasRecursion;           /* 如果计划中包含递归WITH项则为真 */

    /* 当hasRecursion为真时，会使用以下字段： */
    int wt_param_id;                 /* 工作表上PARAM_EXEC的ID */
    struct Path *non_recursive_path; /* 非递归项的路径 */

    /* 这些字段是createplan.c的工作变量 */
    Relids curOuterRels;  /* 当前节点外部的关系 */
    List *curOuterParams; /* 尚未赋值的NestLoopParams */

    /* 可选的join_search_hook私有数据, 例如, GEQO */
    void *join_search_private;
} PlannerInfo;

本节会通过一个具体的例子，来描述如何基于查询树创建计划树。

3.3.1 预处理

在创建计划树之前，计划器对先PlannerInfo中的查询树进行一些预处理。

预处理有很多步骤，本节只讨论和单表查询处理相关的主要步骤。其他预处理操作将在3.6节中描述。

简化目标列表（target list），LIMIT子句等；

例如，表达式2+2会被重写为4，这是由clauses.c中eval_const_expressions()函数负责的。
布尔表达式的规范化

例如，NOT(NOT a)会被重写为a
压平与/或表达式

SQL标准中的AND/OR是二元操作符；但在PostgreSQL内部它们是多元操作符。而计划器总是会假设所有的嵌套AND/OR都应当被压平。

这里有一个具体的例子。考虑这样一个布尔表达式(id = 1) OR (id = 2) OR (id = 3)，图3.9(a) 展示了使用二元表达式时的查询树，预处理会将这些二元算子简化压平为一个三元算子，如图3.9(b)所示。

图3.9. 压平布尔表达式的例子

3.3.2 找出代价最小的访问路径

计划器对所有可能的访问路径进行代价估计，然后选择代价最小的那个。具体来说，计划器会执行以下几个步骤：

创建一个RelOptInfo数据结构，存储访问路径及其代价。

RelOptInfo结构体是通过make_one_rel()函数创建的，并存储于PlannerInfo结构体的simple_rel_array字段中，如图3.10所示。在初始状态时RelOptInfo持有着baserestrictinfo变量，如果存在相应索引，还会持有indexlist变量。baserestrictinfo存储着查询的WHERE子句，而indexlist存储着目标表上相关的索引。

typedef enum RelOptKind
{
	RELOPT_BASEREL,
	RELOPT_JOINREL,
	RELOPT_OTHER_MEMBER_REL,
	RELOPT_UPPER_REL,
	RELOPT_DEADREL
} RelOptKind;

typedef struct RelOptInfo
{
	NodeTag		type;
	RelOptKind	reloptkind;

	/* 本RelOptInfo包含的所有关系 */
	Relids		relids;			/* 基本关系的ID集合 (范围表索引) */

	/* 由计划器生成的预估尺寸 */
	double		rows;			/* 预估结果元组数目 */

	/* 计划器标记位，每个关系一份 */
	bool		consider_startup;	    /* 保留启动代价最低的路径？ */
	bool		consider_param_startup; /* 同上, 针对参数化路径？ */
	bool		consider_parallel;	    /* 考虑并行路径？ */

	/* 扫描当前关系的默认结果目标列表 */
	struct PathTarget *reltarget;		/* Vars/Exprs, 代价, 宽度的列表 */

	/* 物化相关信息 */
	List	   *pathlist;			    /* Path 结构体列表 */
	List	   *ppilist;			    /* pathlist中使用的ParamPathInfos */
	List	   *partial_pathlist;		/* 部分路径 */
	struct Path *cheapest_startup_path;
	struct Path *cheapest_total_path;
	struct Path *cheapest_unique_path;
	List	    *cheapest_parameterized_paths;

	/* 基础关系与连接关系都需要的 参数化信息 */
	/* (参见 lateral_vars 与 lateral_referencers) */
	Relids		direct_lateral_relids;	/* 直接以LATERAL方式引用的关系 */
	Relids		lateral_relids; 	    

	/* 关于基础关系的信息 (连接关系不会设置这些字段！) */
	Index		relid;
	Oid		    reltablespace;	    /* 表空间 */
	RTEKind		rtekind;		    /* RELATION, SUBQUERY, 或 FUNCTION */
	AttrNumber	min_attr;		    /* 关系属性的最小值 (通常<0) */
	AttrNumber	max_attr;		    /* 关系属性的最大值 */
	Relids	   	*attr_needed;		/* 被索引的数组 [min_attr .. max_attr] */
	int32	   	*attr_widths;	   	/* 被索引的数组 [min_attr .. max_attr] */
	List	   	*lateral_vars;	   	/* 关系所引用的LATERAL Vars 与 PHVs */
	Relids		lateral_referencers;/* 侧面引用本表的关系 */
	List	   	*indexlist;		    /* IndexOptInfo列表 */
	BlockNumber pages;			    /* 来自pg_class的页面数估计值 */
	double		tuples;
	double		allvisfrac;
	PlannerInfo *subroot;		    /* 如有子查询 */
	List	   	*subplan_params; 	/* 如有子查询 */
	int		    rel_parallel_workers;	/* 期望的并行工作进程数量 */

	/* 有关外部表与外部表连接的相关信息 */
	Oid			serverid;		/* 外部表与外部表连接相应的服务器ID */
	Oid			userid;			/* 用于检查访问权限的用户标识 */
	bool		useridiscurrent;/* 当前用户是否能合法进行JOIN */
	struct FdwRoutine *fdwroutine;
	void	   	*fdw_private;

	/* 被各种扫描与连接所使用 */
	List	   	*baserestrictinfo;	/* RestrictInfo结构体列表 (如果存在基础关系) */
	QualCost	baserestrictcost;	/* 求值上述限制条件的代价 */
	List	   	*joininfo;		    /* RestrictInfo 结构体列表，涉及到本表的连接会用到 */
	bool		has_eclass_joins;	/* T 意味着joininfo不完整 */
} RelOptInfo;

估计所有可能访问路径的代价，并将访问路径添加至RelOptInfo结构中。

这一处理过程的细节如下：
1. 创建一条路径，估计该路径中顺序扫描的代价，并将其写入路径中。将该路径添加到RelOptInfo结构的pathlist变量中。
2. 如果目标表上存在相关的索引，则为每个索引创建相应的索引访问路径。估计所有索引扫描的代价，并将代价写入相应路径中。然后将索引访问路径添加到pathlist变量中。
3. 如果可以进行位图扫描，则创建一条位图扫描访问路径。估计所有的位图扫描的代价，并将代价写入到路径中。然后将位图扫描路径添加到pathlist变量中。
从RelOptInfo的pathlist中，找出代价最小的访问路径。
如有必要，估计LIMIT，ORDER BY和AGGREGATE操作的代价。

为了更加清晰的理解计划器的执行过程，下面给出了两个具体的例子。

3.3.2.1 例1

首先来研究一个不带索引的简单单表查询；该查询同时包含WHERE和ORDER BY子句。

testdb=# \d tbl_1
     Table "public.tbl_1"
 Column |  Type   | Modifiers 
--------+---------+-----------
 id     | integer | 
 data   | integer | 

testdb=# SELECT * FROM tbl_1 WHERE id < 300 ORDER BY data;

图3.10和图3.11展示了本例中计划器的处理过程。

图3.10 如何得到例1中代价最小的路径

创建一个RelOptInfo结构，将其保存在PlannerInfo结构的simple_rel_array字段中。
在RelOptInfo结构的baserestrictinfo字段中，添加一条WHERE子句。

WHERE子句id<300会经由initsplan.c中定义的distribute_restrictinfo_to_rels()函数，添加至列表变量baserestrictinfo中。另外由于目标表上没有相关索引，RelOptInfo的indexlist字段为空。
为了满足排序要求，planner.c中的standard_qp_callback()函数会在PlannerInfo的sor_pathkeys字段中添加一个pathkey。

Pathkey是表示路径排序顺序的数据结构。本例因为查询包含一条ORDER BY子句，且该子句中的列为data，故data会被包装为pathkey，放入列表变量sort_pathkeys中。
创建一个Path结构，并使用cost_seqscan函数估计顺序扫描的代价，并将代价写入Path中。然后使用pathnode.c中定义的add_path()函数，将该路径添加至RelOptInfo中。

如之前所提到过的，Path中同时包含启动代价和总代价，都是由cost_seqscan函数所估计的。

在本例中，因为目标表上没有索引，计划器只估计了顺序扫描的代价，因此最小代价是自动确定的。

图3.11 如何得到例1中代价最小的路径（接图3.10）

创建一个新的RelOptInfo结构，用于处理ORDER BY子句。

注意新的RelOptInfo没有baserestrictinfo字段，该信息已经被WHERE子句所持有。
创建一个排序路径，并添加到新的RelOptInfo中；然后让SortPath的subpath字段指向顺序扫描的路径。
```
typedef struct SortPath
{
    Path	path;
    Path	*subpath;		/* 代表输入来源的子路径 */
} SortPath;
```
SortPath结构包含两个Path结构：path与subpath；path中存储了排序算子本身的相关信息，而subpath则指向之前得到的代价最小的路径。

注意顺序扫描路径中parent字段，该字段指向之前的RelOptInfo结构体（也就是在baserestrictinfo中存储着WHERE子句的那个RelOptInfo）。因此在下一步创建计划树的过程中，尽管新的RelOptInfo结构并未包含baserestrictinfo，但计划器可以创建一个包含Filter的顺序扫描节点，将WHERE子句作为过滤条件。

这里已经获得了代价最小的访问路径，然后就可以基于此生成一颗计划树。3.3.3节描述了相关的细节。

3.3.2.2 例2

下面我们将研究另一个单表查询的例子，这一次表上有两个索引，而查询带有一个WHERE子句。

testdb=# \d tbl_2
     Table "public.tbl_2"
 Column |  Type   | Modifiers 
--------+---------+-----------
 id     | integer | not null
 data   | integer | 
Indexes:
    "tbl_2_pkey" PRIMARY KEY, btree (id)
    "tbl_2_data_idx" btree (data)

testdb=# SELECT * FROM tbl_2 WHERE id < 240;

图3.12到3.14展示了本例中计划器的处理过程。

创建一个RelOptInfo结构体
在baserestrictinfo中添加一个WHERE子句；并将目标表上的索引（们）添加到indexlist中。

在本例中，WHERE子句'id <240'会被添加至baserestrictinfo中，而两个索引：tbl_2_pkey和tbl_2_data_idx会被添加至RelOptInfo的列表变量indexlist中。
创建一条路径，估计其顺序扫描代价，并添加到RelOptInfo的pathlist中。

图3.12 如何得到例2中代价最小的路径

typedef struct IndexPath
{
	Path			path;
	IndexOptInfo 	*indexinfo;
	List	   		*indexclauses;
	List	   		*indexquals;
	List	   		*indexqualcols;
	List	   		*indexorderbys;
	List	   		*indexorderbycols;
	ScanDirection 	indexscandir;
	Cost			indextotalcost;
	Selectivity 	indexselectivity;
} IndexPath;

/*
 * IndexOptInfo
 *      用于计划/优化的信息，每个索引对应一个。
 *
 *		indexkeys[], indexcollations[], opfamily[], 以及 opcintype[]
 *		每个字段都有 ncolumns 个项.
 *
 *		sortopfamily[], reverse_sort[], 以及 nulls_first[] 类似，也都有
 *		ncolumns 个项, 当且仅当该索引是有序的，否则这些指针都为空。
 *
 *		indexkeys[] 数组中的零值表示该索引列是一个表达式，而每个这种列在indexprs
 *      中都会有一个对应的元素。
 *
 *      对于有序索引，reverse_sort[] 以及 nulls_first[] 描述了正向索引扫描时
 *      索引的排序顺序。当进行反向索引扫描时，就会产生相反的顺序。
 *
 *		indexprs 与 indpred 会通过prepqual.c 中的 eval_const_expressions() 
 *      用于简单地与WHERE子句匹配，indpred使用简单的合取范式。
 *
 *		indextlist 是 TargetEntry的列表，标识着索引建在哪些列上。对于简单的列，
 *      它会提供基本关系中与之对应的Var，对于表达式列，它还会指向indexprs对应元素。
 *      相对应的Var。
 *
 *		当IndexOptInfo创建时，这里大多数字段都会被填充 (plancat.c)，但indrestrictinfo 
 *      与predOK会在稍后通过check_index_predicates()设置。
 */
typedef struct IndexOptInfo
{
	NodeTag		type;
	Oid		    indexoid;		/* 索引关系的OID */
	Oid		    reltablespace;	/* 索引所属的表空间 (不是表) */
	RelOptInfo 	*rel;			/* 索引对应的表，反向链接 */

	/* 索引尺寸的统计 (来自pg_class和其他地方) */
	BlockNumber pages;			/* 索引中的磁盘页面数 */
	double		tuples;			/* 索引中的元组数量 */
	int		    tree_height;	/* 索引树的高度，未知则为 -1  */

	/* 索引描述符信息 */
	int		    ncolumns;		/* 索引中列的数量 */
	int		    *indexkeys;		/* 索引中列的序号，或者0 */
	Oid		    *indexcollations;	/* 索引列上排序规则的OID */
	Oid		    *opfamily;		/* 列上运算符族的OID */
	Oid		    *opcintype;		/* 运算符族输入数据类型的OID */
	Oid		    *sortopfamily;	/* 如果这些列有序，B树算子族的OID */
	bool	   	*reverse_sort;	/* 排序顺序是反向降序的吗？ */
	bool	   	*nulls_first;	/* 排序顺序中，空值是排在最前面的吗？ */
	bool	   	*canreturn;		/* 在仅索引扫描中，哪些索引列可以被返回？ */
	Oid		    relam;			/* 访问方法的OID (在 pg_am 中) */

	List	   	*indexprs;		/* 非平凡的索引列，即表达式 */
	List	   	*indpred;		/* 如果是部分索引，则为谓词，否则为空 */

	List	   	*indextlist;	/* 表示索引列的目标列表 */

	List	   	*indrestrictinfo;	/* 父关系的baserestrictinfo列表 */

	bool		predOK;			    /* 如果查询与索引谓词匹配则为真 */
	bool		unique;			    /* 唯一索引则为真 */
	bool		immediate;		    /* 唯一约束是否是立即强制实施的？ */
	bool		hypothetical;		/* 如果索引并非真实存在则为真。 */

	/* 剩下这些字段是从索引访问方法的API结构里复制过来的 */
	bool		amcanorderbyop;     /* 访问方法是否支持按算子结果排序？ */
	bool		amoptionalkey;		/* 查询是否可以忽略第一列中的键？ */
	bool		amsearcharray;		/* 访问方法是否能处理ScalarArrayOpExpr限定条件? */
	bool		amsearchnulls;		/* 访问方法是否能搜索空项或非空项？ */
	bool		amhasgettuple;		/* 访问方法是否有amgettuple接口？ */
	bool		amhasgetbitmap; 	/* 访问方法是否有amgetbitmap接口？ */
	/* 相比include amapi.h，我们直接在这里用这种方式声明 amcostestimate  */
	void		(*amcostestimate) ();	/* 访问方法的代价估计器 */
} IndexOptInfo;

创建一个IndexPath，估计索引扫描的代价，并通过add_path()函数将IndexPath添加到RelOptInfo的pathlist中。

在本例中有两个索引：tbl_2_pkey与tbl_2_data_index，这些索引会按先后顺序依次处理。

一条针对tbl_2_pkey的IndexPath会先被创建出来，并进行启动代价与总代价的评估。在本例中，tbl_2_pkey是id列上的索引，而WHERE子句也包含该id列；因此WHERE子句会被存储在IndexPath的indexclauses字段中。
创建另一个IndexPath，估计另一种索引扫描的代价，并将该IndexPath添加到RelOptInfo的pathlist中。

接下来，与tbl_2_data_idx相应的IndexPath会被创建出来，并进行代价估计。本例中tbl_2_data_idx并没有相关的WHERE子句；因此其indexclauses为空。

注意add_path()函数并不总是真的会将路径添加到路径列表中。这一操作相当复杂，故这里就省去了具体描述。详细细节可以参考add_path()函数的注释。

图3.13 如何得到例2中代价最小的路径（接图3.12）

创建一个新的RelOptInfo结构
将代价最小的路径，添加到新RelOptInfo的pathlist中。

本例中代价最小的路径是使用tbl_2_pkey的索引路径；故将该路径添加到新的RelOptInfo中。

图3.14 如何得到例2中代价最小的路径（接图3.13）

3.3.3 创建计划树

在最后一步中，计划器按照代价最小的路径生成一颗计划树。

计划树的根节点是定义在plannodes.h中的PlannedStmt结构，包含19个字段，其中有4个代表性字段：

**commandType**存储操作的类型，诸如SELECT，UPDATE和INSERT。
**rtable**存储范围表的列表（RangeTblEntry的列表）。
**relationOids**存储与查询相关表的oid。
**plantree**存储着一颗由计划节点组成的计划树，每个计划节点对应着一种特定操作，诸如顺序扫描，排序和索引扫描。

/* ----------------
 *		PlannedStmt 节点
 * 计划器的输出是一颗计划树，PlannedStmt是计划树的根节点。
 * PlannedStmt存储着执行器所需的“一次性”信息。
 * ----------------*/
typedef struct PlannedStmt
{
	NodeTag		type;
	CmdType		commandType;		/* 增|删|改|查 */
	uint32		queryId;			/* 查询标识符 (复制自Query) */
	bool		hasReturning;		/* 增|删|改是否带有RETURNING? */
	bool		hasModifyingCTE;	/* WITH子句中是否出现了增|删|改？ */
	bool		canSetTag;			/* 我是否设置了命令结果标记？ */
	bool		transientPlan;		/* 当TransactionXmin变化时重新进行计划? */
	bool		dependsOnRole;		/* 执行计划是否特定于当前的角色？ */
	bool		parallelModeNeeded;	/* 需要并行模式才能执行？ */
	struct Plan *planTree;			/* 计划节点树 */
	List	   	*rtable;			/* RangeTblEntry节点的列表 */
	
    /* 目标关系上用于增|删|改的范围表索引 */
	List	   	*resultRelations;   /* RT索引的整数列表, 或NIL */
	Node	   	*utilityStmt;		/* 如为DECLARE CURSOR则非空 */
	List	   	*subplans;			/* SubPlan表达式的计划树 expressions */
	Bitmapset  	*rewindPlanIDs;		/* 需要REWIND的子计划的索引序号 */
	List	   	*rowMarks;			/* PlanRowMark列表 */
	List	   	*relationOids;		/* 计划所依赖的关系OID列表 */
	List	   	*invalItems;		/* 其他依赖，诸如PlanInvalItems */
	int			nParamExec;			/* 使用的PARAM_EXEC参数数量 */
} PlannedStmt;

如上所述，计划树包含各式各样的计划节点。PlanNode是所有计划节点的基类，其他计划节点都会包含PlanNode结构。比如顺序扫描节点SeqScanNode，包含一个PlanNode和一个整型变量scanrelid。PlanNode包含14个字段。下面是7个代表性字段：

startup_cost和total_cost是该节点对应操作的预估代价。
rows是计划器预计扫描的行数。
targetlist保存了该查询树中目标项的列表。
qual储存了限定条件的列表。
lefttree和righttree用于添加子节点。

/* ----------------
 * 计划节点(Plan Node)
 *
 * 所有的计划节点都"派生"自Plan结构，将其作为自己的第一个字段。这样确保了当其强制转换为Plan
 * 结构时所有东西都能正常工作。(当作为通用参数传入执行器时，节点指针会很频繁地转换为Plan*)
 *
 * 我们从来不会真的去实例化任何Plan节点，它只是所有Plan类型节点的公共抽象父类。
 * ----------------
 */
typedef struct Plan
{
	NodeTag		type;
	/* 计划的预估执行开销 ( 详情见 costsize.c )	 */
	Cost		startup_cost;	/* 获取第一条元组前的代价 */
	Cost		total_cost;		/* 获取所有元组的代价 */

	/* 计划器对该计划步骤返回结果大小的估计 */
	double		plan_rows;		/* 计划预期产出的行数 */
	int			plan_width;		/* 以字节计的行宽 */

	/* 并行查询所需的信息 */
	bool		parallel_aware; /* 是否涉及到并行逻辑？ */

	/* 所有计划类型的公有结构化数据 */
	int			plan_node_id;	/* 在整个计划树范围内唯一的标识 */
	List	   	*targetlist;	/* 该节点需要计算的目标列表 */
	List	   	*qual;			/* 隐式合取化处理的 限制条件 列表 */
	struct Plan *lefttree;		/* 输入的查询树 */
	struct Plan *righttree;
	List	   	*initPlan;	/* Init Plan 节点 (无关子查询表达式) */
	/* “参数变化驱动”的重扫描 相关的管理信息
	 * extParam包含着所有外部PARAM_EXEC参数的参数ID列表，这些参数会影响当前计划节点
     * 及其子节点。这里不包括该节点initPlans时setParam的相关参数，但会包括其extParams
     * 
     * allParam包含了所有extParam的参数ID列表，以及影响当前节点的参数ID。（即，
     * 在initPlans中setParams的参数）。注意这里包含了*所有*会影响本节点的PARAM_EXEC参数
	 */
	Bitmapset	*extParam;
	Bitmapset  	*allParam;
} Plan;

/* ------------
 * 扫描节点(Scan nodes)
 * ----------- */
typedef unsigned int Index;

typedef struct Scan
{
	Plan		plan;
	Index		scanrelid;		/* relid 是访问范围表的索引 */
} Scan;

/* ----------------
 *	顺序扫描节点
 * ---------------- */
typedef Scan SeqScan;

下面是两颗计划树，分别与前一小节中的两个例子对应。

3.3.3.1 例1

第一个例子是3.3.2.1节例1对应的计划树。图3.11所示的代价最小的路径，是由一个排序路径和一个顺序扫描路径组合而成。根路径是排序路径，而其子路径为顺序扫描路径。尽管这里忽略了大量细节，但是从代价最小的路径中生成计划树的过程是显而易见的。在本例中，一个 SortNode被添加到PlannedStmt结构中，而SortNode的左子树上则挂载了一个SeqScanNode，如图3.15(a)所示。

在SortNode中，左子树lefttree指向SeqScanNode。

在SeqScanNode中，qual保存了WHERE子句：'id<300'。

typedef struct Sort
{
	Plan		plan;
	int			numCols;			/* 排序键 列的数目 */
	AttrNumber 	*sortColIdx;		/* 它们在目标列表中的位置序号 */
	Oid			*sortOperators;		/* 排序所赖运算符的OID  */
	Oid			*collations;		/* collation的OID  */
	bool	   	*nullsFirst;		/* NULLS FIRST/LAST 方向 */
} Sort;

图3.15. 计划树的例子

3.3.3.2 例2

第二个例子是3.3.2.2节例2对应的计划树。其代价最小的路径为索引扫描路径，如图3.14所示。因此计划树由单个IndexScanNode独立组成，如图3.15(b)所示。

在本例中，WHERE子句id < 240是一个访问谓词，它储存在IndexScanNode的indexqual字段中。

/* 索引扫描节点 */
typedef struct Scan
{
    Plan          plan;
    Index         scanrelid;         /* relid 是范围表上的索引ID */
} Scan;

typedef struct IndexScan
{
    Scan          scan;
    Oid           indexid;            /* 待扫描的索引OID */
    List          *indexqual;         /* 索引限定条件的列表 (通常是OpExprs) */
    List          *indexqualorig;     /* 同上，但使用原始形式 */
    List          *indexorderby;      /* 索引的ORDER BY表达式 */
    List          *indexorderbyorig;  /* 同上，但使用原始形式 */
    List          *indexorderbyops;   /* ORDER BY表达式用到的排序运算符的OID */
    ScanDirection indexorderdir;      /* 正序扫描还是逆序扫描，或者根本不在乎 */
} IndexScan;

3.4 执行器如何工作

在单表查询的例子中，执行器从计划树中取出计划节点，按照自底向上的顺序进行处理，并调用节点相应的处理函数。

每个计划节点都有相应的函数，用于执行节点对应的操作。这些函数在src/backend/executor目录中。例如，执行顺序扫描的的函数（SeqScan）定义于nodeSeqscan.c中；执行索引扫描的函数（IndexScanNode）定义在nodeIndexScan.c中；SortNode节点对应的排序函数定义在nodeSort.c中，诸如此类。

当然，理解执行器如何工作的最好方式，就是阅读EXPLAIN命令的输出。因为PostgreSQL的EXPLAIN命令几乎就是照着计划树输出的。下面以3.3.3节的例1为例。

testdb=# EXPLAIN SELECT * FROM tbl_1 WHERE id < 300 ORDER BY data;
                          QUERY PLAN                           
---------------------------------------------------------------
 Sort  (cost=182.34..183.09 rows=300 width=8)
   Sort Key: data
   ->  Seq Scan on tbl_1  (cost=0.00..170.00 rows=300 width=8)
         Filter: (id < 300)
(4 rows)

我们可以自底向上阅读EXPLAIN的结果，来看一看执行器是如何工作的。

第6行：首先，执行器通过nodeSeqscan.c中定义的函数执行顺序扫描操作。

第4行：然后，执行器通过nodeSort.c中定义的函数，对顺序扫描的结果进行排序。

临时文件

执行器在处理查询时会使用工作内存（work_mem）和临时缓冲区（temp_buffers），两者都于内存中分配。如果查询无法在内存中完成，就会用到临时文件。

使用带有Analyze选项的EXPLAIN，待解释的命令会真正执行，并显示实际结果行数，实际执行时间和实际内存用量。下面是一个具体的例子：
testdb=# EXPLAIN ANALYZE SELECT id, data FROM tbl_25m ORDER BY id;
                          QUERY PLAN                                                        
----------------------------------------------------------------------
 Sort  (cost=3944070.01..3945895.01 rows=730000 width=4104) (actual time=885.648..1033.746 rows=730000 loops=1)
   Sort Key: id
   Sort Method: external sort  Disk: 10000kB
   ->  Seq Scan on tbl_25m  (cost=0.00..10531.00 rows=730000 width=4104) (actual time=0.024..102.548 rows=730000 loops=1)
 Planning time: 1.548 ms
 Execution time: 1109.571 ms
(6 rows)
在第6行，EXPLAIN命令显示出执行器使用了10000KB的临时文件。

临时文件会被临时创建于base/pg_tmp子目录中，并遵循如下命名规则
{"pgsql_tmp"} + {创建本文件的Postgres进程PID} . {从0开始的序列号}
比如，临时文件pgsql_tmp8903.5是pid为8903的postgres进程创建的第6个临时文件

3.5 连接

PostgreSQL 中支持三种**连接（JOIN）**操作：嵌套循环连接（Nested Loop Join），归并连接（Merge Join） ，散列连接（Hash Join）。在PostgreSQL中，嵌套循环连接与归并连接有几种变体。

在下文中，我们会假设读者已经对这三种操作的基本行为有了解。如果读者对这些概念不熟悉，可以参阅[1, 2]。PostgreSQL支持一种针对数据倾斜的混合散列连接（hybrid hash join），关于这方面的资料不多，因此这里会详细描述该操作。

需要注意的是，这三种**连接方法（join method）**都支持PostgreSQL中所有的连接操作，诸如INNER JOIN，LEFT/RIGHT OUTER JOIN，FULL OUTER JOIN等；但是为了简单起见，这里只关注NATURAL INNER JOIN。

3.5.1 嵌套循环连接（Nested Loop Join）

嵌套循环连接是最为基础的连接操作，任何**连接条件（join condition）**都可以使用这种连接方式。PostgreSQL支持嵌套循环连接及其五种变体。

3.5.1.1 嵌套循环连接

嵌套循环连接无需任何启动代价，因此： $$ \verb|start-up_cost| = 0 $$ 运行代价与内外表尺寸的乘积成比例；即$\verb|runcost|$是$O(N_{\verb|outer|}× N_{\verb|inner|})$，这里$N_{\verb|outer|}$和$N_{\verb|inner|}$分别是外表和内表的元组条数。更准确的说，$\verb|run_cost|$的定义如下： $$ \begin{equation} \verb|run_cost|=(\verb|cpu_operator_cost|+ \verb|cpu_tuple_cost|)× N_{\verb|outer|}× N_{\verb|inner|} + C_{\verb|inner|}× N_{\verb|outer|}+C_{\verb|outer|} \end{equation} $$ 这里$C_{\verb|outer|}$和$C_{\verb|inner|}$分别是内表和外表顺序扫描的代价；

图3.16 嵌套循环连接

嵌套循环连接的代价总是会被估计，但实际中很少会使用这种连接操作，因为它有几种更高效的变体，下面将会讲到。

3.5.1.2 物化嵌套循环连接

在上面描述的嵌套循环连接中，每当读取一条外表中的元组时，都需要扫描内表中的所有元组。为每条外表元组对内表做全表扫描，这一过程代价高昂，PostgreSQL支持一种物化嵌套循环连接（materialized nested loop join） ，可以减少内表全表扫描的代价。

在运行嵌套循环连接之前，执行器会使用**临时元组存储（temporary tuple storage）**模块对内表进行一次扫描，将内表元组加载到工作内存或临时文件中。在处理内表元组时，临时元组存储比缓冲区管理器更为高效，特别是当所有的元组都能放入工作内存中时。

图 3.17说明了物化嵌套循环连接的处理过程。扫描物化元组在内部被称为重扫描（rescan）。

图3.17 物化嵌套循环连接

临时元组存储

PostgreSQL内部提供了临时元组存储的模块，可用于各种操作：物化表，创建混合散列连接的批次，等等。该模块包含一系列函数，都在tuplestore.c中。这些函数用于从工作内存或临时文件读写元组。使用工作内存还是临时文件取决于待存储元组的总数。

下面给出一个具体的例子，并研究一下执行器是如何处理物化嵌套循环连接的计划树并估计其代价的。

testdb=# EXPLAIN SELECT * FROM tbl_a AS a, tbl_b AS b WHERE a.id = b.id;
                              QUERY PLAN                               
-----------------------------------------------------------------------
 Nested Loop  (cost=0.00..750230.50 rows=5000 width=16)
   Join Filter: (a.id = b.id)
   ->  Seq Scan on tbl_a a  (cost=0.00..145.00 rows=10000 width=8)
   ->  Materialize  (cost=0.00..98.00 rows=5000 width=8)
         ->  Seq Scan on tbl_b b  (cost=0.00..73.00 rows=5000 width=8)
(5 rows)

上面显示了执行器要进行的操作，执行器对这些计划节点的处理过程如下：

第7行：执行器使用顺序扫描，物化内部表tbl_b。

第4行：执行器执行嵌套循环连接操作，外表是tbl_a，内表是物化的tbl_b。

下面来估算“物化”操作（第7行）与“嵌套循环”（第4行）的代价。假设物化的内部表元组都在工作内存中。

物化（Materialize）:

物化操作没有启动代价；因此， $$ \begin{equation} \verb|start-up_cost| = 0 \end{equation} $$ 其运行代价定义如下： $$ \verb|run_cost| = 2 × \verb|cpu_operator_cost| × N_{\verb|inner|}; $$ 因此： $$ \verb|run_cost|=2× 0.0025× 5000=25.0 $$ 此外， $$ \verb|total_cost| = (\verb|start-up_cost|+ \verb|total_cost_of_seq_scan|)+ \verb|run_cost| $$ 因此， $$ \verb|total_cost| = (0.0+73.0)+25.0=98.0 $$ **(物化)嵌套循环**:

嵌套循环没有启动代价，因此： $$ \verb|start-up_cost|=0 $$ 在估计运行代价之前，先来看一下重扫描的代价，重扫描的代价定义如下： $$ \verb|rescan_cost| = \verb|cpu_operator_cost| × N_{\verb|inner|} $$ 这本例中： $$ \verb|rescan_cost| = (0.0025)× 5000=12.5 $$ 运行代价由以下公式定义： $$ \verb|run_cost| =(\verb|cpu_operator_cost| + \verb|cpu_tuple_cost|)× N_{\verb|inner|}× N_{\verb|outer|} \

\verb|recan_cost|× (N_{\verb|outer|}-1) + C^{\verb|total|}_{\verb|outer|,\verb|seqscan|} + C^{\verb|total|}_{\verb|materialize|}， $$ 这里 $C^{\verb|total|}_{\verb|outer|,\verb|seqscan|}$代表外部表的全部扫描代价，$C^{\verb|total|}_{\verb|materialize|}$代表物化代价；因此 $$ \verb|run_cost| = ( 0.0025 + 0.01 ) × 5000 × 10000 + 12.5 ×(10000−1)+145.0+98.0=750230.5 $$

3.5.1.3 索引嵌套循环连接

如果内表上有索引，且该索引能用于搜索满足连接条件的元组。那么计划器在为外表的每条元组搜索内表中的匹配元组时，会考虑使用索引进行直接搜索，以替代顺序扫描。这种变体叫做索引嵌套循环连接（indexed nested loop join），如图3.18所示。尽管这种变体叫做索引"嵌套循环连接"，但该算法基本上只需要在在外表上循环一次，因此连接操作执行起来相当高效。

图3.18 索引嵌套循环连接

下面是索引嵌套循环连接的一个具体例子。

testdb=# EXPLAIN SELECT * FROM tbl_c AS c, tbl_b AS b WHERE c.id = b.id;
                                   QUERY PLAN                                   
--------------------------------------------------------------------------------
 Nested Loop  (cost=0.29..1935.50 rows=5000 width=16)
   ->  Seq Scan on tbl_b b (cost=0.00..73.00 rows=5000 width=8)
   ->  Index Scan using tbl_c_pkey on tbl_c c  (cost=0.29..0.36 rows=1 width=8)
         Index Cond: (id = b.id)
(4 rows)

第6行展示了访问内表中元组的代价。即在内表中查找满足第七行连接条件(id = b.id)的元组的代价。

在第7行的索引条件(id = b.id)中，b.id是连接条件中的外表属性的值。每当顺序扫描外表取回一条元组时，就会依第6行所示的索引搜索路径，查找内表中需要与之连接的元组。换而言之，外表元组的值作为参数传入内表的索引扫描中，索引扫描路径会查找满足连接条件的内表元组。这种索引路径被称为参数化（索引）路径（parameterized (index) path），细节见PostgreSQ源码：backend/optimizer/README。

该嵌套循环连接的启动代价，等于第6行中索引扫描的代价，因此： $$ \verb|start-up_cost| = 0.285 $$ 索引嵌套循环扫描的总代价由下列公式所定义： $$ \verb|total_cost|= (\verb|cpu_tuple_cost| + C^{\verb|total|}{\verb|inner,parameterized|} )× N{\verb|outer|}+C^{\verb|run|}{\verb|outer,seqscan|} $$ 这里$C^{\verb|total|}{\verb|inner,parameterized|}$是参数化内表索引扫描的整体代价，

在本例中： $$ \verb|total_cost|=(0.01+0.3625)× 5000 + 73.0 = 1935.5 $$ 而运行代价为： $$ \verb|run_cost| = 1935.5-0.285=1935.215 $$ 如上所示，索引嵌套扫描的整体代价是$O(N_{\verb|outer|})$。

3.5.1.4 其他变体

如果在外表上存在一个与连接条件相关的索引，那么在外表上也可以以索引扫描替代顺序扫描。特别是，当WHERE子句中的访问谓词可以使用该索引时，能缩小外表上的搜索范围，嵌套循环连接的代价可能会急剧减少。

当使用外表索引扫描时，PostgreSQL支持三种嵌套循环连接的变体，如图3.19所示。

图3.19 嵌套循环连接的三种变体，使用外表索引扫描

out

这些连接的EXPLAIN结果如下：

使用外表索引扫描的嵌套循环连接

testdb=# SET enable_hashjoin TO off;
SET
testdb=# SET enable_mergejoin TO off;
SET
testdb=# EXPLAIN SELECT * FROM tbl_c AS c, tbl_b AS b WHERE c.id = b.id AND c.id = 500;
                                   QUERY PLAN                                   
-------------------------------------------------------------------------------
 Nested Loop  (cost=0.29..93.81 rows=1 width=16)
   ->  Index Scan using tbl_c_pkey on tbl_c c  (cost=0.29..8.30 rows=1 width=8)
         Index Cond: (id = 500)
   ->  Seq Scan on tbl_b b  (cost=0.00..85.50 rows=1 width=8)
         Filter: (id = 500)
(5 rows)

使用外表索引扫描的物化嵌套循环连接

testdb=# SET enable_hashjoin TO off;
SET
testdb=# SET enable_mergejoin TO off;
SET
testdb=# EXPLAIN SELECT * FROM tbl_c AS c, tbl_b AS b WHERE c.id = b.id AND c.id < 40 AND b.id < 10;
                                   QUERY PLAN                                    
-------------------------------------------------------------------------------
 Nested Loop  (cost=0.29..99.76 rows=1 width=16)
   Join Filter: (c.id = b.id)
   ->  Index Scan using tbl_c_pkey on tbl_c c  (cost=0.29..8.97 rows=39 width=8)
         Index Cond: (id < 40)
   ->  Materialize  (cost=0.00..85.55 rows=9 width=8)
         ->  Seq Scan on tbl_b b  (cost=0.00..85.50 rows=9 width=8)
               Filter: (id < 10)
(7 rows)

使用外表索引扫描的索引嵌套循环连接

testdb=# SET enable_hashjoin TO off;
SET
testdb=# SET enable_mergejoin TO off;
SET
testdb=# EXPLAIN SELECT * FROM tbl_a AS a, tbl_d AS d WHERE a.id = d.id AND a.id <  40;
                                   QUERY PLAN                                    
-------------------------------------------------------------------------------
 Nested Loop  (cost=0.57..173.06 rows=20 width=16)
   ->  Index Scan using tbl_a_pkey on tbl_a a  (cost=0.29..8.97 rows=39 width=8)
         Index Cond: (id < 40)
   ->  Index Scan using tbl_d_pkey on tbl_d d  (cost=0.28..4.20 rows=1 width=8)
         Index Cond: (id = a.id)
(5 rows)

3.5.2 归并连接（Merge Join）

与嵌套循环连接不同的是，**归并连接（Merge Join）**只能用于自然连接与等值连接。

函数initial_cost_mergejoin()和final_cost_mergejoin()用于估计归并连接的代价。

因为精确估计归并连接的代价非常复杂，因此这里略过不提，只会说明归并连接算法的工作流程。归并连接的启动成本是内表与外表排序成本之和，因此其启动成本为： $$ O(N_{\verb|outer|} \log_2(N_{\verb|outer|}) + N_{\verb|inner|} \log_2(N_{\verb|inner|})) $$ 这里$N_{\verb|outer|}$和$N_{\verb|inner|}$是分别是外表和内表的元组条数，而运行代价是$O(N_{\verb|outer|}+N_{\verb|inner|})$。

与嵌套循环连接类似，归并连接在PostgreSQL中有4种变体。

3.5.2.1 归并连接

图3.20是归并连接的概念示意图。

图3.20 归并连接

如果所有元组都可以存储在内存中，那么排序操作就能在内存中进行，否则会使用临时文件。

下面是一个具体的例子，一个归并连接的EXPLAIN输出如下所示。

# EXPLAIN SELECT * FROM tbl_a AS a, tbl_b AS b WHERE a.id = b.id AND b.id < 1000;
                               QUERY PLAN
-------------------------------------------------------------------------
 Merge Join  (cost=944.71..984.71 rows=1000 width=16)
   Merge Cond: (a.id = b.id)
   ->  Sort  (cost=809.39..834.39 rows=10000 width=8)
         Sort Key: a.id
         ->  Seq Scan on tbl_a a  (cost=0.00..145.00 rows=10000 width=8)
   ->  Sort  (cost=135.33..137.83 rows=1000 width=8)
         Sort Key: b.id
         ->  Seq Scan on tbl_b b  (cost=0.00..85.50 rows=1000 width=8)
               Filter: (id < 1000)
(9 rows)

第9行：执行器对内表tbl_b进行排序，使用顺序扫描（第11行）。
第6行：执行器对外表tbl_a进行排序，使用顺序扫描（第8行）。
第4行：执行器执行归并连接操作，外表是排好序的tbl_a，内表是排好序的tbl_b。

3.5.2.2 物化归并连接

与嵌套循环连接类似，归并连接还支持物化归并连接（Materialized Merge Join），物化内表，使内表扫描更为高效。

图3.21 物化归并连接

这里是物化归并连接的EXPLAIN结果，很容易发现，与普通归并连接的差异是第9行：Materialize。

testdb=# EXPLAIN SELECT * FROM tbl_a AS a, tbl_b AS b WHERE a.id = b.id;
                                    QUERY PLAN                                     
---------------------------------------------------------------------------------
 Merge Join  (cost=10466.08..10578.58 rows=5000 width=2064)
   Merge Cond: (a.id = b.id)
   ->  Sort  (cost=6708.39..6733.39 rows=10000 width=1032)
         Sort Key: a.id
         ->  Seq Scan on tbl_a a  (cost=0.00..1529.00 rows=10000 width=1032)
   ->  Materialize  (cost=3757.69..3782.69 rows=5000 width=1032)
         ->  Sort  (cost=3757.69..3770.19 rows=5000 width=1032)
               Sort Key: b.id
               ->  Seq Scan on tbl_b b  (cost=0.00..1193.00 rows=5000 width=1032)
(9 rows)

第10行：执行器对内表tbl_b进行排序，使用顺序扫描（第12行）。
第9行：执行器对tbl_b排好序的结果进行物化。
第6行：执行器对外表tbl_a进行排序，使用顺序扫描（第8行）。
第4行：执行器执行归并连接操作，外表是排好序的tbl_a，内表是物化的排好序的tbl_b。

3.5.2.3 其他变体

与嵌套循环连接类似，当外表上可以进行索引扫描时，归并连接也存在相应的变体。

图3.22 归并连接的三种变体，使用外表索引扫描

这些连接的EXPLAIN结果如下。

使用外表索引扫描的归并连接

testdb=# SET enable_hashjoin TO off;
SET
testdb=# SET enable_nestloop TO off;
SET
testdb=# EXPLAIN SELECT * FROM tbl_c AS c, tbl_b AS b WHERE c.id = b.id AND b.id < 1000;
                                      QUERY PLAN                                      
------------------------------------------------------------------------------
 Merge Join  (cost=135.61..322.11 rows=1000 width=16)
   Merge Cond: (c.id = b.id)
   ->  Index Scan using tbl_c_pkey on tbl_c c  (cost=0.29..318.29 rows=10000 width=8)
   ->  Sort  (cost=135.33..137.83 rows=1000 width=8)
         Sort Key: b.id
         ->  Seq Scan on tbl_b b  (cost=0.00..85.50 rows=1000 width=8)
               Filter: (id < 1000)
(7 rows)

使用外表索引扫描的物化归并连接

testdb=# SET enable_hashjoin TO off;
SET
testdb=# SET enable_nestloop TO off;
SET
testdb=# EXPLAIN SELECT * FROM tbl_c AS c, tbl_b AS b WHERE c.id = b.id AND b.id < 4500;
                                      QUERY PLAN                                      
-------------------------------------------------------------------------------
 Merge Join  (cost=421.84..672.09 rows=4500 width=16)
   Merge Cond: (c.id = b.id)
   ->  Index Scan using tbl_c_pkey on tbl_c c  (cost=0.29..318.29 rows=10000 width=8)
   ->  Materialize  (cost=421.55..444.05 rows=4500 width=8)
         ->  Sort  (cost=421.55..432.80 rows=4500 width=8)
               Sort Key: b.id
               ->  Seq Scan on tbl_b b  (cost=0.00..85.50 rows=4500 width=8)
                     Filter: (id < 4500)
(8 rows)

使用外表索引扫描的索引归并连接

testdb=# SET enable_hashjoin TO off;
SET
testdb=# SET enable_nestloop TO off;
SET
testdb=# EXPLAIN SELECT * FROM tbl_c AS c, tbl_d AS d WHERE c.id = d.id AND d.id < 1000;
                                      QUERY PLAN                                      
-------------------------------------------------------------------------------
 Merge Join  (cost=0.57..226.07 rows=1000 width=16)
   Merge Cond: (c.id = d.id)
   ->  Index Scan using tbl_c_pkey on tbl_c c  (cost=0.29..318.29 rows=10000 width=8)
   ->  Index Scan using tbl_d_pkey on tbl_d d  (cost=0.28..41.78 rows=1000 width=8)
         Index Cond: (id < 1000)
(5 rows)

3.5.3 散列连接（Hash Join）

与归并连接类似，**散列连接（Hash Join）**只能用于自然连接与等值连接。

PostgreSQL中的散列连接的行为因表的大小而异。如果目标表足够小（确切地讲，内表大小不超过工作内存的25％），那么散列连接就是简单的两阶段内存散列连接（two-phase in-memory hash join） ；否则，将会使用带倾斜批次的混合散列连接（hybrid hash join）。

本小节将介绍PostgreSQL中这两种散列连接的执行过程。

这里省略了代价估算的部分，因为它很复杂。粗略来说，假设向散列表插入与搜索时没有遇到冲突，那么启动和运行成本复杂度都是$O(N_{\verb|outer|} + N_{\verb|inner|})$。

3.5.3.1 内存散列连接

下面将描述内存中的散列连接。

内存中的散列连接是在work_mem中处理的，在PostgreSQL中，散列表区域被称作处理批次（batch）。一个处理批次会有多个散列槽(hash slots)，内部称其为桶（buckets），桶的数量由nodeHash.c中定义的ExecChooseHashTableSize()函数所确定。桶的数量总是2的整数次幂。

内存散列连接有两个阶段：**构建（build）阶段和探测（probe）**阶段。在构建阶段，内表中的所有元组都会被插入到batch中；在探测阶段，每条外表元组都会与处理批次中的内表元组比较，如果满足连接条件，则将两条元组连接起来。

为了理解该操作的过程，下面是一个具体的例子。假设该查询中的连接操作使用散列连接。

SELECT * FROM tbl_outer AS outer, tbl_inner AS inner WHERE inner.attr1 = outer.attr2;

散列连接的过程如图3.23和3.24所示。

图3.23 内存散列连接的构建阶段

在工作内存上创建一个处理批次。

在本例中，处理批次有八个桶；即桶的数量是2的3次方。
将内表的第一个元组插入批次的相应的桶中。

具体过程如下：
1. 找出元组中涉及连接条件的属性，计算其散列键。
  
  在本例中，因为WHERE子句是inner.attr1 = outer.attr2，因此内置的散列函数会对第一条元组的属性attr1取散列值，用作散列键。
2. 将第一条元组插入散列键相应的桶中。
  
  假设第一条元组的散列键以二进制记法表示为0x000 ... 001，即其末三**位（bit）**为001。在这种情况下，该元组会被插入到键为001的桶中。
在本文中，构建处理批次的插入操作会用运算符 ⊕ 表示。
插入内表中的其余元组。

图3.24. 内存散列连接的探测阶段

依外表的第一条元组进行探测。

详情如下：
1. 找出第一条外表元组中涉及连接条件的属性，计算其散列键。
  
  在这个例子中，假设第一条元组的属性attr2的散列键是0x000 ... 100，即其末三**位（bit）**为100。最后三位是100。
2. 将外表中第一条元组与批次中的内表元组进行比较。如果满足连接条件，则连接内外表元组。
  
  因为第一个元组的散列键的末三位为100，执行器找出键为100的桶中的所有内表元组，并对内外表元组两侧相应的属性进行比较。这些属性由连接条件（在WHERE子句中）所指明。
  
  如果满足连接条件，执行器会连接外表中的第一条元组与内表中的相应元组。如果不满足则执行器不做任何事情。
  
  在本例中，键为100的桶中有Tuple_C。如果Tuple_C的attr1等于第一条元组（Tuple_W）的attr2，则Tuple_C和Tuple_W将被连接，并保存至内存或临时文件中。
在本文中，处理批次的探测操作用运算符 ⊗ 表示。
依次对外表中的其他元组执行探测。

3.5.3.2 带倾斜的混合散列连接

当内表的元组无法全部存储在工作内存中的单个处理批次时，PostgreSQL使用带倾斜批次的混合散列连接算法，该算法是混合散列连接的一种变体。

首先，这里会描述混合散列连接的基本概念。在第一个构建和探测阶段，PostgreSQL准备多个批次。与桶的数目类似，处理批次的数目由函数ExecChooseHashTableSize()决定，也总是2的整数次幂。工作内存中只会分配一个处理批次，而其他批次作都以临时文件的形式创建。属于这些批次的元组将通过临时元组存储功能，被写入到相应的文件中。

图3.25说明了如何将元组存储在四个（$ 2 ^ 2 $）处理批次中。在本例中元组散列键的最后五个比特位决定了元组所属的批次与桶，因为处理批次的数量为$2^2$，而桶的数量为$2^3$，因此需要5个比特位来表示，其中前两位决定了元组所属的批次，而后三位决定了元组在该批次中所属的桶。例如：Batch_0存储着散列键介于$\textcolor{red}{00}000$与$\textcolor{red}{00}111$的元组；而Batch_1存储着散列键介于$\textcolor{red}{01}000$与$\textcolor{red}{01}111$的元组，依此类推。

图3.25 混合散列连接中的多个处理批次

在混合散列连接中，构建与探测阶段的执行次数与处理批次的数目相同，因为内外表元组都被存至相同数量的处理批次中。在第一轮构建与探测阶段中，除了处理第一个处理批次，还会创建所有的处理批次。另一方面，第二轮及后续的处理批次都需要读写临时文件，这属于代价巨大的操作。因此PostgreSQL还准备了一个名为skew的特殊处理批次，即倾斜批次，以便在第一轮中高效处理尽可能多的元组。

这个特殊的倾斜批次中的内表元组在连接条件内表一侧属性上的取值，会选用外表连接属性上的高频值（MCV）。因此在第一轮处理中能与外表中尽可能多的元组相连接。这种解释不太好理解，因此下面给出了一个具体的例子。

假设有两个表：客户表customers与购买历史表purchase_history。customers由两个属性组成：name和address； purchase_history由两个属性组成：customer_name和buying_item。customers有10,000行，而purchase_history表有1,000,000行。前10％的客户进行了70％的购买。

理解了这些假设，让我们考虑当执行以下查询时，带倾斜的混合散列连接的第一轮是如何执行的。

SELECT * FROM customers AS c, purchase_history AS h 
WHERE c.name = h.customer_name;

如果customers是内表，而purchase_history是外表，则PostgreSQL将使用purchase_history表的高频值值，将前10％的customers元组存储于倾斜批次中。请注意这里引用的是外表上的高频值，而插入倾斜批次的是内表元组。在第一轮的探测阶段，外表（purchase_history）中70％的元组将与倾斜批次中存储的元组相连接。因此，外表分布越是不均匀，第一轮中越是可以处理尽可能多的元组。

接下来会介绍带倾斜批次的混合散列连接的工作原理，如图3.26至3.29所示。

图3.26 混合散列连接的构建阶段的第一轮

在工作内存中创建一个处理批次，以及一个倾斜批次。
创建处理批次相应的临时文件，用于存储排好序的内表元组。

在本例中，内表被分割为四个批次，因此创建了三个批次文件。
为内表的第一条元组执行构建操作。

细节如下：
1. 如果第一条元组应当插入倾斜批次中，则将其插入倾斜批次；否则继续下一步。
  
  在该例中，如果第一条元组属于前10％的客户，则将其插入到倾斜批次中。
2. 计算第一条元组的散列键，然后将其插入相应的处理批次。
对内表其余元组依次执行构建操作。

图3.27 混合散列连接，探测阶段第一轮

创建临时处理批次文件，用于外表排序。
为外表的第一条元组执行探测操作，如果外表第一条元组上相应字段取值为MCV，则在倾斜批次上进行探测，否则进行第七步。

在本例中，如果第一条元组是前10％客户的购买数据，则它会与倾斜批次中的内表元组进行比较。
为外表的第一条元组执行探测操作。

操作的内容取决于该元组散列键的取值。如果该元组属于Batch_0则直接完成探测操作；否则将其插入相应的外表处理批次中。
为外表的其余元组执行探测操作。

注意在本例中，外表中70％的元组已经在第一轮中的倾斜批次中处理了。

图3.28 构建阶段与探测阶段，第二轮

移除倾斜批次与Batch_0，为下一轮处理批次腾地方。
为批次文件batch_1_in中的内表元组执行构建操作。
为批次文件batch_1_out中的外表元组依次执行探测操作。

图3.29 构建阶段与探测阶段，第三轮及后续

为批次文件batch_2_in与batch_2_out执行构建操作与探测操作。
为批次文件batch_3_in与batch_3_out执行构建操作与探测操作。

3.5.4 连接访问路径与连接节点

3.5.4.1 连接访问路径

嵌套循环连接的访问路径由JoinPath结构表示，其他连接访问路径，诸如MergePath与HashPath都基于其实现。

下图列出了所有的连接访问路径，细节略过不提。

图3.30 Join访问路径

typedef JoinPath NestPath;

typedef enum JoinType
{
        /* 根据SQL JOIN语法确定的标准连接种类，解析器只允许输出这几种取值。
         * (例如JoinExpr节点) */
        JOIN_INNER,           /* 仅包含匹配的元组对 */
        JOIN_LEFT,            /* 匹配元组对 + 未匹配的左表元组 */
        JOIN_FULL,            /* 匹配元组对 + 未匹配的左右表元组  */
        JOIN_RIGHT,           /* 匹配元组对 + 未匹配的右表元组  */
        /* 关系理论中的半连接(semijoin)与否定半连接(anti-semijoin)并没有用SQL JOIN
         * 语法来表示，而是用另一种风格标准来表示(举个例子，EXISTS)。计划器会认出这些情景
         * 并将其转换为连接。因此计划器与执行器必须支持这几种取值。注意：对于JOIN_SEMI的
         * 输出而言，连接到哪一条右表元组是不确定的。而对于JOIN_ANTI的输出而言，会保证使用
         * 空值进行行扩展。*/
        JOIN_SEMI,            /* 左表元组的一份拷贝，如果该元组有相应匹配 */
        JOIN_ANTI,            /* 右表元组的一份拷贝，如果该元组有相应匹配 */
        /* 这几种代码用于计划器内部，执行器并不支持。(其实大多数时候计划器也不会用)   */
        JOIN_UNIQUE_OUTER,    /* 左表路径必须是UNIQUE的 */
        JOIN_UNIQUE_INNER     /* 右表路径必须是UNIQUE的 */
} JoinType;

typedef struct JoinPath
{
	Path	   path;
	JoinType   jointype;
	Path	   *outerjoinpath;		/* 连接外表一侧的路径 */
	Path	   *innerjoinpath;		/* 连接内表一侧的路径 */
	List	   *joinrestrictinfo;	/* 连接所适用的限制信息 */
	/* 参考RelOptInfo与ParamPathInfo才能理解为什么JoinPath需要有joinrestrictinfo
	 * 且不能合并到RelOptInfo中。 */
} JoinPath;

typedef struct MergePath
{
	JoinPath   jpath;
	List	   *path_mergeclauses;	/* 归并所需的连接子句 */
	List	   *outersortkeys;		/* 用于外表显式排序的键，如果存在 */
	List	   *innersortkeys;		/* 用于内表显式排序的键，如果存在 */
	bool	   materialize_inner;	/* 为内表执行物化过程? */
} MergePath;

3.5.4.2 连接节点

本小节列出了三种连接节点：NestedLoopNode，MergeJoinNode 和HashJoinNode，它们都基于JoinNode实现，细节略过不提。

/* ----------------
 *        连接节点
 *
 * jointype:    连接左右子树元组的规则
 * joinqual:    来自 JOIN/ON 或 JOIN/USING 的连接限定条件
 *                (plan.qual 包含了来自WHERE子句的条件)
 *
 * 当jointype为INNER时，joinqual 与 plan.qual 在语义上可以互换。对于OUTER而言这两者
 * 则无法互换；只有joinqual会被用于匹配判定，以及是否需要生成空值扩展的元组。
 * (但 plan.qual 仍然会在实际返回一条元组前生效。)
 * 对于外连接而言，只有joinquals能被用于归并连接或散列连接的连接条件。
 * ----------------
 */
typedef struct Join
{
    Plan        plan;
    JoinType    jointype;
    List        *joinqual;    /* 连接条件 (除 plan.qual 外) */
} Join;

/* ----------------
 *        嵌套循环连接节点
 * 
 * nestParams的列表标识出了执行器所需的参数，这些参数从外表子计划中的当前行获取，
 * 并传入内表子计划中用于执行。当前我们限制这些值为简单的Vars，但也许某一天这一限制
 * 会放松。（注意在创建执行计划期间，paramval实际上可能是一个PlaceHolderVar表达式；
 * 但当其进入执行器时，它必须转换为varno为OUTER_VAR的Var。）
 * ----------------*/
typedef struct NestLoop
{
    Join       join;
    List       *nestParams;   /* NestLoopParam 节点的列表*/
} NestLoop;

typedef struct NestLoopParam
{
    NodeTag   type;
    int       paramno;        /* 需要配置的PARAM_EXEC参数数量 */
    Var       *paramval;      /* 需要赋值给Param的外表变量 */
} NestLoopParam;

/* ----------------
 *        归并连接节点
 * 
 * 待归并列上期待的顺序是通过一个btree运算符族的OID，一个排序规则的OID，一个方向字段
 * （BTLessStrategyNumber 或 * BTGreaterStrategyNumber)，以及一个 NULL FIRST
 * 标记位描述的。注意归并语句的两侧可能是不同的数据类型，但它们会按照共同的运算符族与排序
 * 规则，以同样的方式排序。每个归并子句中的算子必须为相应运算符族中的等值运算。
 * ---------------- */
typedef struct MergeJoin
{
    Join    join;
    List    *mergeclauses;        /* mergeclauses 是一颗表达式树 */
    /* 这些字段都是数组，但与mergeclauses列表有着同样的长度： */
    Oid     *mergeFamilies;      /* B树运算符族的OID列表，每条子句一个 */
    Oid     *mergeCollations;    /* 排序规则的OID列表，每条子句一个 */
    int     *mergeStrategies;    /* 顺序(ASC 或 DESC)的列表，每条子句一个 */
    bool    *mergeNullsFirst;    /* 空值顺序，每条子句一个  */
} MergeJoin;


/* ----------------
 *        散列连接节点
 * ---------------- */
typedef struct HashJoin
{
    Join    join;
    List    *hashclauses;
} HashJoin;

3.6 创建多表查询计划树

本节将说明多表查询计划树的创建过程。

3.6.1 预处理

预处理由planner.c中定义的subquery_planner()函数执行。第3.3.1节已经描述了单表查询的预处理。本节将描述多表查询的预处理；尽管这块内容很多，但这里只会挑其中一部分来讲。

对CTE进行计划与转换

如果存在WITH列表，计划器就会通过SS_process_ctes()函数对每个WITH查询进行处理。
上拉子查询

如果FROM子句带有一个子查询，且该子查询没用用到GROUP BY，HAVING，ORDER BY，LIMIT和DISTINCT，INTERSECT或EXCEPT，那么计划器会使用pull_up_subqueries()函数将其转换为连接形式。例如下面一个FROM子句含子查询的查询就可以被转换为自然连接查询。自不必说，这种转换是在查询树上进行的。
```
# SELECT * FROM tbl_a AS a, (SELECT * FROM tbl_b) as b WHERE a.id = b.id;
                  ↓
# SELECT * FROM tbl_a AS a, tbl_b as b WHERE a.id = b.id;
```
将外连接转为内连接

如果可能的话，计划器会将OUTER JOIN查询转换为INNER JOIN查询。

3.6.2 获取代价最小的路径

为了获取最佳计划树，计划器必须考虑各个索引与各种连接方法之间的所有可能组合。如果表的数量超过某个水平，该过程的代价就会因为组合爆炸而变得非常昂贵，以至于根本不可行。

幸运的是，如果表的数量小于12张，计划器可以使用动态规划来获取最佳计划；否则计划器会使用遗传算法。详情如下：

基因查询优化器

当执行一个多表连接查询时，大量时间耗费在了优化查询计划上。为了应对这种情况，PostgreSQL实现了一个有趣的功能：基因查询优化器。这种近似算法能在合理时间内确定一个合理的计划。因此在查询优化阶段，如果参与连接的表数量超过参数geqo_threshold指定的阈值（默认值为12），PostgreSQL将使用遗传算法来生成查询计划。

使用动态规划确定最佳计划树的过程，其步骤如下：

第一层

获得每张表上代价最小的路径，代价最小的路径存储在表相应的RelOptInfo结构中。
第二层

从所有表中选择两个表，为每种组合找出代价最低的路径。

举个例子，如果总共有两张表，表A与表B，则表A和B表连接的各种路径中，代价最小的那条即为最终想要的答案。在下文中，两个表的RelOptInfo记做${A,B}$。

如果有三个表，则需要获取${A,B}, {A,C},{B,C}$三种组合里各自代价最小的路径。
第三层及其后

继续进行同样的处理，直到层级等于表数量。

通过这种方式，在每个层级都能解决最小代价问题的一部分，且其结果能被更高层级的计算复用，从而使代价最小的计划树能够被高效地计算出来。

图3.31 如何使用动态规划获取代价最小的访问路径

接下来会针对下面的查询，解释计划器是如何获取代价最小的计划的。

testdb=# \d tbl_a
     Table "public.tbl_a"
 Column |  Type   | Modifiers 
--------+---------+-----------
 id     | integer | not null
 data   | integer | 
Indexes:
    "tbl_a_pkey" PRIMARY KEY, btree (id)

testdb=# \d tbl_b
     Table "public.tbl_b"
 Column |  Type   | Modifiers 
--------+---------+-----------
 id     | integer | 
 data   | integer | 

testdb=# SELECT * FROM tbl_a AS a, tbl_b AS b WHERE a.id = b.id AND b.data < 400;

3.6.2.1 第一层的处理

在第一层中，计划器会为查询中涉及的关系创建相应的RelOptInfo结构，并估计每个关系上的最小代价。在这一步中，RelOptInfo结构会被添加至该查询对应PlannerInfo的simple_rel_arrey数组字段中。

图3.32 第一层处理后的PlannerInfo与RelOptInfo

表tbl_a的RelOptInfo有三条访问路径，它们被添加至RelOptInfo的路径列表中。这三条路径分别被三个指针所链接，即三个指向代价最小路径的指针：启动代价最小的路径，总代价最小的路径，参数化代价最小的路径。启动代价最小的路径与总代价最小的路径涵义显而易见，因此，这里只会说一下参数化索引扫描代价最小的路径（cheapest parameterized index scan path）。

如3.5.1.3节所述，计划器会考虑为索引嵌套循环连接使用参数化路径（parameterized path）（极少数情况下也会用于带外表索引扫描的索引化归并连接）。参数化索引扫描代价最小的路径，就是所有参数化路径中代价最小的那个。

表tbl_b的RelOptInfo仅有顺序扫描访问路径，因为tbl_b上没有相关索引。

3.6.2.2 第二层的处理

在第二层中，计划器会在PlannerInfo的join_rel_list字段中创建一个RelOptInfo结构。然后估计所有可能连接路径的代价，并且选择代价最小的那条访问路径。 RelOptInfo会将最佳访问路径作为总代价最小的路径，如图3.33所示。

图3.33 第二层处理后的PlannerInfo和RelOptInfo

表3.1展示了本例中连接访问路径的所有组合。本例中查询的连接类型为等值连接（equi-join），因而对全部三种连接算法进行评估。为方便起见，这里引入了一些有关访问路径的符号：

SeqScanPath(table)表示表table上的顺序扫描路径。
Materialized -> SeqScanPath(table)表示表table上的物化顺序扫描路径。
IndexScanPath(table,attribute)表示按表table中属性attribute上的索引扫描路径。
ParameterizedIndexScanPath(table,attribute1,attribute2)表示表table中属性attribute1上的参数化索引路径，并使用外表上的属性attribute2参数化。

表 3.1 此示例中的所有连接访问路径组合

嵌套循环连接

外表路径	内表路径	备注
`SeqScanPath(tbl_a)`	`SeqScanPath(tbl_b)`
`SeqScanPath(tbl_a)`	`Materialized -> SeqScanPath(tbl_b)`	物化嵌套循环链接
`IndexScanPath(tbl_a,id)`	`SeqScanPath(tbl_b)`	嵌套循环连接，走外表索引
`IndexScanPath(tbl_a,id)`	`Materialized -> SeqScanPath(tbl_b)`	物化嵌套循环连接，走外表索引
`SeqScanPath(tbl_b)`	`SeqScanPath(tbl_a)`
`SeqScanPath(tbl_b)`	`Materialized -> SeqScanPath(tbl_a)`	物化嵌套循环连接
`SeqScanPath(tbl_b)`	`ParametalizedIndexScanPath(tbl_a, id, tbl_b.id)`	索引嵌套循环连接

归并连接

外表路径	内表路径	备注
`SeqScanPath(tbl_a)`	`SeqScanPath(tbl_b)`
`IndexScanPath(tbl_a,id)`	`SeqScanPath(tbl_b)`	用外表索引做归并连接
`SeqScanPath(tbl_b)`	`SeqScanPath(tbl_a)`

哈希连接

外表路径	内表路径	备注
`SeqScanPath(tbl_a)`	`SeqScanPath(tbl_b)`
`SeqScanPath(tbl_b)`	`SeqScanPath(tbl_a)`

例如在嵌套循环连接的部分总共评估了七条连接路径。第一条表示在外表tbl_a和内表tbl_b上都使用顺序扫描路径；第二条表示在外表tbl_a上使用路径顺序扫描路径，而在内表tbl_b上使用物化顺序扫描路径，诸如此类。

计划器最终从估计的连接访问路径中选择代价最小的那条，并且将其添加至RelOptInfo{tbl_a,tbl_b}的路径列表中，如图3.33所示。

在本例中，如下面EXPLAIN的结果所示，计划器选择了在内表tbl_b和外表tbl_c上进行散列连接。

testdb=# EXPLAIN  SELECT * FROM tbl_b AS b, tbl_c AS c WHERE c.id = b.id AND b.data < 400;
                              QUERY PLAN                              
----------------------------------------------------------------------
 Hash Join  (cost=90.50..277.00 rows=400 width=16)
   Hash Cond: (c.id = b.id)
   ->  Seq Scan on tbl_c c  (cost=0.00..145.00 rows=10000 width=8)
   ->  Hash  (cost=85.50..85.50 rows=400 width=8)
         ->  Seq Scan on tbl_b b  (cost=0.00..85.50 rows=400 width=8)
               Filter: (data < 400)
(6 rows)

3.6.3 获取三表查询代价最小的路径

涉及三个表的查询，其代价最小的路径的获取过程如下所示：

testdb=# \d tbl_a
     Table "public.tbl_a"
 Column |  Type   | Modifiers 
--------+---------+-----------
 id     | integer | 
 data   | integer | 

testdb=# \d tbl_b
     Table "public.tbl_b"
 Column |  Type   | Modifiers 
--------+---------+-----------
 id     | integer | 
 data   | integer | 

testdb=# \d tbl_c
     Table "public.tbl_c"
 Column |  Type   | Modifiers 
--------+---------+-----------
 id     | integer | not null
 data   | integer | 
Indexes:
    "tbl_c_pkey" PRIMARY KEY, btree (id)

testdb=# SELECT * FROM tbl_a AS a, tbl_b AS b, tbl_c AS c 
testdb-#                WHERE a.id = b.id AND b.id = c.id AND a.data < 40;

第一层：

计划器估计所有表上各自开销最小的路径，并将该信息存储在表相应的RelOptInfos结构{tbl_a}，{tbl_b}，{tbl_c}中。
第二层：

计划器从三个表中选出两个，列出所有组合，分别评估每种组合里代价最小的路径。然后，规划器将信息存储在组合相应的RelOptInfos结构中：{tbl_a,tbl_b}，{tbl_b,tbl_c}和{tbl_a,tbl_c}中。
第三层：

计划器根据所有已获取的RelOptInfos，选择代价最小的路径。更确切地说，计划器会考虑三种RelOptInfos组合：{tbl_a,{tbl_b,tbl_c}}，{tbl_b,{tbl_a,tbl_c}}和{tbl_c,{tbl_a,tbl_b}}，而{tbl_a,tbl_b,tbl_c}如下所示：

$$ \begin{equation} {\verb|tbl_a|,\verb|tbl_b|,\verb|tbl_c|} = \ \mathrm{min}({\verb|tbl_a|,{\verb|tbl_b|,\verb|tbl_c|}}, {\verb|tbl_b|,{\verb|tbl_a|,\verb|tbl_c|}}, {\verb|tbl_c|,{\verb|tbl_a|,\verb|tbl_b|}}). \end{equation} $$

计划器会估算这里面所有可能连接路径的代价。

在处理{tbl_c,{tbl_a,tbl_b}}对应的RelOptInfo时，计划器会估计tbl_c和{tbl_a,tbl_b}连接代价最小的路径。本例中{tbl_a,tbl_b}已经选定为内表为tbl_a且外表为tbl_b的散列连接。如先前小节所述，在估计时三种连接算法及其变体都会被评估，即嵌套循环连接及其变体，归并连接及其变体，散列连接及其变体。

计划器以同样的方式处理{tbl_a,{tbl_b,tbl_c}}与{tbl_b,{tbl_a,tbl_c}}对应的RelOptInfo，并最终从所有估好的路径中选择代价最小的访问路径。

该查询的EXPLAIN命令结果如下所示：

最外层的连接是索引嵌套循环连接（第5行），第13行显示了内表上的参数化索引扫描，外表则是一个散列连接的结果该散列连接的内表是tbl_a，外表是tbl_b（第7-12行）。因此，执行程序首先执行tbl_a和tbl_b上的散列连接，再执行索引嵌套循环连接。

参考文献

[1] Abraham Silberschatz, Henry F. Korth, and S. Sudarshan, “Database System Concepts”, McGraw-Hill Education, ISBN-13: 978-0073523323
[2] Thomas M. Connolly, and Carolyn E. Begg, “Database Systems”, Pearson, ISBN-13: 978-0321523068

Pigsty 博客

新闻

Pigsty 0.9 新功能介绍

v0.9 Highlight

易用性优化：一键安装

日志收集

命令行工具

图形用户界面

Pigsty GUI

Pigsty监控系统的UI

飞升

CMDB

分析

Datalet

展望未来

Pigsty现已加入阿里云PgSQL七天训练营课程体系

PG Conf China 2020

分享内容

大会议程

紧急通知

2020数据库嘉年华分享

分享内容

PG Conf China 2019

分享内容

Pigsty在线直播：开源PG全家桶上手指南

开源PG全家桶上手指南

谁会感兴趣？

相关分享

需要准备什么？

版本

v0.9.0 发布注记

新功能

问题修复

参数变更

v0.8.0 发布注记

改动内容

API变更

服务管理

数据库管理

旧接口定义

新的接口定义

v0.7.0 发布注记

改动内容

Features

Bug Fix

API变更

仅监控模式

数据库管理

旧接口定义

新的接口定义

接口变更

数据库变更

用户管理

旧接口定义

新接口定义

接口变更

用户管理

v0.6.0 发布注记

BUG修复

功能改进

接口变更

v0.5.0 发布注记

大纲

定制数据库

数据库模板

权限模型

供给方式

v0.4.0 发布注记

Pigsty开源版

软件升级

其他改进

离线安装包

v0.3.0 发布注记

监控系统

离线安装包

文章

开箱即用的PG发行版：Pigsty

什么是Pigsty

谁会感兴趣？

全面专业的监控系统