众所周知，我们这的国产化进程已经如火如荼的展开了，虽然还是操作系统优先，数据库还在试点阶段，但是就数据库厂商的套路而言，我已经摸得比较熟悉了。
1.交流阶段
前期沟通交流阶段，就如同我技术blog里面写的很多篇一样，高大全的吹，尽可能的展现自己的好，完全不说自己的问题，顺便深入且全方位的贬低友商。只要不遇到像我这种的硬茬，就想方设法在客户那里树立良好的映像，争取获得试点、POC的机会。
2.试点阶段
进入“试点名录”以后，就要开始选择试点业务了，然后你就会发现一个有趣的现象：在沟通阶段拼命的吹自己是面向OLTP业务的分布式数据库，然后在选择试点业务的时候就尽可能选择数据量合适，没必要上分布式，用一主多从方式（副本模式都不给上）即可解决的业务来做试点。当你对此提出疑问时，数据库厂商就会说，这是单分片模式，后期是可以横向扩展的。这样的试点就会发现，除了语法差异需要调整，你（或者客户或者应用厂商或者both）会惊讶的发现，不需要分布式改造耶~（主从还改造个屁啊，矫情~）
还有一种现象就是还是面向OLTP业务的分布式数据库，最终选择了数据分析平台或者用于存放历史数据，各中细节，你品~你细品
3.POC
理论上来说我们这里还没有进入POC阶段的国产数据库，但是其他中心有啊，无非就是一下几种情况了：
上午出问题，下午开会改代码，晚上加班割接上线，周而复始，无穷无尽，好不容易解决的差不多了，数据库版本更新，一切回到初始（合代码的问题），欲哭无泪
数据同步好好的，偶尔查询下没问题，一旦测试切换，把完整压力切过去之后，整个集群就崩盘了。当然也有那种同步压力大一丢丢集群就崩盘的现象
分布式改造直接把应用厂商搞死（除了真正意义的搞死外<其实很少>，更多的是评估工作量后不配合<主要是不加钱>）
最后价格谈不拢，不了了之（能临近上线了，国产的“价格优势”就显现出来了）
等等等等（欢迎评论区补充）
4.正式上线
其实目前大多数正式上线的国产化数据库也无外乎集中情况：
经过“精挑细选”的业务
已经花了很长时间将业务拆分成较小的可独立运行的模块
业务厂商和数据库厂商为一家
等等等等（欢迎评论区补充）
总结
国产数据库仍然还有很长的路要走，正如我之前说过的一样，很多数据库优先解决的是纯OLTP场景（类似于计费、记账这种），业务逻辑稍微复杂点都有些难（类似于故障流转、流程工单）。或者就是利用分布式进行大规模数据运算的。
老规矩，不知道写了些啥
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/31466763/viewspace-2998147/ ，如需转载，请注明出处，否则将追究法律责任。
最新文章
- 胖头鱼的技术专栏-479 如何高效地将喂给 AI 的数据搬过去（20261015）
- 胖头鱼的技术专栏-478 Agent 成了新用户，数据库要接住它的下一步（20261014）
- 胖头鱼的技术专栏-477 26ai新特性实战：表达式分区（20261013）
- 胖头鱼的技术专栏-476 26ai新特性实战：聚合过滤（20261012）
- 胖头鱼的技术专栏-475 蹭到最后，就没人摆摊了（20261010）
- 胖头鱼的技术专栏-474 从能跑到能上线：PG SplitJSON 0.2.0 和 0.1.0 差在哪
- 胖头鱼的技术专栏-473 26ai新特性实战：日历函数（20261004）
- 胖头鱼的技术专栏-473 改JSON的一个字段不再重写整篇：我给PostgreSQL 18写了个扩展
- 胖头鱼的技术专栏-472 26ai新特性实战：无 FROM 子句的 SELECT 语句（20261003）
- 胖头鱼的技术专栏-471 数据库优化的三层楼——为什么多数人总在第二层打转
