現(xiàn)在解決這個(gè)問題的辦法只能是自強(qiáng)，將數(shù)據(jù)庫核心技術(shù)掌握在自己手里，做屬于自己的國產(chǎn)數(shù)據(jù)庫。其實(shí)，這個(gè)事我國也已經(jīng)張羅了幾十年，早在上世紀(jì) 80 年代以研究所和大學(xué)為主的國家隊(duì)就開始投入研發(fā)國產(chǎn)數(shù)據(jù)庫，并在 90 年代相繼推出了幾款數(shù)據(jù)庫產(chǎn)品。不過可惜的是這些產(chǎn)品研發(fā)從一開始就缺乏產(chǎn)業(yè)端的接入，并不是因?yàn)閷?shí)際需求的刺激，而純粹是為了擁有。這樣，產(chǎn)品在商業(yè)市場(chǎng)的拓展也比較弱。作為追趕者，始終也沒有看到對(duì)手的背影。

知乎上有個(gè)問題：“中國跨過數(shù)據(jù)庫這座大山了嗎？” 翻譯一下就是：現(xiàn)在有完全自主研發(fā)的國產(chǎn)數(shù)據(jù)庫了嗎？回答有 100 多個(gè)，看了看不是普及數(shù)據(jù)庫知識(shí)的就是推廣自家產(chǎn)品的，大多回答并沒有直面這個(gè)問題。確實(shí)也沒法直面，因?yàn)槲覀冞€不能說已經(jīng)翻過這座大山了。

國產(chǎn)數(shù)據(jù)庫現(xiàn)狀

這幾年，雨后春筍般地冒出數(shù)百個(gè)國產(chǎn)數(shù)據(jù)庫，但有多少擁有原創(chuàng)技術(shù)呢？

其實(shí)沒多少！甚至可以粗暴一點(diǎn)說：幾乎沒有！

這幾百個(gè)國產(chǎn)數(shù)據(jù)庫中，絕大多數(shù)是基于開源數(shù)據(jù)庫改造的，90% 都不止。其中又有絕大部分（大概又是 90%）是基于 MySQL 或 PostgreSQL 改造的。

MySQL 作為最著名的開源數(shù)據(jù)庫，由于使用者眾多、兼容性強(qiáng)、接口豐富等因素，被很多國產(chǎn)數(shù)據(jù)庫廠商用來改造成自家產(chǎn)品也不足為奇，畢竟熟悉它的人不少，改造成本也低一點(diǎn)。

不過，相對(duì) MySQL，基于 PostgreSQL（俗稱 PG）封裝的更多。這是由于 PG 采用 BSD 開源許可非常寬松，允許修改源碼后再閉源，甚至不需要版權(quán)聲明。因此 PG 成為眾多國產(chǎn)數(shù)據(jù)庫廠商的最愛，紛紛基于 PG 封裝出自己的“原創(chuàng)”國產(chǎn)數(shù)據(jù)庫，包括某些以創(chuàng)新聞名的著名大廠。正所謂“國外一開源，我們就原創(chuàng)”，有的廠家甚至懶得改造（也可能是沒能力改造），連驅(qū)動(dòng)程序都能直接借用。

除了 MySQL 和 PG 這兩大陣營外，也有一些基于其他開源數(shù)據(jù)庫封裝的，不過數(shù)量很少。有些國產(chǎn)數(shù)據(jù)庫看似原創(chuàng)，但其實(shí)是基于某個(gè)已經(jīng)退出江湖的古老開源數(shù)據(jù)庫改造的，現(xiàn)在很難看出來就被誤以為原創(chuàng)了。

除了使用開源庫封裝，還有一些國內(nèi)數(shù)據(jù)庫廠商通過購買源碼實(shí)現(xiàn)“自主”。像 2015 年有幾家中國公司購買了 Informix 源碼來發(fā)展自己的數(shù)據(jù)庫。

這些“借用別人”的非原創(chuàng)數(shù)據(jù)庫廠商，大多數(shù)并沒有掌握核心技術(shù)，畢竟消化上千萬行代碼也不是一件容易的事兒。雖然手里有源代碼，卻仍然很難進(jìn)行深入的改造，未來升級(jí)發(fā)展也要仰人鼻息。有些時(shí)候甚至還會(huì)有協(xié)議和法律問題，比如 MySQL 現(xiàn)在的所有權(quán)歸 Oracle 所有，天知道哪天 O 記不高興了會(huì)不會(huì)對(duì)我們干些啥。

不過，欣慰的是，還是有少量難能可貴的廠商是從 0 開始自主實(shí)現(xiàn)的。比較有代表性的是 OceanBase。因?yàn)檎Q生于互聯(lián)網(wǎng)企業(yè)，面對(duì)急速擴(kuò)張的業(yè)務(wù)，繼續(xù)使用國外商用數(shù)據(jù)庫無論在成本上還是容量上都難以支撐，自身就有很有很強(qiáng)的動(dòng)力擺脫對(duì)國外產(chǎn)品的依賴，就必須走出一條自研之路。當(dāng)然，從頭自研一個(gè)數(shù)據(jù)庫并非易事，這是個(gè)十年才能磨一劍的艱辛事業(yè)，肯這樣熬的廠商確實(shí)是鳳毛麟角。

除此之外，我們還有另一個(gè)更奇葩的也是十年磨出一劍的，一個(gè)看起來不像數(shù)據(jù)庫卻能完成大量數(shù)據(jù)庫任務(wù)的產(chǎn)品：潤乾軟件開發(fā)的集算器 SPL。它不僅在工程實(shí)現(xiàn)上完全自主開發(fā)，連理論模型都是自己原創(chuàng)的，突破的不僅僅是數(shù)據(jù)庫本身，還有背后的理論框架，這樣的產(chǎn)品在國內(nèi)可以說更是絕無僅有的了。

SPL 是啥？和數(shù)據(jù)庫有啥關(guān)系？效果咋樣？背后又突破了什么理論？下面我們就來說道說道。

SPL的由來

SPL 的開發(fā)主體是潤乾軟件，潤乾報(bào)表你可能聽過或用過，是 20 年前為了解決中國式復(fù)雜報(bào)表制作創(chuàng)新的一個(gè)產(chǎn)品，其中使用了獨(dú)創(chuàng)的非線性報(bào)表模型理論。我們知道，報(bào)表是一個(gè)強(qiáng)數(shù)據(jù)計(jì)算場(chǎng)景，數(shù)據(jù)庫中的數(shù)據(jù)距離要呈現(xiàn)出來的數(shù)據(jù)還很遠(yuǎn)，需要很多步驟的復(fù)雜運(yùn)算才能得到。而報(bào)表工具只能解決呈現(xiàn)環(huán)節(jié)那一步的少量計(jì)算，對(duì)于進(jìn)入報(bào)表工具之前的數(shù)據(jù)計(jì)算則無能為力。這導(dǎo)致了雖然有成熟的報(bào)表工具來解決格式及呈現(xiàn)環(huán)節(jié)的計(jì)算問題，而報(bào)表開發(fā)卻依然很難的現(xiàn)狀。

對(duì)于這個(gè)問題，業(yè)界也沒什么好辦法，只能是寫復(fù)雜 SQL（以及存儲(chǔ)過程）或者在應(yīng)用程序中用高級(jí)語言 （如 Java）編程，十分繁瑣低效。而且由于 SQL 和 Java 的開發(fā)特性，還會(huì)帶來耦合性高、維護(hù)困難等問題。

在這樣的背景下，我們希望找到一種方式來解決數(shù)據(jù)計(jì)算難、計(jì)算慢的問題。我們通過大量總結(jié)分析碰到的各種數(shù)據(jù)計(jì)算問題后發(fā)現(xiàn)，如果繼續(xù)沿用 SQL 的技術(shù)體系無論如何也解決不好這個(gè)問題，充其量在工程上做些優(yōu)化（現(xiàn)在大多數(shù)數(shù)據(jù)庫在做的），新瓶裝舊酒而已。

SQL 的理論基礎(chǔ)是關(guān)系代數(shù)，SQL 之所以難以應(yīng)對(duì)復(fù)雜數(shù)據(jù)計(jì)算，根本原因是背后的關(guān)系代數(shù)理論。想要根本解決這個(gè)問題就不能再基于關(guān)系代數(shù)。

那怎么辦？

既然沒有現(xiàn)成的可用，就只能發(fā)明新的了，使用新的理論模型解決計(jì)算難題！

不過，這事兒說起來輕松，做起來卻不容易。從 2007 年開始，我們用了十多年時(shí)間，歷經(jīng)四次大的重構(gòu)才把模型和結(jié)構(gòu)穩(wěn)定下來，形成了一套理論模型——離散數(shù)據(jù)集，基于這套模型開發(fā)出了 SPL（Structured Process Language），專門用于結(jié)構(gòu)化數(shù)據(jù)計(jì)算的程序設(shè)計(jì)語言，配合有存儲(chǔ)機(jī)制后，也可以理解成為數(shù)據(jù)倉庫產(chǎn)品。

由于 SPL 采用了新的理論模型，在市面上根本沒有其他產(chǎn)品可以借鑒，更不可能有現(xiàn)成的開源代碼可以“借用”，只能完全自己一行一行開發(fā)。所以，SPL 的核心運(yùn)算模型代碼從頭到腳都是完全自主原創(chuàng)的。連理論基礎(chǔ)都是自己發(fā)明的，代碼更加只能原創(chuàng)，你說夠不夠自主？

說到這你可能發(fā)現(xiàn)，SPL 看起來跟傳統(tǒng)數(shù)據(jù)庫不太一樣，它的實(shí)際應(yīng)用效果如何呢？

SPL應(yīng)用效果

對(duì)于大數(shù)據(jù)計(jì)算類任務(wù)來講，就已應(yīng)用的效果來看，SPL 在實(shí)踐中的表現(xiàn)非常出色。實(shí)現(xiàn)復(fù)雜計(jì)算時(shí)，不僅代碼簡(jiǎn)短，性能相較于傳統(tǒng)數(shù)據(jù)庫通常能快一個(gè)數(shù)量級(jí)以上。

國家天文臺(tái)的某個(gè)天體計(jì)算場(chǎng)景：11 張照片，每張 50 萬天體（目標(biāo)規(guī)模為 500 萬），天文距離（三角函數(shù)計(jì)算）較近的天體被視為同一個(gè)，需要將不同照片中的“相同”天體合并，屬性重新聚合。

這個(gè)任務(wù)的技術(shù)本質(zhì)是個(gè)非等值關(guān)聯(lián)，計(jì)算量是平方級(jí)的（也就是 50 萬 *50 萬 =2500 億）。Python 代碼約 200 行，單線程計(jì)算 6.5 天，按個(gè)速度估算，目標(biāo)的 500 萬規(guī)模需要近 2 年時(shí)間，徹底沒有可實(shí)用性；國內(nèi)某大廠的分布式數(shù)據(jù)庫上動(dòng)用了 100 個(gè) CPU 的 SQL 代碼也用了 3.8 小時(shí)，算下來單核計(jì)算速度比 Python 還慢；而 SPL 實(shí)現(xiàn)的優(yōu)化代碼僅 50 多行，利用任務(wù)特點(diǎn)大幅降低了計(jì)算量（遠(yuǎn)不到 2500 億），在 4 核的筆記本上僅用 2 分多鐘就完成了計(jì)算，計(jì)算 500 萬的目標(biāo)規(guī)模只要數(shù)小時(shí)就能搞定，完全可以實(shí)用。

這個(gè)差距的背后：受限于理論模型的 SQL，無法實(shí)現(xiàn)這種優(yōu)化技術(shù)，只能眼睜睜地看著計(jì)算資源消耗；Python 硬編碼雖然可以實(shí)現(xiàn)優(yōu)化算法，但工作量巨大，代碼將遠(yuǎn)不止 200 行；只有 SPL，代碼更短，還跑得更快。

不僅如此，在其他行業(yè)，SPL 的優(yōu)勢(shì)也很明顯。

在某保險(xiǎn)公司團(tuán)體保明細(xì)單查詢場(chǎng)景中，SPL 相比 Oracle 性能提升了 2000 倍，同時(shí)代碼量減少了 5 倍以上……

在某保險(xiǎn)公司車險(xiǎn)跑批計(jì)算優(yōu)化場(chǎng)景中，使用 SPL 將 RDB 跑批時(shí)間從 2 個(gè)小時(shí)優(yōu)化到 17 分鐘，而實(shí)現(xiàn)代碼從原來的 2000 行縮短到不到 500 行……

在某銀行的客戶畫像場(chǎng)景中，SPL 將用戶畫像客群交集計(jì)算性能提升了 200 倍以上……

在某金融用戶的報(bào)表查詢場(chǎng)景中，SPL 將報(bào)表計(jì)算時(shí)間從 3700 秒縮短到 105 秒，提升了 35 倍多……

……

類似的案例 SPL 實(shí)施過不少，還沒有失手過，平均提速超過一個(gè)數(shù)量級(jí)，同時(shí)代碼量降低數(shù)倍。

這里還有一份性能測(cè)試報(bào)告：《全國產(chǎn)計(jì)算數(shù)據(jù)庫性能測(cè)試報(bào)告》（http://c.raqsoft.com.cn/article/1564972044122）。用 SPL 在國產(chǎn)芯片上實(shí)現(xiàn)的運(yùn)算，能超越在 Intel 芯片上跑的 Oracle。這都是 SPL 理論創(chuàng)新（離散數(shù)據(jù)集）帶來的效果。

SPL為什么更強(qiáng)

我們看到 SPL 的應(yīng)用效果后不禁要問，SPL 到底有何種魔法居然能達(dá)到這些驚為天人的效果？SPL 背后的理論基礎(chǔ)離散數(shù)據(jù)集模型到底是什么樣的？

SPL 的優(yōu)勢(shì)主要集中在兩點(diǎn)，實(shí)現(xiàn)數(shù)據(jù)計(jì)算的代碼簡(jiǎn)短（寫得簡(jiǎn)單），而且性能更高（跑得快）。那是 SPL 改變了計(jì)算機(jī)的速度了嗎？并沒有，軟件不可能改變硬件的性能。SPL 更強(qiáng)的原因是因?yàn)樵O(shè)計(jì)了很多別人沒有的算法（和存儲(chǔ)機(jī)制），基于這些算法可以讓計(jì)算機(jī)少執(zhí)行一些運(yùn)算，從而獲得高性能，而這些算法大都要依靠離散數(shù)據(jù)集理論才能很好實(shí)現(xiàn)。

下面是 SPL 的部分算法，很多都是 SPL 的獨(dú)創(chuàng)發(fā)明，在業(yè)內(nèi)首次提出，窺一斑而知全豹。

像常見的 TopN 運(yùn)算，在 SPL 中 TopN 被理解為聚合運(yùn)算，這樣可以將高復(fù)雜度的排序轉(zhuǎn)換成低復(fù)雜度的聚合運(yùn)算，而且很還能擴(kuò)展應(yīng)用范圍。

和 SQL 不同，SPL 完成這個(gè)運(yùn)算的語句中沒有排序字樣，也就不會(huì)產(chǎn)生大排序的動(dòng)作，在全集還是分組中計(jì)算 TopN 的語法基本一致，不僅寫法上更簡(jiǎn)單，性能也更高。而 SQL 只能寫出有排序字樣的語句，是不是能跑得快就只能指望數(shù)據(jù)庫的優(yōu)化引擎了，簡(jiǎn)單情況時(shí)數(shù)據(jù)庫還能對(duì)付，但情況復(fù)雜時(shí)連 Oracle 這樣的資深數(shù)據(jù)庫都會(huì)“暈掉”，這里有相關(guān)的詳細(xì)測(cè)試案例：性能優(yōu)化技巧：TopN 。

我們已經(jīng)將 SPL 的離散數(shù)據(jù)集理論整理成論文（ SPL論文 http://c.raqsoft.com.cn/article/1653097658478 ），其中嚴(yán)格地定義了離散數(shù)據(jù)集代數(shù)體系，并描述了它與關(guān)系代數(shù)的不同。

高性能靠的不是代碼，而是代數(shù)，代碼只是個(gè)實(shí)現(xiàn)手段而已，關(guān)鍵是 SPL 背后的理論體系中提供的數(shù)據(jù)類型和算法以及存儲(chǔ)模型。

這篇文章 寫著簡(jiǎn)單跑得又快的數(shù)據(jù)庫語言SPL 中用更通俗的說法解釋了 SPL 的高效原理。關(guān)系代數(shù)和 SQL 就像小學(xué)時(shí)代的算術(shù)，只有加減乘除，而離散數(shù)據(jù)集和 SPL 則相當(dāng)于增加了中學(xué)的乘方開方指數(shù)對(duì)數(shù)。加減乘除可以應(yīng)對(duì)日常購物買菜，但要造出飛機(jī)大樓就必須用到更多的數(shù)學(xué)了。

了解了這些，再看前文提到的在國產(chǎn)芯片上跑出超越 Oracle 在 Intel 芯片上的性能也就不神奇了。即使國產(chǎn)芯片還有很長(zhǎng)的路要走，基于 SPL 打造完全自主、高效的國產(chǎn)數(shù)據(jù)庫也能成為現(xiàn)實(shí)，讓國產(chǎn)芯片也能插上翅膀騰飛起來。

SPL的未來

當(dāng)然，SPL 本身也還有很長(zhǎng)的路要走，目前已發(fā)布的功能還只面向 OLAP（數(shù)據(jù)分析）場(chǎng)景，主要解決數(shù)據(jù)計(jì)算難題。我們知道，數(shù)據(jù)庫除了計(jì)算還有交易，就是常說的 OLTP 能力。在面向交易的場(chǎng)景，SPL 仍然會(huì)通過創(chuàng)新解決當(dāng)前數(shù)據(jù)庫面臨的各類問題。

還是創(chuàng)新

現(xiàn)在數(shù)據(jù)庫上云已經(jīng)是大勢(shì)所趨，但是簡(jiǎn)單地把關(guān)系數(shù)據(jù)庫從本地搬到云上并不能體現(xiàn)出云應(yīng)用的特征。云應(yīng)用的基本特征在于數(shù)據(jù)結(jié)構(gòu)的多樣性。云數(shù)據(jù)庫要同時(shí)為多個(gè)用戶提供服務(wù)，而不同用戶的數(shù)據(jù)結(jié)構(gòu)可能不同，同一個(gè)用戶在不同時(shí)段的數(shù)據(jù)結(jié)構(gòu)也會(huì)變，這樣就會(huì)積累大量不同結(jié)構(gòu)的數(shù)據(jù)要一起存儲(chǔ)和計(jì)算。這就會(huì)面臨個(gè)性化（不同數(shù)據(jù)結(jié)構(gòu)）和海量用戶的矛盾，這是關(guān)系數(shù)據(jù)庫無法解決的問題。

事實(shí)上，50 年前誕生的數(shù)據(jù)庫在設(shè)計(jì)時(shí)并沒有考慮過這個(gè)問題（也不可能想到 50 年后的需求），因此關(guān)系代數(shù)中幾乎沒有設(shè)計(jì)針對(duì)多樣性結(jié)構(gòu)數(shù)據(jù)的處理能力。想要解決這個(gè)問題就不能再沿用關(guān)系代數(shù)體系。

同時(shí)，關(guān)系數(shù)據(jù)庫在實(shí)現(xiàn)一致性時(shí)成本過高，資源消耗嚴(yán)重，導(dǎo)致并發(fā)能力下降。而高并發(fā)又是云應(yīng)用的典型特性，這又成了一對(duì)不可調(diào)和的矛盾。這個(gè)問題的原因在于它的數(shù)據(jù)組織機(jī)制（數(shù)據(jù)類型），這仍然是由其理論關(guān)系代數(shù)決定的。想要同時(shí)兼顧一致性和高并發(fā)就還要打破關(guān)系代數(shù)的限制，換一種方式組織和存儲(chǔ)數(shù)據(jù)。

突破理論限制才能從根本上解決問題，SPL（離散數(shù)據(jù)集）正當(dāng)時(shí)！

這個(gè)未來也并不遙遠(yuǎn)，SPL 面向 OLTP 的功能已經(jīng)在實(shí)驗(yàn)室中打磨了幾年，再完善一段時(shí)間就可以亮劍出竅，屆時(shí)完全基于自主原創(chuàng)理論的國產(chǎn)數(shù)據(jù)庫將劃破天際。

超越

同時(shí)，理論上的創(chuàng)新還可能帶來另外一個(gè)結(jié)果，那就是：超越！在數(shù)據(jù)庫領(lǐng)域?qū)崿F(xiàn)對(duì)國外產(chǎn)品的超越。

我們明白，作為追趕者，采用技術(shù)跟隨戰(zhàn)略是沒希望的。目前的國產(chǎn)數(shù)據(jù)庫絕大多數(shù)仍然是關(guān)系數(shù)據(jù)庫，可以說都是技術(shù)跟隨者。而國外巨頭們做這些事已經(jīng)好幾十年，人強(qiáng)錢多積累厚，我又沒有三頭六臂，憑什么超越人家呢？唯一的可能就是對(duì)手犯錯(cuò)，但是作為十名開外的我們不能指望前面 N 名對(duì)手同時(shí)犯錯(cuò)吧。而寄希望于某種政策把國外產(chǎn)品拒之門外，也有點(diǎn)沒出息不是，而且在這開放的年代也不太可能出現(xiàn)這種情況。

那么就唯有創(chuàng)新！

數(shù)據(jù)庫，我們必須比對(duì)手做得更好，還要好很多，這樣才有機(jī)會(huì)超越，才能彌補(bǔ)生態(tài)的不完善。而要做得更好，就需要有顛覆性的技術(shù)，在新技術(shù)面前我們和對(duì)手是站在同一起跑線上的。

關(guān)系數(shù)據(jù)庫已經(jīng)發(fā)明了幾十年，早就不適應(yīng)現(xiàn)代更復(fù)雜的應(yīng)用需求和更強(qiáng)大的硬件環(huán)境，很多看似簡(jiǎn)單的問題非常難做，開發(fā)維護(hù)成本很高，也不能充分利用計(jì)算機(jī)資源，眼睜睜地忍受低性能。

對(duì)于那些關(guān)系數(shù)據(jù)庫巨頭來講，要向股東交代，就要保持穩(wěn)定的收益，它還不能隨便革掉自己的命，結(jié)果反而處于相對(duì)不利的局面。這就給了能在理論層面創(chuàng)新的產(chǎn)品機(jī)會(huì)，實(shí)現(xiàn)超越并非異想天開。

馬車再高檔也還是馬車，無論如何優(yōu)化都還是要靠馬拉動(dòng)。初生的汽車，操作上當(dāng)然會(huì)有各種不習(xí)慣，功能上也會(huì)有眾多不如意。但它是發(fā)動(dòng)機(jī)驅(qū)動(dòng)的，假以時(shí)日不斷完善，它的巨大優(yōu)勢(shì)必將全面碾壓馬車。

讓我們拭目以待，也讓我們砥礪前行！

來源：數(shù)據(jù)猿