云原生 DB 技术将取代K8S为基础云数据库服务-- 2025年云数据库专栏（一）

2025年新开的专栏，也是2025年（中国新年）后的第一篇，云数据库，云原生数据库专栏的第一篇。

提到云，云数据库，云原生数据库，大部分从业者的情感是不愿意接受，抵触，愤恨，他要抢夺我的饭碗的情愫。

那么云，云数据库，云原生技术，会抢夺从业者的饭碗吗？ 会的，一定，且肯定，但这里的抢夺，需要说明。自从有人类，人类意识，这样的抢夺从未停止。

从人类的产生，人类氏族，人类的部落，都是在往多发展，你从未听说过，一个人与一群人战斗，在这个人的技术能力智力与那群人同等的情况下，不会输，不会死。

野生环境，社会环境中，能存活下来的大部分是懂得协作，懂得顺应发展潮流，不拒绝新的知识的人，且从中寻找新的存活途径的人。

我们可以举一个小例子，蒸汽机发明的时候，并应用到了火车，当时马车的马夫们非常的不服，经常举办蒸汽机火车与马车的比赛，且前面的几年间，马车快过蒸汽机车，蒸汽机车不断地出现各种的故障，问题。

但历史的发展，我们都知道结果，现在从北京到上海，坐的不是马车，而是高铁。从成本的角度，一辆马车的成本要远远低于一辆高铁，但人们选择的是高铁，而不是马车。成本的核算本身不光是马车和高铁的成本堆叠。

云，云原生技术的发展，恰似集约式的经济模式，取代个体作坊式的模式，这就如同上世纪的纺纱厂取代了农村的妇女个人的纺织机。集约式的发展的特点：

1 提高效率生产力

2 存进技术进步与创新

3 适应大规模的生产和消费

4 应对资源的约束和挑战

同时我们也应该注意集约性的发展必然带来

1 失去个体自主性和多样性

2 加剧社会的不平等和贫富差距

3 带来环境的污染和过度消耗

4 增加系统性的风险

人类的发展中，我们每天都在承受风险，对云，云原生的不满和战斗从未停止。但我相信，如同马车和火车，集约性的发展必然取代个体单独的发展，这在人类的历史发展上一直是这个规律。

说到这里，还没有说到云数据库，云原生数据库和自建的数据库产品之间的区别

这里我们站到更高的视野或角度，也就是IT项目负责人或者公司的领导者的角度来看，而不是某个数据库技术工作者的角度来分析，因为那样既无聊也无效，数据库或者说DBA是不能左右一个企业的集约化发展的。（你表达半天意见，没有搭理你）

从IT CTO ,CIO,甚至公司的CEO的角度

1 公司的IT运营要有强大的背书，尤其服务于民生行业，必须有背书，被服务者必须信任你的服务是可靠且不经常出现问题。

2 技术的先进性，一个人，一个DBA和几千人的团队，从某种角度来说，不用考虑几千人的团队的产品要比一个人的技术先进性要高，否则也就不会有人天天要去名企工作，在大企业里面寻找更多的机会。

3 成本与价格的核算的合理性

我们以云原生的技术与个人搭建的K8S数据库为例

1 云原生技术中的数据库产品可以应对更激烈的使用场合

举例： 1 扩充节点的迅速性，从目前部门的云原生数据库产品的技术能力，扩充节点与节点本身的数据量已经可以做到无关，你 100G 的数据库，还是 1T 容量的数据库在serverless 弹性节点时，时间消耗是一致的。 就这一点，K8S为基础的开源数据库产品将无力迎战，技术原理所限，K8S部署的数据库是基于网络复制数据节点的方式。

如突发的业务风险中，我可以在3分钟或者更快1分钟扩充一个500G 甚至1T的数据库节点，而以K8S 为基础的产品是不具备这样的能力的，以K8S为基础的数据库扩缩容系统是以数据库的单体容量大小来估算可以产生节点的时间。 而突发情况中，我们要的是快，而不是你可以，如同在医院抢救病人，我可以3分钟来一次心脏除颤，你也可以但你告诉病人稍等，我这充电呢，我要等300分钟后，才能给你心脏除颤。 最后的结果，3分钟病人可能就活了，300分钟病人都凉透了。你要命的业务也是如此，没有人会等你对大容量的数据库进行网络复制来满足严苛挑剔的客户。以前是大家都不能，但在云原生技术的驱动下，云原生数据库可以，而基于K8S的数据库技术不可以，那么基于K8S的数据库产品被淘汰在严苛的环境下是必然而不是偶然，如同我们不在使用的马车技术。

2 云原生技术中的数据库产品在同等服务的情况下，成本更低

举例： 云原生的产品和K8S搭建的数据库产品之间最大的优势是成本。

1 云原生技术拥有的技术特性

1 快速扩缩容，应用需要立即进行扩容节点，应用不需要立即缩回节点，召之即来挥之即去，多加的节点的时间可以很短。

2 技术的完整度高，这里我们举几个例子，在云原生数据库中可以针对1T或者更高的数据库产品中的一个表进行瞬间恢复，并且恢复到原数据库中，

举例，在9点你的程序员误操作一个表中的数据，如果是基于K8S的数据库产品，我且认为你能恢复数据但需要很长的时间，在云原生技术中，恢复一个单表基本在分钟级，且直接还原到你源库中，并更换你的恢复的表名为restore_日期。

从此对于误操作，没有公司再害怕只要你愿意随时可以找回你丢失的数据，秒级的精度。

（如果是K8S的自建技术，如何做到以上的需求，你付出的成本是多少）

3 大量利用更先进的硬件技术，数据库代码重写匹配硬件。这点是云原生技术中的最大的特点，现在的硬件技术突飞猛进，原有我们的意识磁盘就是磁盘，但在传统中，你的CPU并发再高，也限制在IOPS也就是磁盘，磁盘的带宽。

而利用了云原生技术中的磁盘将不是我们日常中的磁盘感念，你的一块磁盘是一块，原原生技术中的磁盘，将是100块，甚至1000块磁盘合并，你的数据直接分散在这些磁盘上，技术上将数据CPU的并发和磁盘的分散结合，达到你买再贵的磁盘也达不到的效果，人多力量大。

（基于K8S的技术自建系统，你最大的问题是硬件的限制，与数据库源代码与新硬件的不匹配）

4 数据库的技术进步的速度快，这点毋庸置疑，传统的数据库产品你BUG FIXED ，version upgrade 都会等到很长的时间，而云原生技术的数据库产品，更新的速度和打到你数据库上的速度非常快，15天，1个月，根本不用等，如果是严重的问题可能1天就BUG FIXED。彻底打翻原有数据库BUG FIXED 和版本更新的时间维度。

（基于K8S的自建产品，无法具有此项解决方案）

5 有能力的用户可以加入到数据库产品，技术的讨论与修改中。这点也是我非常喜欢的，原有的数据库产品无论是ORACLE，MYSQL，POSTGRESQL ,SQL SERVER，这些产品是无法做到和用户去有效的互动，经常的互动的。这是产品本身结构所决定的问题，而现在的云原生的数据库的产品改变将变得更加的快速与用户互动更高。

能活的更好的产品都是符合用户需求的产品，数据库也是一样。比如POSTGRESQL 的事务ID 64位的问题，在云原生数据库上，可能并不太难，客户的需求只要合理那么他很快就会改变。

6 数据库安全 云原生的数据库产品是可以做到本地机房损毁，快速拉起异地机房的，因为在数据库原理和硬件上都已经在设计初期就考虑到这个问题.

(基于K8S自建的产品，就是容器化管理数据库的方式，不具备此项设计和功能，如果想具有，那么成本又是多少)

DBA 或数据库从业者不能孤立站在自己的角度看问题，看云原生技术的发展，云原生数据库他就是一个数据库，只不过的售卖的方式和玩法变化了，云原生数据库产品更接近用户，而不是更疏远，高级用户可能直接对话数据库产品的核心人员或者负责人。更多的意见和需求会更快的传达到数据库产品方，有效信息的传递，大量的信息的传递，信息的传递的速度，觉决定了云原生技术可以做的更好。因为提意见的都是使用过产品的用户，且速度非常快的传递到产品方。

从对企业负责的角度，选择更强大的数据库产品是DBA的责任，让企业应对业务风险时的抗击打能力是DBA需要负担的责任，而不是我认为，我想，或者我不想云进入我的企业，这就如同K8S在云上搭建的数据库快速扩缩容的产品，可能在前5年还可以，但现在他就是淘汰的从产品力，成本的角度没有优势和值得吹嘘的价值，且对于一些极端的业务情况不适合的技术。

最后，当前的经济形式也让企业的项目不具有之前的稳定性，项目开3个月就黄了，半年就下线的比比皆是，此时如果还用自建机房+K8S技术，或者自建机房的方式，那么和自杀么有任何的区别，企业无法承担固定资产带来的成本风险。

最终，马车会被淘汰，但马车的马夫可以变成高铁的司机，可以变成高铁的维修工，可以变成高铁的服务人员，可以变成高铁的产品更新者，这些都是愿意改变的人最终的结果，且可以活的更长。

作为2025年的AustinDatabase 的重头戏，云数据库，磁盘就是一个开胃菜，下一篇更炸裂，题目我都想好了，某某云得对手是自己