近日，PingCAP开始裁员，某位同学在知乎上发出灵魂一问：“如何看待PingCAP裁员，是不是国产数据库没救了？”
从文章可看出，墨天轮在《2022 年中国数据库行业年度分析报告》中进行了鞭辟入里的分析，重点指出了个中难点所在：
对此，我们要正确认知市场：
首先，PingCAP裁员是真的，但PingCAP也只是国产数据库的一家厂商，他不代表整体，PingCAP裁员≠国产数据库凉了。
其次，国产数据库确实存在难点，但难点≠不能解决。
语法兼容是行业的难点，我们都明白原数据库跑A SQL 效率很好，但兼容数据库跑A SQL效率大打折扣。功能兼容要看语法(尤其不能出现不等价的语法)、数据类型、函数、存储过程、触发器等多个维度。不管是语法兼容还是功能兼容，其实都跟数据库的协议相关。
此外，就替换方案来讲，以通过MySQL路径替换Oracle为例：
首先，MySQL协议封装路径采用的是从业务视角进行分表分库，会带来大量业务冗余表，增加了应用的复杂度。
其次，MySQL协议封装路径是延续性创新，属于伪分布式，没有做到数据细粒度切分，导致数据库扩容、缩容受限，在集群规模在百台级别，存在性能瓶颈。
最后，Oracle数据库自身也是具备强大的分析能力，MySQL协议封装路径缺少大量分析函数，无法进行AP分析。仅此四点，通过MySQL路径替换就不是最优解。
这个办法替换，确实难以规模化替代。
但试问，去Oracle到底是走MySQL路径，还是走更贴近企业数据中心的Oracle路径？
升级替换Oracle是Hubble数据库非常清晰的目标市场，Hubble数据库走更贴近企业数据中心的Oracle路径，实现数据库的替代升级逻辑，可以规模化替换。实践中，在银行A类核心系统国产化成功替换Oracle一体机。
对比Oracle，单表3亿记录数量级下的用户业务场景性能突破 Oracle 800并发瓶颈，1600 并发下依然保持线性稳定服务。同等并发下，平均响应时间和最大响应时间均优于Oracle，具有稳定的线性横向扩展能力。
4月1日（本周六）14:00—16:00. 金田公园内8号，让我们从分布式数据库世界的“入口”——协议，正确看待国产数据库的发展。
