前段時間的俄烏沖突，Oracle 宣布“暫停在俄羅斯的所有業(yè)務”，相信大家的心情絕不是隔岸觀火，而是細思恐極。

數(shù)據(jù)庫號稱 IT 領域三大核心之一（其他兩個是 CPU 和操作系統(tǒng)），一直以來都被國際巨頭壟斷，人家控制著核心，想什么時候鎖喉就什么時候鎖，你一點辦法都沒有。

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

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

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

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

其實沒多少！甚至可以粗暴一點說：幾乎沒有！

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

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

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

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

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

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

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

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

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

SPL 的由來

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

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

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

SQL 的理論基礎是關系代數(shù)，SQL 之所以難以應對復雜數(shù)據(jù)計算，根本原因是背后的關系代數(shù)理論。想要根本解決這個問題就不能再基于關系代數(shù)。

那怎么辦？

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

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

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

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

SPL 應用效果

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

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

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

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

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

在某保險公司團體保明細單查詢場景中，SPL 相比 Oracle 性能提升了 2000 倍，同時代碼量減少了 5 倍以上……

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

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

在某金融用戶的報表查詢場景中，SPL 將報表計算時間從 3700 秒縮短到 105 秒，提升了 35 倍多……

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

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

SPL 為什么更強

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

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

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

像常見的 TopN 運算，在 SPL 中 TopN 被理解為聚合運算，這樣可以將高復雜度的排序轉換成低復雜度的聚合運算，而且很還能擴展應用范圍。

A

1=file（“data.ctx”）.open（）.cursor（）

2=A1.groups（;top（10，amount））金額在前 10 名的訂單

3=A1.groups（area;top（10，amount））每個地區(qū)金額在前 10 名的訂單

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

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

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

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

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

SPL 的未來

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

還是創(chuàng)新

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

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

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

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

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

超越

同時，理論上的創(chuàng)新還可能帶來另外一個結果，那就是：超越！在數(shù)據(jù)庫領域實現(xiàn)對國外產品的超越。

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

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

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

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

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

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

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

審核編輯 ：李倩