开头还是介绍一下群,如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, Oceanbase, Sql Server等有问题,有需求都可以加群群内有各大数据库行业大咖,CTO,可以解决你的问题。加群请联系 liuaustin3 ,(共2150人左右 1 + 2 + 3 + 4 +5) 新人直接分配到5群,另欢迎 OpenGauss 的技术人员加入。
这题目让我想起非诚勿扰电影里面的台词,有意思吗?有意思呀!PostgreSQL 有意思,PolarDB for PostgreSQL 有意思。
大部分在PolarDB for MySQL 有的特性在 PolarDB for PostgreSQL 都可以使用。同时PolarDB for PostgreSQL 有一个开源的版本,也就是线下可以部署,这在整体的生态上是完整的,基于一些金融机构有线上和线下部署的数据同步的需求,那么这样的整体的解决方案对于一些机构来说是完整的,可控的。
从上图可以看到PolarDB for PostgreSQL 的部分在数据同步中,使用了方式是通过内存进行数据同步的方式,通过wal meta queue 从日志中同步化基础数据到Polardb 的从节点。并且将这些信息直接同步到从节点的shared buffer pool 中,同时下面也会将日志同步刷新到磁盘上,如polardb for mysql 一样通过REDO 的日志来进行数据的刷新,通过wal的数据进行从节点的内存的数据的冲刷。
这里注意实线和虚线,数据同步的同步和异步的数据同步的方式。基于这样的形式的数据的,主从节点数据的节点之间的延迟,我们是期待的,理论上比POSTGRESQL RDS 的 主从数据同步应该是要好的多,这样的方式在 POLARDB FOR MYSQL 上是有验证的,延迟有没有,有但是基本上在20ms 内,甚至更低。
所以如果Polardb for PostgreSQL的主从节点之间的数据差异在20ms内,对于读写分离来说,将不需要业务在去考虑这方面的基础架构的设计。
除此之外,我们对于下面的一些特性更加的有兴趣
1 数据冷热分离,在数据库层面上进行自动分层的技术,在数据存储中,最大的成本来源和可以进行削减的成本,大多来自于存储,类似我们这样的企业,数据一定有冷数据库,将几个T的冷数据如果能通过分层技术,下探到 OSS上,那么存储成本会几何级的下降。但具体的实施和方案,还需要更多的了解。因为这样的冷热分离是从物理上操作,而非业务逻辑上的冷热分离。
2 节点的增加和替换
这点也是我们对于现有的PostgreSQL 有想法的地方,当然可以增加pgbouncer,但是如果有一个能进行读写分离的插件的代理,那么将是我们最高兴 PostgreSQL 具有的功能,这样花一个POSTGRESQL 的钱得到两个节点,和读写分离的代理,最大化一些只读SQL 的自动和主节点的隔离,省时省力。
对于添加只读节点方面我们在POALRDB FOR MYSQL 也有深刻的体会,快速添加节点,如果是 几个T的从库添加那你就等着吧,但基于POALRDB 的 shared storage 和 内存同步数据的方案,几个T的从节点的添加也是在分钟级别可以获得这个能力,这对于突发的事件,要增加只读节点也是一个得心应手得事情。
3 内存全局话的设计
这点在POSTGRESQL 里面你需要使用到 POSTGRESQL 16 可以应用此功能,在POLARDB FOR POSTGRESQL 里面,PG14 就已经有了全局内存管理信息的功能,也就是不在有一个collector 来不断的收集各个客户进程里面的变动的数据信息,而是将这些放到整体的内存中来进行管理,对于节省内存来说有好处。
除此之外,还有ePQ 功能,我们希望能通过ePQ功能,让在原有的CPU 数量上,提升性能 50%,当然这些都需要进行测试和验证。
最后,在相关人员的介绍中,相关的硬件中,以及包含了硬件压缩的芯片,可以在数据存储在磁盘时进行硬件压缩和解压缩,预计可以提高数据存储 30%的平均容量。
所以写到这里,我有点期待后续,如果一个PG,更快,更便宜,更能在低版本使用高版本的一些特性和功能,那倒是有点意思。