ORACLE TO POSTGRESQL 来自2天上海的印象

开头还是介绍一下群,如果感兴趣polardb ,mongodb ,mysql ,postgresql ,redis 等有问题,有需求都可以加群群内有各大数据库行业大咖,CTO,可以解决你的问题。加群请联系 liuaustin3 ,在新加的朋友会分到2群(共1000人左右 1 + 2 + 3)新人会进入3群

最近去了上海一趟,主要与某个企业在从 ORACLE 数据库转型到POSTGRESQL 有关,2天的行程下来感触也挺多。首先在我们传统的意识中,只有国内的那些XX单位,才要摆脱ORACLE 搭上 POSTGRESQL 这班车,什么原因 ZC原因,而本次转换到POSTGRESQL的原因,却不是ZC原因,而是 CB原因,虽然知道ORACLE TO POSTGRESQL 的主要两个原因分别是 ZC 和 CB ,但是一些世界500强也开始算计成本,也让我有点"惊诧"。

因为向来这些企业本身都是对于稳定性有更高的要求,ORACLE 可以带来的东西可不是 "免费" 软件可以比拟的,但如今这样的企业也开始要吃免费的"餐食" 也是有点意思。

当然转型期间,必然有痛苦,500强们习惯了ORACLE 给付的稳定性,但换到了POSTGRESQL 就遇到了以下的一些问题,因为本次主要是和开发的一些同学进行了沟通,所以也了解了大家的一些问题。

在使用POSTGRESQL 的时候,到底是像使用ORACLE 一样的开发模式,继续开发,存储过程,函数,以及OLTP 混合着OLAP的风格,还是根据POSTGRESQL 本身的特性来一次 "根除" 模式的开发方式的转变,这是一个重点。

基于ORACLE 数据库开发的模式中,有一种模式是依赖数据库提供的功能的基础上进行软件开发的模式,同时这样的开发方式中,由于ORACLE本身能承受更多的一些不同的项目,不同的目的的软件,将数据集中在一个物理库上,基于ORACLE 先进的一些对于连接的管理使用,和强大的SQL优化方式,同时辅助于ORACLE周边的各种的优化方式,从上到下都可以武装到牙齿的方法,让一些开发方式还是可以继续的。

反过来,换一个数据库本身就会导致开发模式的转变这样的事情很多的公司并未意识到,还用昨天的酒 放到今天继续的卖,那么吃亏的必然是今天的顾客。结果就是,继续这样的开发方式和模式,导致原来在ORACLE可以的事情,到了POSTGRESQL 不可以了。

这都是基于对于新的数据库不了解原理和工作模式导致的问题,比如MVCC的在不同数据库完成此项功能时所付出的代价,以及不同的特性导致你做某些操作后对数据库本身的稳定性和性能产生的影响。这些都是要被开发的人员了解,并逐步熟悉的。

同时在本次的工作中,还发现一个问题就是让我感受到,这些开发人员从心底的呼唤,DBA is stupidity. 当然人家当面没有说,但是我已经深刻感受到交流中,对于他们内部的一些 D B A 工作模式的困扰,比如开发在热火朝天的进行 ORACLE TO POSTGRESQL 的工作,并希望得到 DB 的一些支持,而DB 给出的第一句话就是 ,ORACLE 行,为什么POSTGRESQL 不行。从这话里面的意思我已经听出一点点,怎么你们搞不定POSTGRESQL ,POSTGRESQL 无法完成ORACLE的一些功能和性能,那你们为什么不继续 ORACLE,或者这事与我们无关,我们DB 就是运行维护,其他的事情 It is not our dba's business.

如果每次都是开发现行,而不是DBA 先行,然后和大爷一样把所有的数据库问题都推卸到开发,我作为一个 DB 我都看不过去,对于这样的DB 我只想说,shame on you ! 我以为抱着一个数据库吃一辈子的DBA 就是一个故事,你真的给我演绎的一个真实。

不过沟通中,开发人员的积极和努力,以及对于POSTGRESQL 本身的兴趣也让我吃惊,很多的问题,都在想办法自己处理,并且发起了学习POSTGRESQL 的一个非常有热度的氛围。相信加以时日,很多开发者都会理解基于POSTGRESQL 数据库开发的一些特性和习惯。让自己变得更值钱,更符合当前的经济情况下的,更加白热化的 成本 竞争。

通过交流我也在自己找到很多自身的不足,设计上我并不是一个自己坐在象牙塔里面的DB,我更愿意了解,应用的业务逻辑,以及业务的一些特性,通过了解这些,结合POSTGRESQL 本身的一些功能,让开发业务更轻松,这是我一直秉持的初衷,开发一些思维模式 + DBA 基础,或许能有更多的想法,解决更多"很有意思"的业务逻辑导致的开发中要求数据库能进行架构改变后,让开发更顺畅,让系统更稳定,性能更流畅的方法。

同时从本次的沟通中,自己也通过沟通,发现了更多开发针对POSTGRESQL有意思的想法,并且也启发了我针对POSTGRESQL 在一些公司转变中对于数据库一些 DBA 不曾想起来的一些特性的研究。

最终你的价值,不来自于你自己的认为,而是来自与你解决了多少人的需求,那才是你真正的价值所在,而很多开发者在了解POSTGRESQL的左左右右,上上下下,他们会带来更多的价值与需求,所以开发和DB 是互相帮助的 partner 而不是和某些DB 对于在开发中数据库转换中带来的那句,为什么ORACLE 行 PG 不行,这不是对某个数据库的耻辱,是你对你自己职业的羞辱。

最后基于这些开发者提出的一些问题,我也会思考,并试图找出更好的解决方案, wait and see what happens .

相关推荐
gma9991 分钟前
Etcd 框架
数据库·etcd
爱吃青椒不爱吃西红柿‍️4 分钟前
华为ASP与CSP是什么?
服务器·前端·数据库
Yz987639 分钟前
hive的存储格式
大数据·数据库·数据仓库·hive·hadoop·数据库开发
苏-言1 小时前
Spring IOC实战指南:从零到一的构建过程
java·数据库·spring
Ljw...1 小时前
索引(MySQL)
数据库·mysql·索引
菠萝咕噜肉i1 小时前
超详细:Redis分布式锁
数据库·redis·分布式·缓存·分布式锁
长风清留扬1 小时前
一篇文章了解何为 “大数据治理“ 理论与实践
大数据·数据库·面试·数据治理
Mephisto.java1 小时前
【大数据学习 | Spark】Spark的改变分区的算子
大数据·elasticsearch·oracle·spark·kafka·memcache
OpsEye1 小时前
MySQL 8.0.40版本自动升级异常的预警提示
数据库·mysql·数据库升级
Ljw...1 小时前
表的增删改查(MySQL)
数据库·后端·mysql·表的增删查改