PostgreSQL 12 首个版本说明草案发布

来源: OSCHINA
编辑: 局长
2019-05-14 06:59:00

虽然 PostgreSQL 12 尚未发布,不过开发团队已公布其首个版本说明草案。据官方介绍,这是一个十分重要的版本,下面看看有哪些值得关注的变化。

对于从任意旧版本迁移到 PostgreSQL 12 的用户,需要使用 pg_dumpall 或 pg_upgrade 进行 dump/restore(备份和恢复) 操作。

PostgreSQL 12 还包含许多可能影响与旧版本之间的兼容性的变更:

  • 删除系统列 OID 的某些特殊行为

    旧版本中,在创建表时可以通过WITH OIDS指定正常情况下不可见(normally-invisible)的 OID 列;在新版本中该特性已被删除,不过列仍可以被显式地指定为OID类型。

  • 删除数据类型abstimereltimetinterval

  • 删除时间段扩展(timetravel extension)

  • recovery.conf设置移动至postgresql.conf

    recovery.conf将不再被使用,如果该文件仍存在,服务器将无法启动。

  • 不再允许多种不同的recovery_target* 规范

    旧版本中,可指定多个不同的 recovery_target*变量,现在只能指定一个。

  • 导致需要恢复的情况将默认使用最新状态

    具体来说,recovery_target_time现在的默认值为latest,而旧版本的默认值为current

  • 重构几何函数和运算符

    会使得结果更准确,但和旧版本相比略有不同

  • 重构几何类型以更加一致地处理 NaN、下溢、上溢和除零情况

  • 改进社区报告的针对行数据类型的行为和错误

分区方面也有不少的改进:

  • 提高分区表上许多操作的性能

    现在可以有效地对数以千计的分区进行修剪

  • 允许外键引用分区表

  • 提高COPY分区表的速度

  • 允许将分区边界设置为任意表达式

  • 允许CREATE TABLE分区表的表空间规范影响其子表空间

此外还有索引、认证、监控和功能优化等诸多变化。由于内容十分多,建议直接查看原文

展开阅读全文
精彩评论

引用来自“霡霂”的评论

关系数据库还是转向New SQL 才是未来。

引用来自“冰力”的评论

@霡霂 很多场景转不了,而且更多场景根本没必要转。
那就看这个产品的支持力度了,比如TIDB,MySQL兼容做的非常好,如果是一个小项目,在语法用法层面,感觉不到区别。如果幸运的摊上一个大项目,那点兼容性的问题,先不说会不会遇到兼容性问题,真遇到了也不是个事,总比折腾一堆分库分表或者、高可用的中间件轻松。不过TiDB的硬件要求有点高,CockroachDB就比较皮实了,你完全可以用一堆树莓派搭建一个非常稳定可靠的高性能的存储集群。
2019-05-14 14:33
4
举报
PG大法好
2019-05-14 11:35
4
举报

引用来自“霡霂”的评论

关系数据库还是转向New SQL 才是未来。
new SQL是什么?
2019-05-14 13:22
3
举报

引用来自“霡霂”的评论

关系数据库还是转向New SQL 才是未来。

引用来自“冰力”的评论

@霡霂 很多场景转不了,而且更多场景根本没必要转。

引用来自“霡霂”的评论

那就看这个产品的支持力度了,比如TIDB,MySQL兼容做的非常好,如果是一个小项目,在语法用法层面,感觉不到区别。如果幸运的摊上一个大项目,那点兼容性的问题,先不说会不会遇到兼容性问题,真遇到了也不是个事,总比折腾一堆分库分表或者、高可用的中间件轻松。不过TiDB的硬件要求有点高,CockroachDB就比较皮实了,你完全可以用一堆树莓派搭建一个非常稳定可靠的高性能的存储集群。

引用来自“shifeng1983”的评论

CAP理论就让你这么给突破了?

引用来自“霡霂”的评论

没get到我说的和cap哪里冲突了,还请指明,感谢。

引用来自“shifeng1983”的评论

分布式的主要问题就是慢,时间都消耗在网络传输上了,如果用一堆树莓派能解决的问题,那用电脑单机一定也能解决。好的做法是业务拆分一下,或者用异构数据库,基本上能解决99%的问题,
你理解错了。“可以用一堆树莓派搭建一个非常稳定可靠的高性能的存储集群”这句话是用来表达TiDB对硬件要求高。另外,无论是TiDB、还是CockroachDB、或者Greenplum,亦或是google的spanner,都不是强一致性(那是传统关系数据库的强项),而是采用的最终一致性,只要是最终一致性,没有不出现数据延迟的。但是最终一致性并不违反cap理论,而是cap理论阐述的一部分。另外虽然性能很重要,但不是性能并不是考察分布式系统的唯一指标。
10个树莓派节点的吞吐量可能比不上一台服务器,但是100个节点呢?一台单机,宕机后就无法提供服务了,但是对于100个树莓派节点的CockroachBD集群来说,即便宕机一半(50个节点),仍然可以提供服务,哪怕这50个树莓派的硬盘完全被损坏,集群中的数据仍然不会丢失(一条数据记录在CockrochDB集群中至少有3个数据副本,分布在不同的节点上),假如说,100个节点仍然不能满足性能需求,或者存储量不足,直接增加新的节点,由集群自动的对数据进行分布,创建副本等(水平可伸缩性)。
真遇到了单机性能问题,业务拆分或者使用异构数据库,并不能真的解决问题,分布式(sharding)和集群是绕不过的坎。无论你是将业务拆分到不同的数据库中(垂直切分),还是对业务量大的数据表进行分片(水平切分),都需要对项目本身的架构进行大的调整,以应对分布式事务和数据切分的难题,但是使用NewSQL,这些都不是问题,简单说,你可以像写单机应用一样完成一个分布式系统的开发。不过CockroachDB等面对的业务场景,更多的是微服务、大数据量、高负载的场景。
2019-05-16 10:31
2
举报

引用来自“霡霂”的评论

关系数据库还是转向New SQL 才是未来。

引用来自“朝半仙”的评论

new SQL是什么?
对关系型数据库的重新定义。原生的、透明支持分布式和高可用。不在再产品中引入一堆切分的中间件。参见TIDB、CockroachDB、Greenplum。
2019-05-14 13:36
2
举报
19 收藏
分享
21 评论
19 收藏
分享
返回顶部
顶部
返回顶部
顶部