这开头还是介绍一下群,如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, Oceanbase, Sql Server等有问题,有需求都可以加群群内,可以解决你的问题。加群请微信联系 liuaustin3 ,(共1900人左右 1 + 2 + 3 + 4 +5) 4群(400+ 关闭自由申请,新入群的将默认分配达到5群),另欢迎 OpenGauss 的技术人员加入。
上周去Polardb下午上台讲了讲使用的经验,由于身体不适没有控制住,爹味十足的吼到了超时。不过好在没有弄砸锅。大会可以说是,人山人海,鞭炮齐鸣,锣鼓喧天,彩旗招展。会上和不少 2 3 4 5 年的老师们都奔现了,终于互相都见到了活的,我得到的评价是,这么高, 也没怎么高 3 4 层楼那么高吧。
中午和一些大佬吃饭,其中一个大佬一些思路非常棒,给了我一些新的idea。 当然席间也说到,关于DBA 后续的一些问题,尤其是后续怎么继续生存,以及职业发展的问题。
上周一篇关于2024不看好国产数据库的帖子,阅读量是我没有想到的。当下我感觉到一个字,冷。 北京当天的天气,的确是阴冷,但是和当下的经济环境和从事数据库这行人在未来继续更好的生存的问题相比,到不算太冷了。
可以确定的是,不管你愿意不愿意,或者承认不承认,云数据库,尤其云原生数据库,正在蚕食当下的方方面面。数据库的确出现了新的模式,如同当天大会提出的,积木数据库,积木数据库会影响那些行业,那些人,那些数据库产品,我们粗略的分析一下。
1 国产数据库
国产数据库行业生存竞争除了国产数据库们自己的竞争,被忽略的还有云原生数据库,基于人性的好逸恶劳的本性,送到嘴边的就是比费劲心力更受人待见,国产数据库在服务上是无法和云原生数据库直面硬钢的,云数据库主打的是,服务到你最后一公里,重点的客户可以直接到访,一般的客户线上远程直接协助,或处理,从硬件到上面构建的数据库都是云数据库,所以解决问题避免了很多复杂因素导致的,未知情况。
这好比线下实体门店,已经在无力迎战网上的电商一样,败退下来只是时间的问题,联通也上了云,是让我惊讶的,这样的公司不应该是线下数据库的爱好者,它也上云了,也在用云原生 OMG。
国产的数据库这个仗准备怎么打?那么多的狠角色已经侵入你的客户群,你束手就擒还是寻找突破口,发现新客户,老客户怎么维系,问题一大堆,头疼。
更多的问题是,传统国产数据库的客户的硬件不统一,各式各样的都有,给数据库稳定的运行提出了难题,很难满足所有的客户,云数据库则不同统一的硬件水平,高标准的维护,并且云原生就是在这些硬件上,进行针对硬件的软件开发,最大化的利用了硬件的特性和性能,这点国产线下的数据库很难在这方面有建树,因为要兼容的硬件五花八门,无法应对所有客户的需求,所以性能这方面,必然会参差不齐。
从体量上讲云数据库,云原生数据库有稳定的资金流,不会出现客户使用了数据库产品,不付费的问题,在资金支持这方面不会出现,现金流的漏洞。另外还有一个关键的部分,在使用率,占有率不用说的也会高于国产数据库的产品,终究云数据库,消费这些产品的是广大的中小企业,甚至大型的知名的企业,而类似信创无法威慑的企业,你打死他,他也不会用线下国产数据库,从受众这也不是一个量级。
基于更多的使用者,云原生数据库发展的要更快,更健壮,得到的反馈更多,版本的更新和BUG FIX的速度更快,国产数据库要想在这方和云原生数据库抗衡,难。
一个是更标准,更稳定,独有的一些云上数据库的技术,频繁在搞创新,并且有巨无霸的企业背景的背书的数据库产品,孰强孰弱不用再说。
2 DBA的工作方式方法和工作的重要程度
这点我本不想说,但说了就说了,云原生数据库对于DBA 的职业冲击,或许比云原生数据库对国产数据库的冲击还要大。 以前的工作职责,即使上云后,使用RDS 数据库工作的重要程度虽然降低,但还不至于到恐慌的程度。云原生数据库的出现,他就是解决那些一直开发,架构认为是问题的问题,如同polardb 提出了,积木数据库。缺什么,插什么,性能如同水龙头有了serverless ,IMCI 都可以应对一些开发容易出现的错误,并给你时间在进行补救,比如你上线一个系统,由于没有加索引,导致CPU 升高,那么只要有适当的弹性或者有IMCI,他就先给你化解一波问题,剩下的你赶紧去纠正。
DBA 的工作在云原生上,需要了解新型数据库的组成,功能,以及玩法,的确就是一个积木,搭建的好不好,好用不好用,成本高不高,在DBA的谋划。那么DBA 就慢慢从一个,工具人类型,逐渐的长脑子了,会分析,会写程序调用API了,工作的模式又在新的数据库上被改变了。
那我不用云数据库不就行了,呵呵,你真单纯!我用当天我遇到了一个老熟人的话作为这阶段的回复。
老熟人也可以说是我的老领导,前前前前前单位的,人非常的开朗,他最大的优点是能顺势而为。之前的单位也是行业的翘楚,由于某些原因裁员了3波该卖的也卖了,曾经上万人的大单位,几十人的运维+DBA,最后变成了,他自己,光杆司令。后来缓过来点,在行业又成为新热公司,就这样,整体的DBA + 运维 = 6人。
我也不敢想象,现在街上几千家的他们的门店,那么热的品牌,他和我说,不敢招人,经济形势不好,经历了那么多,怕招人后,在给人家裁了,我理解他虽然满脸笑意,但非常痛苦,换谁都痛苦。原来我们的上百套MYSQL 都没有了,都已经上云了,线下数据库nothing 了。未来你挡不住大量的企业因为各种问题,持续的上云,摆脱固定资产,和繁琐的数据库底层运维技术,以及抛弃低端的运行维护人员的时代选择。
(本段并不让人愉快,如同命运,你可以对他破口大骂,最终你将顺应他)
这样的情况不是少数,我自己深有体会,一般纯商业公司,运维和DBA的需求量会逐渐缩小,他们统统选择云数据库是在向隐性成本低头,项目好,我就采购更多的数据库,项目不好,马上降低配置节省成本,人少,基础的工作可以少做不做,什么备份,硬件更换,严重的故障维保,统统都让云来做,这不是可以不可以,这是为了生存下去,企业一次次的让步。 在公司经营的稳定性上,任何的障碍都会被清除,哪怕一个运维都没有,系统也要正常工作,这就是老板们最终要的。
这和当前租房还是卖房的思路一样,我不知道我的项目能否在当下的经济环境下存活多长时间,租机房,购买服务器,谁还能这么傻,运维人员我也可以先不找,让开发先担待,云原生和RDS才是首选,最终达到一切和项目无关的,都可以被去除。未来专业性不强的DBA 很容易就失去工作,云可以替代你做很多事情。
现实就是这么残酷,与云相比,个人的不稳定因素和成本的可剔除性更高,智能化越高层次不高的技术人员的饭碗就越难保住,技术人员要读懂资本家的想法和做法,尤其在他们现在也没钱,也在穷的时候,他不可能在大手大脚的在赏你一块钱。
3 架构师和开发
每次我都不曾提到的团体,这次你们也躲不过去,别笑话DBA,某工DISS DBA ,实际上你也逃不了,架构师其中重要的是架构的设计工作,以前数据库的能力差,比如MYSQL ,你这分库分表,业务模块逻辑拆分,各种对数据库限流的方案,忙的不亦乐乎。
现在云原生数据库,都是松紧带和积木,他可以解决你很多曾经你必须考虑的问题,从侧面你的一部分工作也会被弱化,有强就有弱,此消彼长,云原生数据库能力强,必然会将一部分工作带走,那么人是不是就可以裁一波了。 开发也是,之前语句拆分,撰写的各种严格的要求,这些都是工作量,都要写到日报里面,在云原生的数据库上有了一些解决方案,那么你不在特别严格要求自己的情况下,你这方面就有空余的时间,是不是要更多的进行业务的开发,或者......
4 同根的RDS 产品
煮豆燃豆萁,豆在釜中泣,相残何须和你打招呼。 其实最倒霉的还是云上的RDS 数据库产品,云原生数据库都具有和 MYSQL , POSTGRESQL 的兼容性,所以很容易从RDS 到云原生,可以说是无缝切换,但相对RDS的那些无法解决的问题,和很多人抨击的成本比自建的要贵的问题,云原生根本就不会和你废话,ECS 和 RDS 与云原生比没有胜算。
降维打击或许就是这个意思,内部更换数据库产品,本身对于云公司讲没有任何的损失,还是一件好事,RDS 产品在云内部相对云原生的数据库部门也是弱势的,不过好在内部可以转化,云原生数据库多了,原来的RDS产品的人员,就可以转到云原生数据库部门,当然这是外人的想法,具体如何未曾可知。
最后,中午的那顿火辣辣的饭的确是没白吃,大佬的想法和idea的确可以深挖,新的工作增长点和立足的部分又有了,聪明的DB,会找出新时代的立足点。

原文作者:AustinDatabases;如有侵权,请联系管理员删除。