近期在中國(guó)信通院主辦的 2023 OSCAR 開(kāi)源產(chǎn)業(yè)大會(huì)上，發(fā)布的一份《開(kāi)源數(shù)據(jù)庫(kù)生態(tài)發(fā)展研究報(bào)告》吸引到我。這份報(bào)告是中國(guó)信通院旗下的云計(jì)算開(kāi)源產(chǎn)業(yè)聯(lián)盟寫(xiě)的，比較權(quán)威。報(bào)告針對(duì)最為流行的開(kāi)源數(shù)據(jù)庫(kù)-MySQL 發(fā)展現(xiàn)狀、技術(shù)創(chuàng)新、產(chǎn)業(yè)應(yīng)用三方面梳理了發(fā)展情況，并對(duì)我國(guó)基于MySQL技術(shù)路線的開(kāi)源數(shù)據(jù)庫(kù)產(chǎn)業(yè)進(jìn)行展望。報(bào)告根據(jù) MySQL 開(kāi)源數(shù)據(jù)庫(kù)5.7版本生命周期即將結(jié)束，結(jié)合在金融、電信、能源行業(yè)的情況，闡述了用戶在數(shù)據(jù)庫(kù)替代和遷移選型過(guò)程中所考慮的諸多因素及可能的技術(shù)選型方案。針對(duì)這一報(bào)告，也談下我的一些觀點(diǎn)。下文圖未做特殊說(shuō)明的，均取自上面的研究報(bào)告。完整報(bào)告參考[閱讀原文]。

1. 大背景：MySQL 5.7 即將 EOL

1).MySQL 5.7 EOL

EOL，即生命周期結(jié)束（End of Life）。根據(jù)Oracle官方信息，到了2023年10月，MySQL 5.7將迎來(lái)其生命周期的終結(jié)，也就是俗稱的“停服”。這意味著該版本將不再獲得更新或安全補(bǔ)丁，同時(shí)也意味著各個(gè)行業(yè)使用MySQL 5.7數(shù)據(jù)庫(kù)的業(yè)務(wù)系統(tǒng)將面臨多種潛在風(fēng)險(xiǎn)…

圖片

數(shù)據(jù)庫(kù)停服，意味著一系列的問(wèn)題，包括在安全漏洞修復(fù)、穩(wěn)定性、安全性、軟硬件環(huán)境適配、運(yùn)行維護(hù)支持、生態(tài)系統(tǒng)萎縮及使用開(kāi)源 MySQL 本身可能帶來(lái)的合規(guī)性風(fēng)險(xiǎn)等。

2).MySQL 使用現(xiàn)狀

報(bào)告中也談到了MySQL在國(guó)內(nèi)，特別是5.7版本的使用情況。作為最為流行的開(kāi)源數(shù)據(jù)庫(kù)，MySQL在國(guó)內(nèi)有大量的裝機(jī)量，從全球占比來(lái)看，中美占據(jù)半壁以上。而作為最為流行的版本，MySQL5.7在眾多版本中也是占比最高的。報(bào)告中以金融行業(yè)為例，說(shuō)明了MySQL 5.7的使用情況。

2. 國(guó)產(chǎn)化替代選型考慮因素

1).選擇開(kāi)源 MySQL理由

從上面的數(shù)據(jù)可見(jiàn)，MySQL 在國(guó)內(nèi)有著巨大的使用量，不僅僅在互聯(lián)網(wǎng)行業(yè)，其他行業(yè)也同樣有著廣泛的使用。那為什么大家如此喜愛(ài)這一產(chǎn)品？這也是后面我們?cè)诳紤]國(guó)產(chǎn)化替代上需要關(guān)注的因素。報(bào)告中同樣給出了一組調(diào)查數(shù)據(jù)。

圖片

從數(shù)據(jù)中不難發(fā)現(xiàn)，開(kāi)源和生態(tài)是用戶選擇這一產(chǎn)品最為主要的兩個(gè)因素。一方面軟件開(kāi)源大大降低了使用門(mén)檻，可以讓用戶快速了解使用產(chǎn)品；同時(shí)也可吸引到大量開(kāi)發(fā)者來(lái)為之貢獻(xiàn)，實(shí)現(xiàn)軟件迭代閉環(huán)，促進(jìn)快速發(fā)展。這也是國(guó)內(nèi)很多數(shù)據(jù)庫(kù)廠商紛紛采用開(kāi)源策略的初衷。另一方面，完善的生態(tài)體系促進(jìn)了產(chǎn)品發(fā)展，上下游生態(tài)產(chǎn)品將有助于用戶快速開(kāi)發(fā)、使用這一產(chǎn)品，降低使用難度。這也是國(guó)內(nèi)大部分產(chǎn)品的短板——還沒(méi)有形成較為完善的生態(tài)體系，因而大多采用的兼容方式，已借用相對(duì)成熟的生態(tài)體系。由此可見(jiàn)，國(guó)內(nèi)很多產(chǎn)品都提供了 MySQL 的兼容模式，正是基于此。

2).使用 MySQL 的主要問(wèn)題

當(dāng)然，使用開(kāi)源 MySQL 也并非是完美方案，同樣面臨很多問(wèn)題。這也是希望未來(lái)在 MySQL 的替代過(guò)程中能夠解決的問(wèn)題。報(bào)告中也收集到用戶吐槽的一些問(wèn)題。

圖片

這些問(wèn)題中主要是來(lái)自兩個(gè)方面，一是開(kāi)源軟件所帶來(lái)的問(wèn)題，主要是運(yùn)行維護(hù)、協(xié)議合規(guī)等問(wèn)題，這些都是開(kāi)源軟件在企業(yè)內(nèi)使用的常見(jiàn)問(wèn)題，對(duì)于非國(guó)內(nèi)開(kāi)源的軟件，問(wèn)題更為凸顯；二是 MySQL 軟件自身在功能、性能、穩(wěn)定性等方面的問(wèn)題，這也是企業(yè)選擇開(kāi)源的一個(gè)風(fēng)險(xiǎn)，無(wú)法像使用商業(yè)軟件一樣，可以跟廠商有較為緊密的互動(dòng)、獲得穩(wěn)定的技術(shù)支持。

3).替換 MySQL 5.7 的考慮因素

鑒于上面談到的 MySQL 5.7 即將停止服務(wù)，那么如何替換就成為很多企業(yè)需考慮的問(wèn)題。在選擇具體技術(shù)方案之前，首先看看用戶在面對(duì)替換時(shí)優(yōu)先考慮哪些問(wèn)題。報(bào)告以金融行業(yè)為例，收集了用戶在替換時(shí)需考慮的幾個(gè)因素。下文我將這些因素逐一展開(kāi)說(shuō)明。

圖片

3. 替代主要技術(shù)路線及產(chǎn)品

1).替代技術(shù)路線選擇

通過(guò)上文可知，替換數(shù)據(jù)庫(kù)需要考慮諸多因素，那當(dāng)前用戶是如何選擇的呢？報(bào)告以金融行業(yè)為例，收集來(lái)自用戶的的反饋。從下圖所示的用戶選擇來(lái)看，替換為國(guó)產(chǎn)數(shù)據(jù)庫(kù)是主流的選擇，選擇升級(jí)到8.0次之，仍然冒險(xiǎn)使用 5.7 版本很少。

圖片

既然替換（含升級(jí)）是用戶的主流選擇，那么當(dāng)前可支持 MySQL 替換的技術(shù)路線有哪些呢？報(bào)告中明確指出有三種可行的技術(shù)路線：

• 遷移到 MySQL 支持版本，如 MySQL 8.0
• 遷移到國(guó)內(nèi)的 MySQL 開(kāi)源分支
• 遷移到國(guó)產(chǎn)商業(yè)數(shù)據(jù)庫(kù)

2).主流技術(shù)方案對(duì)比

這里結(jié)合上文談到的用戶在面對(duì)替換場(chǎng)景優(yōu)先考慮的這些因素，針對(duì)這三種可行的技術(shù)路線，做了個(gè)簡(jiǎn)單的雷達(dá)圖分析。圖中的維度對(duì)比是來(lái)自上文的考量因素。圖中由內(nèi)到外，對(duì)應(yīng)遷移難度從難到易、成本由高到低、其他因素均從內(nèi)到外為高到低遞減，也就是說(shuō)越靠外側(cè)，越是優(yōu)選之策。那么從下圖可以看出，國(guó)內(nèi)開(kāi)源方案相對(duì)比較均衡，且全面優(yōu)于升級(jí)到8.0版本的方案，后者在長(zhǎng)期發(fā)展上有優(yōu)勢(shì)。而與國(guó)產(chǎn)商業(yè)數(shù)據(jù)庫(kù)對(duì)比來(lái)看，后者的優(yōu)缺點(diǎn)更加鮮明，部分對(duì)比項(xiàng)上有明顯的優(yōu)勢(shì)，但同樣也存在明顯的劣勢(shì)，主要表現(xiàn)在成本及兼容性上。因此用戶如何選擇，需綜合考慮自身的情況。下文將重點(diǎn)對(duì)比下各個(gè)維度。

圖片

? 遷移難度

遷移難度，是大部分用戶在國(guó)產(chǎn)化替代中最為優(yōu)先的考量因素，從現(xiàn)有幾種替換方案來(lái)說(shuō)差異很明顯。原生 MySQL 的遷移相對(duì)難度不大，官網(wǎng)也提供了從5.7到8.0的升級(jí)方案及配套工具。但這里需要強(qiáng)調(diào)一點(diǎn)，8.0版本與5.7還是存在不小的差異，還沒(méi)有做到完全向下兼容，因此還是需要做部分工作，包括從開(kāi)發(fā)、架構(gòu)及運(yùn)維方面。國(guó)內(nèi)開(kāi)源方案，相對(duì)更為平滑，其是基于原生5.7版本構(gòu)建而成，與官方版本的差異很小，更多是在功能及國(guó)產(chǎn)化適配上的增強(qiáng)，因此遷移難度在三個(gè)方案中是最小的，用戶通常可以復(fù)用現(xiàn)有5.7的全套技術(shù)棧，相對(duì)難度和風(fēng)險(xiǎn)都是最小的。國(guó)產(chǎn)商用方案相對(duì)而言，是遷移難度最大的。不同商用方案的技術(shù)架構(gòu)不同，有些是采用MySQL做了二次化封裝而成，有些則完全自研并實(shí)現(xiàn)了一定MySQL兼容；那么無(wú)論是采用哪種技術(shù)路線，都涉及遷移中必要的評(píng)估工作。這一過(guò)程通常會(huì)包括功能、非功能及性能評(píng)估，包含諸多的評(píng)測(cè)內(nèi)容。如評(píng)估結(jié)果與原生MySQL 5.7的差異較大，則都需要進(jìn)行后續(xù)的遷移改造。此外，在后續(xù)的結(jié)構(gòu)、數(shù)據(jù)遷移方面也無(wú)法利用原生工具完成，需要廠商或第三方來(lái)提供相關(guān)遷移工具和方案。

? 改造成本

從上面的遷移難度看，各方案都多少存在一定的改造成本，但差異也是比較明顯的。原生方案中由8.0替換5.7，可能會(huì)存在一定的修改量，這需要在充分理解版本間差異的情況下進(jìn)行修改。相對(duì)而言，國(guó)內(nèi)開(kāi)源方案在改造成本上則更有優(yōu)勢(shì)，鑒于其主要是針對(duì)部分功能及對(duì)國(guó)產(chǎn)化適配的增強(qiáng)，可以理解為對(duì)5.7是“100%”的兼容，在改造成本方面幾乎為零。國(guó)產(chǎn)商用部分則是三者中改造成本最高的，在前期充分的評(píng)估后，需要摸清與5.7的功能差異，有針對(duì)性的進(jìn)行改造適配。有些問(wèn)題，甚至需要在架構(gòu)層面進(jìn)行調(diào)整才能解決。這里需考慮的成本不僅僅包括財(cái)力投入，也包括人力及時(shí)間成本等。

? 可用性

金融行業(yè)對(duì)可用性的要求是極其嚴(yán)苛的，能夠投入到生產(chǎn)環(huán)境使用的產(chǎn)品都是經(jīng)過(guò)充分的考慮與驗(yàn)證。如需要新引入產(chǎn)品，哪怕僅僅是產(chǎn)品版本的重大升級(jí)，同樣是需要進(jìn)行評(píng)估與驗(yàn)證的。針對(duì)上面幾種方案，升級(jí)到8.0，是需要有個(gè)版本重大升級(jí)后的驗(yàn)證過(guò)程，充分驗(yàn)證其可用性。對(duì)于國(guó)內(nèi)開(kāi)源方案，因其是基于5.7構(gòu)建而成，因此其可用性基本可視同5.7的能力，對(duì)于用戶來(lái)說(shuō)，無(wú)需做太多驗(yàn)證類工作。對(duì)于國(guó)產(chǎn)商業(yè)方案來(lái)說(shuō)，各家產(chǎn)品均優(yōu)先在可用性上做了處理，但同樣需要做一定的驗(yàn)證工作。

? 安全性

數(shù)據(jù)庫(kù)作為數(shù)據(jù)的主要載體，其對(duì)安全尤其是數(shù)據(jù)安全上有著嚴(yán)格要求。在具體安全能力上，主要包括有數(shù)據(jù)的保密性、完整性、可用性、訪問(wèn)控制、身份驗(yàn)證、備份恢復(fù)、審計(jì)監(jiān)控、安全合規(guī)、防范攻擊及必要的物理安全。原生的MySQL 8.0主要延續(xù)了5.7在安全方面的能力，可滿足企業(yè)基本的安全訴求。國(guó)內(nèi)開(kāi)源，在安全性上有著更多的增強(qiáng)，包括針對(duì)數(shù)據(jù)加密方面國(guó)密算法的支持等。國(guó)產(chǎn)商用方面，則在安全上有著更多的增強(qiáng)，通過(guò)自身或與第三方工具的配合，可實(shí)現(xiàn)更高的安全性。

? 產(chǎn)品性能

產(chǎn)品性能，一直是 MySQL 被部分用戶吐槽的方面。原生的MySQL在高頻、小批量的數(shù)據(jù)訪問(wèn)方面有一定優(yōu)勢(shì)，在稍微復(fù)雜的方面則有先天的短板。在MySQL 8.0上，這種情況有了一定的改善，通過(guò)支持諸如 Hash Join 等特性，做了一定的增強(qiáng)。當(dāng)然，我們也要客觀的看到，其較其他產(chǎn)品還是存在差距的。國(guó)內(nèi)開(kāi)源方面，針對(duì)性能方面有著更多的增強(qiáng)，有些沒(méi)有合入官方版本的性能補(bǔ)丁被合入，其性能較原生MySQL有了進(jìn)一步的增強(qiáng)。而國(guó)產(chǎn)商業(yè)方面，通過(guò)針對(duì)優(yōu)化器、執(zhí)行器乃至算法的支持，其性能有更為優(yōu)異的表現(xiàn)，特別是隨著分布式、列存、向量化執(zhí)行引擎等關(guān)鍵能力的突破，其性能較原生或國(guó)內(nèi)開(kāi)源版本，有了質(zhì)的飛躍。

? 兼容性

好的數(shù)據(jù)庫(kù)產(chǎn)品，還需要構(gòu)建完善的上下游生態(tài)，這直接關(guān)乎到用戶的使用體驗(yàn)。作為后來(lái)者，通常會(huì)選擇兼容主流產(chǎn)品作為一條“捷徑”。企業(yè)也通常會(huì)將兼容性作為選擇的產(chǎn)品的考量因素之一。上述幾種方案中，8.0在兼容性方面會(huì)采取向下兼容模式，會(huì)存在少量細(xì)微的差異；國(guó)內(nèi)開(kāi)源因是在5.7版本上構(gòu)建，兼容性幾乎等價(jià)于開(kāi)源版本；在國(guó)產(chǎn)商業(yè)產(chǎn)品上，兼容性還存在不小的距離，需要不斷完善增強(qiáng)。

? 運(yùn)維管理及易用性

數(shù)據(jù)庫(kù)產(chǎn)品作為一種復(fù)雜的基礎(chǔ)軟件，提高易用性、降低運(yùn)維管理難度是關(guān)乎于使用者體感的重要因素。在具體措施上，一方面通過(guò)內(nèi)核的不斷優(yōu)化，提升易用性；一方面則通過(guò)自研或與第三方工具集成，降低使用管理的難度。從上述三個(gè)方案來(lái)看，社區(qū)開(kāi)源產(chǎn)品無(wú)論是5.7還是升級(jí)到8.0都會(huì)面臨一定的管理問(wèn)題，原生的開(kāi)源產(chǎn)品大多沒(méi)有提供必要的配套工具等；同時(shí)基于內(nèi)核層面的易用性問(wèn)題，也很難在開(kāi)源代碼中快速合入實(shí)現(xiàn)。相對(duì)而言，國(guó)內(nèi)開(kāi)源會(huì)好一些，部分易用性問(wèn)題可以在內(nèi)核層實(shí)現(xiàn)。國(guó)產(chǎn)商用的則更有一些優(yōu)勢(shì)，很多商業(yè)產(chǎn)品都提供了很多周邊工具來(lái)減少運(yùn)維強(qiáng)度。

3).主流開(kāi)源替代產(chǎn)品

那么針對(duì)上面談到的方案二，即遷移到國(guó)內(nèi)開(kāi)源產(chǎn)品上，報(bào)告中也整理了部分國(guó)內(nèi)開(kāi)源產(chǎn)品，包括 GreatSQL、PolarDB-X、StoneDB、TenDBCluster-TenDB、AliSQL 等一批基于 MySQL 開(kāi)源分支構(gòu)建的產(chǎn)品，這些產(chǎn)品已初步構(gòu)建多方參與的社區(qū)生態(tài)，在應(yīng)用落地、社區(qū)活躍度、代碼貢獻(xiàn)等層面圍繞自身特點(diǎn)進(jìn)行不斷完善。報(bào)告中還對(duì)比了這些產(chǎn)品：

圖片

在這些開(kāi)源產(chǎn)品中，以 GreatSQL、PolarDB-X 等為代表的一些產(chǎn)品均取得不俗的成績(jī)。它們通過(guò)構(gòu)建國(guó)內(nèi)自有開(kāi)源生態(tài)社區(qū)，穩(wěn)步推進(jìn)生態(tài)發(fā)展。通過(guò)活躍的開(kāi)源社區(qū)，不斷更新迭代產(chǎn)品發(fā)展，快速響應(yīng)解決社區(qū)問(wèn)題，完善產(chǎn)品在不同業(yè)務(wù)場(chǎng)景下的需求，逐步形成更為符合中國(guó)特點(diǎn)的生態(tài)體系。以 GreatSQL 為例，通過(guò)增加如并行查詢、線程池、MGR增強(qiáng)、SQL兼容增強(qiáng)、國(guó)密算法等特性及能力，提升在高性能、高可用、易用性、安全性上的表現(xiàn)，為國(guó)內(nèi)用戶提供了MySQL5.7停服替換的一種更好的選擇。除了上述產(chǎn)品外，國(guó)內(nèi)還有很多其他基于 MySQL 的開(kāi)源或基于開(kāi)源分支之上的商業(yè)產(chǎn)品，都可以作為用戶替代的選擇。相信這些產(chǎn)品未來(lái)也將擔(dān)當(dāng)起 MySQL 替換的重任。下圖是來(lái)自墨天輪社區(qū)統(tǒng)計(jì)的 MySQL 體系的國(guó)內(nèi)產(chǎn)品。

圖片