<output id="ilehw"><bdo id="ilehw"><nobr id="ilehw"></nobr></bdo></output>
        <dl id="ilehw"><font id="ilehw"></font></dl>
          1. PostgreSQL 12 首个版本说明草案发布

            局长
             局长
            发布于 2019年05月14日
            收藏 19

            虽然 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将不再被使用,如果该文件?#28304;?#22312;,服务器将无法启动。

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

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

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

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

            • 重构几何函数和运算符

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

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

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

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

            • 提高分区表上许多操作的?#38405;?/p>

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

            • 允许外键引用分区表

            • 提高COPY分区表的速度

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

            • 允许CREATE TABLE分区表的表空间规?#38431;?#21709;其子表空间

            此外还有索引、?#29616;ぁ?#30417;控和功能优化等诸多变化。由于内容十分多,建议直接查看原文

            本站文章除注明转载外,均为本站原创或编译。?#38431;?#20219;何?#38382;?#30340;转载,但请务必注明出处,尊重他人劳动共创开源社区。
            转载请注明:文章转载自 OSCHINA 社区 [http://www.bswx.tw]
            本文标题:PostgreSQL 12 首个版本说明草案发布
            加载中

            精彩评论

            s
            shifeng1983

            引用来自“霡霂”的评论

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

            引用来自“冰力”的评论

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

            引用来自“霡霂”的评论

            那就看这个产品的支?#33267;?#24230;了,比如TIDB,MySQL兼容做的非常好,如果是一个小项目,在语法用法层面,感觉不到区别。如果?#20197;说?#25674;上一个大项目,那点兼容性的问题,先不说会不会遇到兼容性问题,真遇到了也不是个事,总?#26085;?#33150;一堆分库分表或者、高可用的中间件轻松。不过TiDB的?#24067;?#35201;求有点高,CockroachDB就比较皮实了,你完全可以用一堆树莓派搭建一个非常稳定可靠的高?#38405;?#30340;存储集群。
            CAP理论就让你这么给突破了?
            霡霂
            霡霂

            引用来自“霡霂”的评论

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

            引用来自“冰力”的评论

            @霡霂 很多场景转不了,而且更多场景根本没必要转。
            那就看这个产品的支?#33267;?#24230;了,比如TIDB,MySQL兼容做的非常好,如果是一个小项目,在语法用法层面,感觉不到区别。如果?#20197;说?#25674;上一个大项目,那点兼容性的问题,先不说会不会遇到兼容性问题,真遇到了也不是个事,总?#26085;?#33150;一堆分库分表或者、高可用的中间件轻松。不过TiDB的?#24067;?#35201;求有点高,CockroachDB就比较皮实了,你完全可以用一堆树莓派搭建一个非常稳定可靠的高?#38405;?#30340;存储集群。
            一号男嘉宾
            一号男嘉宾
            PG大法好
            朝半仙
            朝半仙

            引用来自“霡霂”的评论

            关系数据库还是转向New SQL 才是未来。
            new SQL是什么?
            霡霂
            霡霂

            引用来自“霡霂”的评论

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

            引用来自“代码之美”的评论

            看到你的大放厥词,花了半个小时了解new sql是个什么玩意儿,?#21040;?#23450;义为“分布式关系型数据库?#20445;?#35299;决的痛点是传统关系型数据库主从,多主复杂困难的问题。不管是分布式关系型数据库new sql还是键值型数据库nosql,其都是在特定应用场景下的产物,一个用于弱数据环?#24120;?#19968;个用于大规模数据环?#24120;?#20320;给我说“转向?#20445;?#19981;怕闪掉大牙。

            引用来自“霡霂”的评论

            我们只是技术讨论,你要有什么情绪回家对着你家人撸去,这里没人惯着你。

            引用来自“代码之美”的评论

            没看到你有任何支持你的惊人结论的论据,就一句话扔这了,这算哪门子讨论,哗众取宠吗
            又不是辩论大赛,赢了没有奖金,没有奖品,我至于见了?#21496;?#35299;释一遍吗?另外对于new sql,你真的理解偏了。如果你针对new sql真的?#34892;?#36259;,就好好看看TiDB,CockroachDB的特性和功能。支不支持分布式,与nosql的应用领域关系不大。new sql出现的根本原因还是RMDB数据库的sharding中间件在?#23548;?#24212;用?#24615;?#31957;的表现。当我们不得不使用分布式解决?#38405;?#38382;题的时候要面临以下几个挑战:
            1、如何在实现分布式的同时,减少对业务的影响:对于业务来说,是分布式是透明的(少修改代码,甚至不修改代码,SQL还是SQL);
            2、如何在实现分布式的同时,我如?#25991;?#20570;到高可用,(异地)容灾和恢复;
            3、如何在实现分布式的同时,自由的对数据进行伸缩操作(随时增加服务器节点扩容,而不是担心数据的分布问题);
            4、如何在实现分布式的同时,继续使用事物,以及保证数据一致性;
            5、如何在实现分布式的同时,即可以OLTP,又可以OLAP(传统架构上,OLAP需要建立一个单独的数据仓库)
            6、如何在实现分布式的同时,以上过程尽可能的简单化,更容?#36164;?#29616;自动化。
            从初衷看,new sql是对传统RMDB的改良,大家仍需要RMDB,也想要一个真正简洁可靠的分布式。从长远看,传统的RMDB 更像是New SQL的一个特殊状态,即单节点,上面提到的TIDB和CockroachDB都可以在单节点下运行,而且TIDB兼容MySQL协议,CockroachDB兼容PgSQL,甚至他们的驱动和管理工具可以直接?#32654;从謾?br/>上面提到的两个new sql底层实现上,确实是基于KV存储的(NoSQL),但是对于用户来说接触不到,用户仍然是使用sql。如果说非要说和nosql沾边的话,两者都支持json类型和操作,就像MySQL5.7和PgSQL9.2.0?#24615;?#21152;对json的支持一样。

            最新评论(21

            左华栋
            左华栋

            引用来自“霡霂”的评论

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

            引用来自“代码之美”的评论

            看到你的大放厥词,花了半个小时了解new sql是个什么玩意儿,?#21040;?#23450;义为“分布式关系型数据库?#20445;?#35299;决的痛点是传统关系型数据库主从,多主复杂困难的问题。不管是分布式关系型数据库new sql还是键值型数据库nosql,其都是在特定应用场景下的产物,一个用于弱数据环?#24120;?#19968;个用于大规模数据环?#24120;?#20320;给我说“转向?#20445;?#19981;怕闪掉大牙。

            引用来自“霡霂”的评论

            我们只是技术讨论,你要有什么情绪回家对着你家人撸去,这里没人惯着你。

            引用来自“代码之美”的评论

            没看到你有任何支持你的惊人结论的论据,就一句话扔这了,这算哪门子讨论,哗众取宠吗

            引用来自“霡霂”的评论

            又不是辩论大赛,赢了没有奖金,没有奖品,我至于见了?#21496;?#35299;释一遍吗?另外对于new sql,你真的理解偏了。如果你针对new sql真的?#34892;?#36259;,就好好看看TiDB,CockroachDB的特性和功能。支不支持分布式,与nosql的应用领域关系不大。new sql出现的根本原因还是RMDB数据库的sharding中间件在?#23548;?#24212;用?#24615;?#31957;的表现。当我们不得不使用分布式解决?#38405;?#38382;题的时候要面临以下几个挑战:
            1、如何在实现分布式的同时,减少对业务的影响:对于业务来说,是分布式是透明的(少修改代码,甚至不修改代码,SQL还是SQL);
            2、如何在实现分布式的同时,我如?#25991;?#20570;到高可用,(异地)容灾和恢复;
            3、如何在实现分布式的同时,自由的对数据进行伸缩操作(随时增加服务器节点扩容,而不是担心数据的分布问题);
            4、如何在实现分布式的同时,继续使用事物,以及保证数据一致性;
            5、如何在实现分布式的同时,即可以OLTP,又可以OLAP(传统架构上,OLAP需要建立一个单独的数据仓库)
            6、如何在实现分布式的同时,以上过程尽可能的简单化,更容?#36164;?#29616;自动化。
            从初衷看,new sql是对传统RMDB的改良,大家仍需要RMDB,也想要一个真正简洁可靠的分布式。从长远看,传统的RMDB 更像是New SQL的一个特殊状态,即单节点,上面提到的TIDB和CockroachDB都可以在单节点下运行,而且TIDB兼容MySQL协议,CockroachDB兼容PgSQL,甚至他们的驱动和管理工具可以直接?#32654;从謾?br/>上面提到的两个new sql底层实现上,确实是基于KV存储的(NoSQL),但是对于用户来说接触不到,用户仍然是使用sql。如果说非要说和nosql沾边的话,两者都支持json类型和操作,就像MySQL5.7和PgSQL9.2.0?#24615;?#21152;对json的支持一样。
            postgresql 支持的 jsonb 更加Nosql 。 mysql 的 json 算不上~
            霡霂
            霡霂

            引用来自“霡霂”的评论

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

            引用来自“代码之美”的评论

            看到你的大放厥词,花了半个小时了解new sql是个什么玩意儿,?#21040;?#23450;义为“分布式关系型数据库?#20445;?#35299;决的痛点是传统关系型数据库主从,多主复杂困难的问题。不管是分布式关系型数据库new sql还是键值型数据库nosql,其都是在特定应用场景下的产物,一个用于弱数据环?#24120;?#19968;个用于大规模数据环?#24120;?#20320;给我说“转向?#20445;?#19981;怕闪掉大牙。

            引用来自“霡霂”的评论

            我们只是技术讨论,你要有什么情绪回家对着你家人撸去,这里没人惯着你。

            引用来自“代码之美”的评论

            没看到你有任何支持你的惊人结论的论据,就一句话扔这了,这算哪门子讨论,哗众取宠吗
            又不是辩论大赛,赢了没有奖金,没有奖品,我至于见了?#21496;?#35299;释一遍吗?另外对于new sql,你真的理解偏了。如果你针对new sql真的?#34892;?#36259;,就好好看看TiDB,CockroachDB的特性和功能。支不支持分布式,与nosql的应用领域关系不大。new sql出现的根本原因还是RMDB数据库的sharding中间件在?#23548;?#24212;用?#24615;?#31957;的表现。当我们不得不使用分布式解决?#38405;?#38382;题的时候要面临以下几个挑战:
            1、如何在实现分布式的同时,减少对业务的影响:对于业务来说,是分布式是透明的(少修改代码,甚至不修改代码,SQL还是SQL);
            2、如何在实现分布式的同时,我如?#25991;?#20570;到高可用,(异地)容灾和恢复;
            3、如何在实现分布式的同时,自由的对数据进行伸缩操作(随时增加服务器节点扩容,而不是担心数据的分布问题);
            4、如何在实现分布式的同时,继续使用事物,以及保证数据一致性;
            5、如何在实现分布式的同时,即可以OLTP,又可以OLAP(传统架构上,OLAP需要建立一个单独的数据仓库)
            6、如何在实现分布式的同时,以上过程尽可能的简单化,更容?#36164;?#29616;自动化。
            从初衷看,new sql是对传统RMDB的改良,大家仍需要RMDB,也想要一个真正简洁可靠的分布式。从长远看,传统的RMDB 更像是New SQL的一个特殊状态,即单节点,上面提到的TIDB和CockroachDB都可以在单节点下运行,而且TIDB兼容MySQL协议,CockroachDB兼容PgSQL,甚至他们的驱动和管理工具可以直接?#32654;从謾?br/>上面提到的两个new sql底层实现上,确实是基于KV存储的(NoSQL),但是对于用户来说接触不到,用户仍然是使用sql。如果说非要说和nosql沾边的话,两者都支持json类型和操作,就像MySQL5.7和PgSQL9.2.0?#24615;?#21152;对json的支持一样。
            代码之美
            代码之美

            引用来自“霡霂”的评论

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

            引用来自“代码之美”的评论

            看到你的大放厥词,花了半个小时了解new sql是个什么玩意儿,?#21040;?#23450;义为“分布式关系型数据库?#20445;?#35299;决的痛点是传统关系型数据库主从,多主复杂困难的问题。不管是分布式关系型数据库new sql还是键值型数据库nosql,其都是在特定应用场景下的产物,一个用于弱数据环?#24120;?#19968;个用于大规模数据环?#24120;?#20320;给我说“转向?#20445;?#19981;怕闪掉大牙。

            引用来自“霡霂”的评论

            我们只是技术讨论,你要有什么情绪回家对着你家人撸去,这里没人惯着你。
            new sql的竞争对像更多是mongodb之类的分布式数据库,跟pg八杆子打不着
            代码之美
            代码之美

            引用来自“霡霂”的评论

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

            引用来自“代码之美”的评论

            看到你的大放厥词,花了半个小时了解new sql是个什么玩意儿,?#21040;?#23450;义为“分布式关系型数据库?#20445;?#35299;决的痛点是传统关系型数据库主从,多主复杂困难的问题。不管是分布式关系型数据库new sql还是键值型数据库nosql,其都是在特定应用场景下的产物,一个用于弱数据环?#24120;?#19968;个用于大规模数据环?#24120;?#20320;给我说“转向?#20445;?#19981;怕闪掉大牙。

            引用来自“霡霂”的评论

            我们只是技术讨论,你要有什么情绪回家对着你家人撸去,这里没人惯着你。
            没看到你有任何支持你的惊人结论的论据,就一句话扔这了,这算哪门子讨论,哗众取宠吗
            霡霂
            霡霂

            引用来自“霡霂”的评论

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

            引用来自“代码之美”的评论

            看到你的大放厥词,花了半个小时了解new sql是个什么玩意儿,?#21040;?#23450;义为“分布式关系型数据库?#20445;?#35299;决的痛点是传统关系型数据库主从,多主复杂困难的问题。不管是分布式关系型数据库new sql还是键值型数据库nosql,其都是在特定应用场景下的产物,一个用于弱数据环?#24120;?#19968;个用于大规模数据环?#24120;?#20320;给我说“转向?#20445;?#19981;怕闪掉大牙。
            我们只是技术讨论,你要有什么情绪回家对着你家人撸去,这里没人惯着你。
            代码之美
            代码之美

            引用来自“霡霂”的评论

            关系数据库还是转向New SQL 才是未来。
            看到你的大放厥词,花了半个小时了解new sql是个什么玩意儿,?#21040;?#23450;义为“分布式关系型数据库?#20445;?#35299;决的痛点是传统关系型数据库主从,多主复杂困难的问题。不管是分布式关系型数据库new sql还是键值型数据库nosql,其都是在特定应用场景下的产物,一个用于弱数据环?#24120;?#19968;个用于大规模数据环?#24120;?#20320;给我说“转向?#20445;?#19981;怕闪掉大牙。
            witt-xy
            witt-xy
            PG真香
            renwofei423
            renwofei423

            引用来自“一号男嘉宾”的评论

            PG大法好
            听说删除了简体中午还是中国地区?
            霡霂
            霡霂

            引用来自“霡霂”的评论

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

            引用来自“冰力”的评论

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

            引用来自“霡霂”的评论

            那就看这个产品的支?#33267;?#24230;了,比如TIDB,MySQL兼容做的非常好,如果是一个小项目,在语法用法层面,感觉不到区别。如果?#20197;说?#25674;上一个大项目,那点兼容性的问题,先不说会不会遇到兼容性问题,真遇到了也不是个事,总?#26085;?#33150;一堆分库分表或者、高可用的中间件轻松。不过TiDB的?#24067;?#35201;求有点高,CockroachDB就比较皮实了,你完全可以用一堆树莓派搭建一个非常稳定可靠的高?#38405;?#30340;存储集群。

            引用来自“shifeng1983”的评论

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

            引用来自“霡霂”的评论

            没get到我说的和cap哪里冲突了,还请指明,?#34892;弧?/div>

            引用来自“shifeng1983”的评论

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

            引用来自“霡霂”的评论

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

            引用来自“冰力”的评论

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

            引用来自“霡霂”的评论

            那就看这个产品的支?#33267;?#24230;了,比如TIDB,MySQL兼容做的非常好,如果是一个小项目,在语法用法层面,感觉不到区别。如果?#20197;说?#25674;上一个大项目,那点兼容性的问题,先不说会不会遇到兼容性问题,真遇到了也不是个事,总?#26085;?#33150;一堆分库分表或者、高可用的中间件轻松。不过TiDB的?#24067;?#35201;求有点高,CockroachDB就比较皮实了,你完全可以用一堆树莓派搭建一个非常稳定可靠的高?#38405;?#30340;存储集群。

            引用来自“shifeng1983”的评论

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

            引用来自“霡霂”的评论

            没get到我说的和cap哪里冲突了,还请指明,?#34892;弧?/div>分布式的主要问题就是慢,时间都消耗在网络传输上了,如果用一堆树莓派能解决的问题,那用电脑单机一定也能解决。好的做法是业务拆分一下,或者用异构数据库,基本上能解决99%的问题,
            返回顶部
            顶部
            广东快乐十分实时开奖

                  <output id="ilehw"><bdo id="ilehw"><nobr id="ilehw"></nobr></bdo></output>
                  <dl id="ilehw"><font id="ilehw"></font></dl>

                            <output id="ilehw"><bdo id="ilehw"><nobr id="ilehw"></nobr></bdo></output>
                            <dl id="ilehw"><font id="ilehw"></font></dl>
                              1. 巴萨西甲联赛赛程 竞彩足球能赚钱吗 七星彩走势图连线坐标 辽宁11选5万能8码 北京pk10人工计划预测 nba火箭队 七乐彩复式注数计算公式 新浪彩票专题网 广东11选5任五推荐计划 彩票刮刮乐中奖绝招 湖北Ⅱ选5走奖图 3d六码复式中奖金额 彩票河北十一选五开奖 重庆时时彩平台手机app 海南环岛赛在哪直播