近日，PingCAP開(kāi)始裁員，某位同學(xué)在知乎上發(fā)出靈魂一問(wèn)：“如何看待PingCAP裁員，是不是國(guó)產(chǎn)數(shù)據(jù)庫(kù)沒(méi)救了？”

從文章可看出，墨天輪在《2022 年中國(guó)數(shù)據(jù)庫(kù)行業(yè)年度分析報(bào)告》中進(jìn)行了鞭辟入里的分析，重點(diǎn)指出了個(gè)中難點(diǎn)所在：

對(duì)此，我們要正確認(rèn)知市場(chǎng)：

首先，PingCAP裁員是真的，但PingCAP也只是國(guó)產(chǎn)數(shù)據(jù)庫(kù)的一家廠商，他不代表整體，PingCAP裁員≠國(guó)產(chǎn)數(shù)據(jù)庫(kù)涼了。

其次，國(guó)產(chǎn)數(shù)據(jù)庫(kù)確實(shí)存在難點(diǎn)，但難點(diǎn)≠不能解決。

語(yǔ)法兼容是行業(yè)的難點(diǎn)，我們都明白原數(shù)據(jù)庫(kù)跑A SQL 效率很好，但兼容數(shù)據(jù)庫(kù)跑A SQL效率大打折扣。功能兼容要看語(yǔ)法(尤其不能出現(xiàn)不等價(jià)的語(yǔ)法)、數(shù)據(jù)類型、函數(shù)、存儲(chǔ)過(guò)程、觸發(fā)器等多個(gè)維度。不管是語(yǔ)法兼容還是功能兼容，其實(shí)都跟數(shù)據(jù)庫(kù)的協(xié)議相關(guān)。

此外，就替換方案來(lái)講，以通過(guò)MySQL路徑替換Oracle為例：

首先，MySQL協(xié)議封裝路徑采用的是從業(yè)務(wù)視角進(jìn)行分表分庫(kù)，會(huì)帶來(lái)大量業(yè)務(wù)冗余表，增加了應(yīng)用的復(fù)雜度。

其次，MySQL協(xié)議封裝路徑是延續(xù)性創(chuàng)新，屬于偽分布式，沒(méi)有做到數(shù)據(jù)細(xì)粒度切分，導(dǎo)致數(shù)據(jù)庫(kù)擴(kuò)容、縮容受限，在集群規(guī)模在百臺(tái)級(jí)別，存在性能瓶頸。

最后，Oracle數(shù)據(jù)庫(kù)自身也是具備強(qiáng)大的分析能力，MySQL協(xié)議封裝路徑缺少大量分析函數(shù)，無(wú)法進(jìn)行AP分析。僅此四點(diǎn)，通過(guò)MySQL路徑替換就不是最優(yōu)解。

這個(gè)辦法替換，確實(shí)難以規(guī)?；娲?。

但試問(wèn)，去Oracle到底是走M(jìn)ySQL路徑，還是走更貼近企業(yè)數(shù)據(jù)中心的Oracle路徑？

升級(jí)替換Oracle是Hubble數(shù)據(jù)庫(kù)非常清晰的目標(biāo)市場(chǎng)，Hubble數(shù)據(jù)庫(kù)走更貼近企業(yè)數(shù)據(jù)中心的Oracle路徑，實(shí)現(xiàn)數(shù)據(jù)庫(kù)的替代升級(jí)邏輯，可以規(guī)?；鎿Q。實(shí)踐中，在銀行A類核心系統(tǒng)國(guó)產(chǎn)化成功替換Oracle一體機(jī)。

對(duì)比Oracle，單表3億記錄數(shù)量級(jí)下的用戶業(yè)務(wù)場(chǎng)景性能突破 Oracle 800并發(fā)瓶頸，1600 并發(fā)下依然保持線性穩(wěn)定服務(wù)。同等并發(fā)下，平均響應(yīng)時(shí)間和最大響應(yīng)時(shí)間均優(yōu)于Oracle，具有穩(wěn)定的線性橫向擴(kuò)展能力。

4月1日（本周六）14:00—16:00. 金田公園內(nèi)8號(hào)，讓我們從分布式數(shù)據(jù)庫(kù)世界的“入口”——協(xié)議，正確看待國(guó)產(chǎn)數(shù)據(jù)庫(kù)的發(fā)展。