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

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

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

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

國產數據庫現狀

這幾年，雨后春筍般地冒出數百個國產數據庫，但有多少擁有原創技術呢？

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

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

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

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

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

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

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

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

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

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

SPL 的由來

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

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

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

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

那怎么辦？

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

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

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

說到這你可能發現，SPL 看起來跟傳統數據庫不太一樣，它的實際應用效果如何呢？

SPL 應用效果

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

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

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

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

不僅如此，在其他行業，SPL 的優勢也很明顯。

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

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

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

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

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

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

SPL 為什么更強

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

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

下面是 SPL 的部分算法，很多都是 SPL 的獨創發明，在業內首次提出，窺一斑而知全豹。

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

A

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

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

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

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

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

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

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

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

SPL 的未來

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

還是創新

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

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

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

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

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

超越

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

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

那么就唯有創新！

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

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

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

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

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

審核編輯 ：李倩