近日,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号,让我们从分布式数据库世界的“入口”——协议,正确看待国产数据库的发展。