PostgreSQL 大佬给我的四个问题与Postgresql 改进

微信,说去测测 PolarDB for PostgreSQL , 业界大佬发话,岂敢不从. 下面是大佬给留下的问题,从这些问题看,都是对PG存在的一些问题的改进.

在测试之前首先要了解polardb for postgresql, polardb是一款基于postgresql 的share-nothing的分布式数据库.支持高可用,数据冗余以及全局数据一致性和ACID的特性.同时polardb坚持最大化的支持单机版的postgresql的语法以及相关的兼容性.其中特点是,通过时间方式来进行分布式事务的处理.

通过extension的方式来完成分布式事务的管理,元数据的管理,集群的管理,其目标为更容易的升级,更容易被部署和使用.

其中polardb可以在阿里云上找到, 通过docker来进行部署,也支持通过源码来进行相关的部署工作.

安装

1 准备至少3台机器, 或者一台机器也可,一台机器是模拟三台,使用不同的端口

2 操作系统centos 7.2 及以上, GCC 4.8.5, 安装perl 依赖包

3 关闭防火墙

systemctl stop firewalld systemctl disable firewalld

4 机器之间免密SSH

5 在所有的机器上安装依赖包

sudo yum install bison flex libzstd-devel libzstd zstd cmake openssl-devel protobuf-devel readline-devel libxml2-devel libxslt-devel zlib-devel bzip2-devel lz4-devel snappy-devel python-devel

6 下载地址 https://github.com/alibaba/PolarDB-for-PostgreSQL

7 按照相关文档的环境配置一下

8 打开安装包直接onekey.sh (可以建立一个polardb的账号) 将三个节点安装到一台机器

安装完毕后,直接登录到PG的数据库中

至此,奇幻的旅程就开始了.

首先我们先来一遍感官印象, 下面是一个三个节点的安装在一台机器的 polardb for postgresql, 从下面的后台的三个节点执行的backend process , 可以捕捉到几个点.

这是一个三节点的postgresql 并且与我们熟知的一些后台进程有不同,三个节点分别是 dn_master, dn_slave , dn_learner . 从dn_master 中我们可以发现每个节点都多了一个后台我们不认识的进程 consensus .

下面就从个人观点来对大佬的4个问题猜猜看

1 为什么去掉FPW

首先FPW 是什么 full page writes , 这个选项使用PG的都知道,如果你想保证你的数据库在CRASH 后数据页面如果被损坏后数据还想正常拉起来, 那个FPW是必须要开的. 那么大佬的问题是,为什么要去掉 FPW, 那么必有蹊跷,

思路就得打开.

不要用单机的思路来在去想POSTGRESQL 或者说是polardb, 要用集群的观点来去想了,

1 这个设计里面的思路是分布式集群,也就是每次系统都是至少为三个节点的"postgresql". 并且host_standby = on , 在这样的情况下,如果主节点挂了,那么必然有从节点并且是数据一致的方式顶上, 此时full page writes存在的意义在哪里, standby 节点就是保证数据完整性的依靠.

同时如果说从数据传输方面去想, 那么必然希望数据传输性能的提高, FPW本身不光是降低系统写I/O的性能,同时也会对网络多节点传输造成负担,所以FPW被去掉也是必然,当然还有一点这里就不说了.

2 为什么数据库高并发读写时数据库的性能会严重下降?

这个问题其实个人觉得难度不低了, 这就要从几个方面考虑高并发时会遇到什么问题, 1 高并发读,高并发读必然触发大量的SNAPSHOT , 大量的SNAPSHOT 处理必然耗费大量的资源, 此时还是不要被束缚在单机的想法里面,从分布式的角度看,目前大部分分布式数据库的设计中必然会有一个"时间"的设计,也就是事务执行的顺序性必然要通过时间的概念通过时间戳,来为分布式的数据库的事务分发事务的ID, 以及通过时间来进行SNAPSHOT 排序,这也是目前大部分分布式数据库的通用的做法了.

2 高并发写, 高并发写主要要考虑的问题,还是要从分布式的角度考虑, 这里考虑有几个问题 1 高并发写的带来的获取事务ID资源的问题, 一般来说如果不使用时间来做的话, 采用锁处理,可以是读写锁,或者是自旋锁, 分布式高并发的性能瓶颈就在于事务的全局ID分发和MVCC的处理上,当然在分布式的POSTGRES-XL中隔离级别也是一个影响性能的关键点,所以POSTGRES-XL 一般都不选择RC.

相信通过时间方式来对集群事务进行处理后,必然会解决这个问题. 同时如果通过时间方式来对整体的集群的事务进行管理后, vacuum 的方式也会改变.

3 怎么样才让PG的高可用方案做到0数据丢失?

要达到目标,这里要考虑两个方面, 单点的数据0丢失和分布式事务的完整性的问题,单点0数据丢失的问题. 如完善的日志系统, full page writes 等等,但要针对分布式系统要完成和解决的问题有

1 数据复制问题,数据在多个节点复制必须保证大多数节点数据一致,和所有节点数据最终一致.这里使用PG的同步复制,异步复制是可以达到目地的.

2 节点切换的过程中,需要使用分布式协议,raft, paxos都可以,基于这些协议的高可用的数据节点一般等于大于3个.

几个需要在高可用中解决的问题, 1, 节点中大多数节点与主节点一致,怎么判断出大多数的节点, 这个需要master来进行判断 2 切换过程中需要判断切换的follower节点在wal 日志是否与主节点一致, 这就需要主节点发送日志的标志位给follower节点,这样在切换中保证切换的节点与主节点是完全一致的. 这里猜测,下图的两个目录是否就是完成上面功能的痕迹.

4 为什么数据库崩溃后恢复总是慢悠悠?

这个问题不光是在postgresql, 在mysql中也是一样,这就牵扯到checkpoint点后的系统crash后,利用日志来进行数据恢复的问题了, 需要重做的日志越多,则数据库崩溃后恢复的速度会越慢. 有没有办法解决,关键的核心在于数据恢复是否可以并行恢复,如果是按照wal 日志的顺序自然是不好打理, 但如果我们换一个思路, 数据的最终一致性,基于postgresql 的数据页面,将日志批量读取,并且根据数据页面的重做进行多个线程的操作并将有关联性的顺序,无关联性的并行,这个问题就可以解决了.

以上的内容都属于猜的性质,从中也可以体会到单体的数据库与分布式数据库之间的思维的方式的改变.基于分布式的数据库在数据的承载量和计算机的速度方面等等,在性能优化出现问题的的思路也和单体的数据库不同,所以DBA在使用分布式数据库的思路也要变化应对变化的环境.