有沒有完全自主的國產化資料庫技術_Java中文社群

前段時間的俄烏衝突，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實施過不少，還沒有失手過，平均提速超過一個數量級，同時代碼量降低數倍。

這裡還有一份效能測試報告：《全國產計算資料庫效能測試報告》。用 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論文），其中嚴格地定義了離散資料集代數體系，並描述了它與關係代數的不同。

高效能靠的不是程式碼，而是代數，程式碼只是個實現手段而已，關鍵是SPL背後的理論體系中提供的資料型別和演算法以及儲存模型。

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

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

SPL的未來

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

還是創新

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

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

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

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

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

超越

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

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

那麼就唯有創新！

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

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

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

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

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

## SPL資料