5月21日，任正非接受媒體采訪。2萬字的媒體實(shí)錄中，74歲的任正非在回答中27次提及了“數(shù)學(xué)”，例舉了諸多數(shù)學(xué)對(duì)于華為的重要性。

這不是任正非和華為第一次強(qiáng)調(diào)數(shù)學(xué)。這個(gè)一直偏冷門的基礎(chǔ)學(xué)科在近年來的技術(shù)浪潮和貿(mào)易戰(zhàn)背景下，再一次被提上了新的高度。

那么，數(shù)學(xué)在數(shù)據(jù)和AI研發(fā)中到底有什么作用？在這場(chǎng)中國(guó)的自主創(chuàng)新征戰(zhàn)中，數(shù)學(xué)人又能發(fā)揮怎樣的作用呢？

對(duì)于這個(gè)話題，或許沒有人比蔣步星更有發(fā)言權(quán)。

上個(gè)世紀(jì)80年代，蔣步星作為第一代奧數(shù)選手在德國(guó)布倫瑞克市獲得了國(guó)際數(shù)學(xué)奧林匹克競(jìng)賽（imo）獲得個(gè)人金獎(jiǎng)和團(tuán)體賽冠軍。

也是在當(dāng)年，他進(jìn)入了清華大學(xué)計(jì)算機(jī)系理論班。1996年清華大學(xué)計(jì)算機(jī)系碩士畢業(yè)后，他先后在清華大學(xué)及紫光、長(zhǎng)天等公司任職主持信息系統(tǒng)開發(fā)，2000年創(chuàng)立潤(rùn)乾公司，致力于研發(fā)包括數(shù)據(jù)庫在內(nèi)的通用基礎(chǔ)軟件。

近日，蔣步星老師也撰長(zhǎng)文，分享了自己如何用數(shù)學(xué)，做中國(guó)人自己的數(shù)據(jù)庫系統(tǒng)，從中可一窺一個(gè)“數(shù)學(xué)人”的家國(guó)情懷和實(shí)業(yè)精神。

以下為全文：

題目《莫非我就是被時(shí)代呼喚的數(shù)學(xué)人？》

作者：蔣步星

最近中美貿(mào)易戰(zhàn)，華為成了焦點(diǎn)。任老爺子一席大論，據(jù)說有27次提到了數(shù)學(xué)；緊接著，某著名公號(hào)的一篇《時(shí)代呼喚數(shù)學(xué)家》又刷了屏，直把數(shù)學(xué)家推到了風(fēng)口浪尖，讓人感覺數(shù)學(xué)的春天就要來了。

熟悉我所做工作的朋友也來問我：是不是有很多人來找我了。其實(shí)慚愧，并沒有多少，所以寫個(gè)文章蹭蹭熱點(diǎn)宣傳一下。

我是在用數(shù)學(xué)搞軟件，但距離主流數(shù)學(xué)很遠(yuǎn)，而且遠(yuǎn)未成功，不敢妄稱為“家”，因此把標(biāo)題改了下，謙虛些說是數(shù)學(xué)人吧。

我在做什么？

我們?cè)诟闾?hào)稱IT三大核心技術(shù)之一的數(shù)據(jù)庫！另外兩大是CPU和操作系統(tǒng)。CPU太硬，我毫無發(fā)言權(quán)；操作系統(tǒng)略知一二，發(fā)言權(quán)也不多。數(shù)據(jù)庫領(lǐng)域嘛，確實(shí)是比較熟悉的。

我國(guó)的數(shù)據(jù)庫做得怎樣呢？

N年前，除了國(guó)外巨頭外，只有幾個(gè)國(guó)家隊(duì)在搞數(shù)據(jù)庫（所謂國(guó)家隊(duì)，其實(shí)也是企業(yè)，但主要由政府資金來支持）。不客氣說，國(guó)家隊(duì)做得很差。這無關(guān)從業(yè)人員的能力和情懷，而是路子方向的問題。國(guó)家隊(duì)做數(shù)據(jù)庫，并不是因?yàn)橛行枨蟠碳?，而就是為了做而做，技術(shù)路線也基本是抄（有些直接拿開源改），這要能做好才是奇怪的事情。去年中興事件時(shí)，我寫了一篇文章《國(guó)產(chǎn)數(shù)據(jù)庫通通都沒戲！》說這個(gè)現(xiàn)象。

近年來，有許多企業(yè)加入數(shù)據(jù)庫開發(fā)的行列。企業(yè)隊(duì)和國(guó)家隊(duì)的根本不同在于，企業(yè)隊(duì)有明確的需求，也就是很清楚地知道要解決的問題。特別是互聯(lián)網(wǎng)行業(yè)中巨大用戶量的應(yīng)用，繼續(xù)使用國(guó)外數(shù)據(jù)庫，要么撐不住，要么買不起。在需求的刺激下，做出來的產(chǎn)品在某些方面就能夠達(dá)到世界領(lǐng)先水平了。在競(jìng)爭(zhēng)中的國(guó)家隊(duì)也開始企業(yè)化轉(zhuǎn)型，能力也在不斷提升。

不過，過去的國(guó)家隊(duì)固然沒什么建樹，今天的企業(yè)隊(duì)也仍然只是在工程上進(jìn)行優(yōu)化，使自家產(chǎn)品比國(guó)外產(chǎn)品更適合某類場(chǎng)景，并沒有獲得壓倒性的優(yōu)勢(shì)。面臨的技術(shù)難題也只是得到了一定程度的緩解，沒有從根本上解決。

其實(shí)不僅國(guó)內(nèi)，全世界范圍也是這樣。大家都只是在工程上做些優(yōu)化，甚至有些搞法也只能叫改造不能說是優(yōu)化。比如NoSQL產(chǎn)品，在吞吐率上做了提升，但嚴(yán)重犧牲了計(jì)算能力，還放棄了某些場(chǎng)合很重要的一致性能力；某些NewSQL產(chǎn)品為了擴(kuò)展能力和一致性做了妥協(xié)；而近年來熱門的大數(shù)據(jù)庫平臺(tái)Hadoop，原本試圖顛覆傳統(tǒng)關(guān)系型數(shù)據(jù)倉庫，但搞來搞去又在回歸到SQL去了。

我怎么做數(shù)據(jù)庫？

我們發(fā)明新數(shù)學(xué)！

現(xiàn)在的數(shù)據(jù)庫在用什么數(shù)學(xué)呢？

目前主流數(shù)據(jù)庫是關(guān)系數(shù)據(jù)庫，之所以這么叫，是因?yàn)樗臄?shù)學(xué)基礎(chǔ)被稱為關(guān)系代數(shù)，這是少有的幾項(xiàng)計(jì)算機(jī)領(lǐng)域?qū)Ｓ玫臄?shù)學(xué)。

關(guān)系代數(shù)已經(jīng)發(fā)明近五十年了，五十年前的應(yīng)用需求以及硬件環(huán)境，和今天比的差異是很巨大了，繼續(xù)延用五十年前的理論來解決今天的問題，是不是聽著就感覺太陳舊了？然而現(xiàn)實(shí)就是這樣，由于存量用戶太多，而且也還沒有成熟的新技術(shù)出現(xiàn)，基于關(guān)系代數(shù)設(shè)計(jì)的SQL，今天仍然是最重要的數(shù)據(jù)庫開發(fā)語言。雖然這幾十年來也有一些改進(jìn)完善，但根子并沒有變，面對(duì)當(dāng)代的復(fù)雜需求和硬件環(huán)境，關(guān)系數(shù)據(jù)庫并沒有那么得心應(yīng)手了。

舊瓶難再裝新酒。

要說清這個(gè)問題，我們要看數(shù)據(jù)庫到底在干什么事情？

數(shù)據(jù)庫這個(gè)產(chǎn)品，名字中有個(gè)庫字，會(huì)讓人覺得它主要是為了存儲(chǔ)的。其實(shí)不然，簡(jiǎn)單的存儲(chǔ)很容易解決，數(shù)據(jù)庫真正干的事有兩條：計(jì)算、交易！存儲(chǔ)也是為這兩件事服務(wù)的。

計(jì)算問題

先說計(jì)算，也就是我們常說的OLAP能力。這里我更愿意用計(jì)算這個(gè)詞，而不用分析（OLAP中的A）。計(jì)算的概念更廣泛且更務(wù)實(shí)一些，它并不單指加加減減，查找、關(guān)聯(lián)都可以看成是某種計(jì)算。

什么樣的計(jì)算體系才算好呢？

又是兩條：寫著簡(jiǎn)單、跑得快。

寫著簡(jiǎn)單，很好理解，就是讓程序員很快能寫出來代碼來，這樣單位時(shí)間內(nèi)可以完成更多的工作；跑得快更容易理解，我們當(dāng)然希望更短時(shí)間內(nèi)獲得計(jì)算結(jié)果。

那么，關(guān)系數(shù)據(jù)庫，或者說SQL，在這兩方面做得怎么樣呢？

SQL語句很象英語，有些查詢可以當(dāng)英語來讀和寫（網(wǎng)上多得很，就不舉例了），這應(yīng)當(dāng)算是滿足寫著簡(jiǎn)單這一條了吧。

且慢！我們?cè)诮炭茣峡吹降腟QL經(jīng)常只有兩三行，這些SQL確實(shí)算是寫著簡(jiǎn)單的，但如果我們嘗試一些稍復(fù)雜化的問題呢？

我經(jīng)常舉的一個(gè)其實(shí)還算簡(jiǎn)單的例子：計(jì)算一支股票最長(zhǎng)連續(xù)上漲了多少天？用SQL寫出來是這樣的：

SELECT MAX（連續(xù)日數(shù)） FROM （SELECT COUNT（*） 連續(xù)日數(shù) FROM （SELECT SUM（漲跌標(biāo)志） OVER （ ORDER BY 交易日） 不漲日數(shù) FROM （ SELECT 交易日， CASE WHEN 收盤價(jià)》LAG（收盤價(jià)） OVER（ ORDER BY 交易日 THEN 0 ELSE 1 END 漲跌標(biāo)志 FROM 股票 ）） GROUP BY 不漲日數(shù)）

這個(gè)語句的工作原理就不解釋了，程序員們可以自己嘗試一下。

這曾經(jīng)是我公司的招聘考題，通過率不足20%；因?yàn)樘y，后來把它改了一種方式：把SQL語句寫出來讓應(yīng)聘者解釋它在算什么，通過率依然不高。這說明什么？說明SQL即難懂又難寫！

再看跑得快的問題，還是一個(gè)經(jīng)常拿出來的簡(jiǎn)單例子：1億條數(shù)據(jù)中取前10名。這個(gè)任務(wù)用SQL寫出來并不復(fù)雜：

SELECT TOP 10 x FROM T ORDER BY x DESC

但是，這個(gè)語句對(duì)應(yīng)的執(zhí)行邏輯是先對(duì)所有數(shù)據(jù)進(jìn)行大排序，然后再取出前10個(gè)，后面的不要了。大家知道，排序是一個(gè)很慢的動(dòng)作，會(huì)多次遍歷數(shù)據(jù)，如果數(shù)據(jù)量大到內(nèi)存裝不下，那還需要外存做緩存，性能還會(huì)進(jìn)一步急劇下降。如果嚴(yán)格按這句SQL體現(xiàn)的邏輯去執(zhí)行，這個(gè)運(yùn)算無論如何是跑不快的。然而，很多程序員都知道這個(gè)運(yùn)算并不需要大排序，也用不著外存緩存，一次遍歷用一點(diǎn)點(diǎn)內(nèi)存就可以完成，也就是存在更高性能的算法?？上У氖?，用SQL卻寫不出這樣的算法，只能寄希望于數(shù)據(jù)庫的優(yōu)化器足夠聰明，能把這句SQL轉(zhuǎn)換成高性能算法執(zhí)行，但情況復(fù)雜時(shí)數(shù)據(jù)庫的優(yōu)化器也未必靠譜。

看樣子，SQL，也就是關(guān)系數(shù)據(jù)庫，在這兩方面做得并不好。這兩個(gè)并不復(fù)雜的問題都是這樣，現(xiàn)實(shí)中數(shù)千行的SQL代碼中，這種難寫且跑不快的情況比比皆是。

為什么SQL做得不夠好呢？

要回答這個(gè)問題，我們需要分析一下用程序?qū)崿F(xiàn)計(jì)算到底是在干什么。

本質(zhì)上講，編寫程序的過程，就是把解決問題的思路翻譯成計(jì)算機(jī)可執(zhí)行的精確化形式語言的過程。舉例來說，就象小學(xué)生解應(yīng)用題，分析問題想出解法之后，還要列出四則運(yùn)算表達(dá)式。用程序計(jì)算也是一樣，不僅要想出解決問題的方法，還要把解法翻譯成計(jì)算機(jī)能理解執(zhí)行的動(dòng)作才算完成。

用于描述計(jì)算方法的形式語言，其核心在于所采用的代數(shù)體系。所謂代數(shù)體系，簡(jiǎn)單說就是一些數(shù)據(jù)類型和其上的運(yùn)算規(guī)則，比如小學(xué)學(xué)到的算術(shù)，就是整數(shù)和加減乘除運(yùn)算。有了這套東西，我們就能把想做的運(yùn)算用這個(gè)代數(shù)體系約定的符號(hào)寫出來，也就是代碼，然后計(jì)算機(jī)就可以執(zhí)行了。

如果這個(gè)代數(shù)體系設(shè)計(jì)時(shí)考慮不周到，提供的數(shù)據(jù)類型和運(yùn)算不方便，那就會(huì)導(dǎo)致描述算法非常困難。這時(shí)候會(huì)發(fā)生一個(gè)怪現(xiàn)象：翻譯解法到代碼的難度遠(yuǎn)遠(yuǎn)超過解決問題本身。

舉個(gè)例子，我們從小學(xué)習(xí)用阿拉伯?dāng)?shù)字做日常計(jì)算，實(shí)施加減乘除都很方便，所有人都天經(jīng)地義認(rèn)為數(shù)值運(yùn)算就該是這樣的。其實(shí)未必！我想大多數(shù)人都知道還有一種叫做羅馬數(shù)字的東西，我不知道羅馬數(shù)字體系是不是還有我們熟悉的加減乘除運(yùn)算（它那個(gè)數(shù)字體系無法象阿拉伯?dāng)?shù)字這樣方便地實(shí)施這些運(yùn)算，很可能運(yùn)算定義也不同了），我也一直很困惑古羅馬人是如何上街買菜的？

這樣，我們知道了，程序難寫很大程度是代數(shù)的問題。

再看跑不快的原因。

軟件沒辦法改變硬件的性能，CPU和硬盤該多快就是多快。不過，我們可以設(shè)計(jì)出低復(fù)雜度的算法，也就是計(jì)算量更小的算法，這樣計(jì)算機(jī)執(zhí)行的動(dòng)作變少，自然也就會(huì)快了。但是，光想出算法還不夠，還要把這個(gè)算法用某種形式語言寫得出來才行，否則計(jì)算機(jī)不會(huì)執(zhí)行。

而且，寫起來還要比較簡(jiǎn)單，都要寫很長(zhǎng)很麻煩，也沒有人會(huì)去用。所以呢，對(duì)于程序來講，跑得快和寫著簡(jiǎn)單其實(shí)是同一個(gè)問題，背后還是這個(gè)形式語言采用的代數(shù)的問題。如果這個(gè)代數(shù)不好，就會(huì)導(dǎo)致高性能算法很難實(shí)現(xiàn)甚至實(shí)現(xiàn)不了，也就沒辦法跑得快了。就象上面說的，用SQL寫不出我們期望的小內(nèi)存單次遍歷算法，能不能跑得快就只能寄希望于優(yōu)化器。

我們?cè)僮鰝€(gè)類比：

在國(guó)內(nèi)上過小學(xué)的同學(xué)大概都知道高斯計(jì)算1+2+3+.。.+100的小故事。普通人就是一步步地硬加100次，高斯小朋友很聰明，發(fā)現(xiàn)1+100=101、2+99=101、。..、50+51=101，結(jié)果是50乘101，很快算完回家午飯了。

聽過這個(gè)故事，我們都會(huì)感慨高斯很聰明，能想到這么巧妙的辦法，即簡(jiǎn)單又迅速。這沒有錯(cuò)，但是，大家容易忽略一點(diǎn)：在高斯的時(shí)代，人類的算術(shù)體系（也是一個(gè)代數(shù)）中已經(jīng)有了乘法！象前面所說，我們從小學(xué)習(xí)四則運(yùn)算，會(huì)覺得乘法是理所當(dāng)然的，其實(shí)并不是，乘法是后于加法被發(fā)明出來的。如果高斯的年代還沒有乘法，即使有聰明的高斯，也沒辦法快速解決這個(gè)問題。

現(xiàn)在，我們可以回答前面的問題：為什么關(guān)系數(shù)據(jù)庫在我們期望的那兩個(gè)方面做得不夠好？

問題出在關(guān)系代數(shù)上，關(guān)系代數(shù)就象只有加法還沒發(fā)明乘法的算法體系，很多事做不好是必然的。

而且，不幸的是，這個(gè)問題是理論上的，在工程上無論如何優(yōu)化也無濟(jì)于事，只能有限改善，不能根除。不過，絕大部分的數(shù)據(jù)庫開發(fā)者并不會(huì)想到這一層，或者說為了照顧存量用戶的兼容性，也沒打算想到這一層。于是，主流數(shù)據(jù)庫界一直在這個(gè)圈圈里打轉(zhuǎn)轉(zhuǎn)。

那么該怎么辦呢？也就是如何讓計(jì)算寫著更簡(jiǎn)單、跑得更快呢？

發(fā)明新的代數(shù)！有“乘法”的代數(shù)。

嗯，數(shù)學(xué)來了！

交易問題

說完計(jì)算，我們?cè)僬f說交易，也就是常說的OLTP能力。

現(xiàn)在是云計(jì)算的時(shí)代，幾乎所有的數(shù)據(jù)庫廠商都在忙著上云。但是，目前這個(gè)數(shù)據(jù)庫真地適合上云嗎？

其實(shí)，包括某些世界巨頭在內(nèi)的所謂云數(shù)據(jù)庫，就是把家里的數(shù)據(jù)庫物理地搬到云服務(wù)器上而已，其它方面仍然只是工程上的改造，在強(qiáng)一致性和可擴(kuò)展性之間進(jìn)行一定的權(quán)衡妥協(xié)，應(yīng)用開發(fā)過程和傳統(tǒng)數(shù)據(jù)庫沒有太大區(qū)別。當(dāng)然，我們不能說這就不算是云應(yīng)用，但這種機(jī)制并未體現(xiàn)云應(yīng)用的基本特征。

云應(yīng)用的基本特征在于數(shù)據(jù)結(jié)構(gòu)的多樣性。

云應(yīng)用將打破企業(yè)界限，不象傳統(tǒng)應(yīng)用每個(gè)用戶做一個(gè)，而是云服務(wù)商提供一個(gè)系統(tǒng)面對(duì)所有用戶；應(yīng)用也不象以前那樣一期一期做下去，而要永遠(yuǎn)在線，只能熱升級(jí)。不同用戶的數(shù)據(jù)結(jié)構(gòu)不完全一樣，同一個(gè)用戶在不同時(shí)段的數(shù)據(jù)結(jié)構(gòu)也會(huì)變，這樣就會(huì)積累大量不同結(jié)構(gòu)的數(shù)據(jù)要一起存儲(chǔ)和計(jì)算。這是關(guān)系數(shù)據(jù)庫在設(shè)計(jì)時(shí)沒有被考慮過的問題，因?yàn)殛P(guān)系代數(shù)幾乎沒有設(shè)計(jì)針對(duì)多樣性結(jié)構(gòu)數(shù)據(jù)的處理能力。

繼續(xù)采用關(guān)系數(shù)據(jù)庫（或其變種）應(yīng)對(duì)云應(yīng)用，就會(huì)面臨個(gè)性化和海量用戶之間的矛盾：想要海量用戶，就要犧牲個(gè)性化（所有用戶面對(duì)同樣數(shù)據(jù)結(jié)構(gòu)的應(yīng)用）；想要個(gè)性化（各有各的數(shù)據(jù)結(jié)構(gòu)）就要犧牲用戶量（只服務(wù)相對(duì)數(shù)量較少的用戶）。但是云應(yīng)用恰恰要求個(gè)性化和大用戶量這兩個(gè)特征并存。

交易數(shù)據(jù)庫還有個(gè)重要指標(biāo)是保證一致性（網(wǎng)上解釋很多，這里不贅述）。關(guān)系數(shù)據(jù)庫雖然能夠?qū)崿F(xiàn)一致性，但資源消耗嚴(yán)重，這會(huì)導(dǎo)致并發(fā)能力下降，而多并發(fā)又是云應(yīng)用常有的特征。

關(guān)系數(shù)據(jù)庫實(shí)現(xiàn)一致性的成本過高，原因在于它的數(shù)據(jù)組織機(jī)制，這由參與操作的數(shù)據(jù)類型決定，而數(shù)據(jù)類型是被關(guān)系代數(shù)規(guī)定的。

和前面說的多樣性一樣，想要實(shí)現(xiàn)低成本的一致性，就要打破關(guān)系代數(shù)，換一種方式組織和存儲(chǔ)數(shù)據(jù)。

嗯，還是數(shù)學(xué)！

在路上

用了這么多篇幅說明當(dāng)前數(shù)據(jù)庫采用的代數(shù)體系有問題，這是一回事。而發(fā)明一個(gè)新的代數(shù)體系，那完全是另一回事。僅僅改進(jìn)某一項(xiàng)運(yùn)算并不算很困難，但要將各種數(shù)據(jù)類型和運(yùn)算整合在一個(gè)體系中，保證封閉和自洽，這就會(huì)是一個(gè)巨大的挑戰(zhàn)。

這里就封閉和自洽解釋一下。封閉性是指任何計(jì)算結(jié)果必須仍然屬于定義過的數(shù)據(jù)類型，一個(gè)不滿足封閉性的代數(shù)無法連續(xù)地運(yùn)算。比如整數(shù)對(duì)加減乘封閉，而對(duì)除法不封閉，在整數(shù)范圍內(nèi)就不能連續(xù)隨意地做四則運(yùn)算，要么對(duì)除法做限制，要么把整數(shù)擴(kuò)展到有理數(shù)。

而自洽性是指這些運(yùn)算不能出現(xiàn)矛盾的結(jié)果，比如我們要約定不能除以0，否則把某個(gè)數(shù)除以0規(guī)定成任何數(shù)都能推出邏輯矛盾，這個(gè)體系就沒法計(jì)算出正確的東西。封閉性和自洽性是合理代數(shù)體系必須滿足的條件。

同時(shí)在應(yīng)用方面，為了讓它有足夠的描述能力，也就是讓我們常見的需求都能輕松用基本數(shù)據(jù)類型和運(yùn)算組合出來，這就希望數(shù)據(jù)類型和運(yùn)算盡量多。但是，為了降低整體的復(fù)雜度和相應(yīng)的學(xué)習(xí)成本，又要讓數(shù)據(jù)類型和運(yùn)算盡量少。這一多一少的權(quán)衡也是個(gè)學(xué)問。數(shù)學(xué)上有個(gè)最小完備集這個(gè)概念，大體就是這個(gè)意思，我們?cè)O(shè)計(jì)的數(shù)據(jù)類型和運(yùn)算要正好夠，沒有多余的也沒有不足的。

結(jié)果呢，我們用了十年時(shí)間，歷經(jīng)四次推倒重構(gòu)，今天才終于能把OLAP功能發(fā)布出來，而解決OLTP的云數(shù)據(jù)庫仍在實(shí)驗(yàn)環(huán)境中打磨。

當(dāng)年我在清華BBS上的網(wǎng)名就是“十年磨一劍”，一語成讖。

十年磨出個(gè)什么東西呢？

磨出了新的代數(shù)！我們起了個(gè)數(shù)學(xué)味道的名字：離散數(shù)據(jù)集?；谶@個(gè)代數(shù)，我們?cè)O(shè)計(jì)了新的形式語言，起名為SPL（Structured Process Language）。

這篇文章內(nèi)不合適詳細(xì)解釋離散數(shù)據(jù)集的內(nèi)容了，我只把前面的例子用SPL寫出來，簡(jiǎn)單感受一下。

一支股票最長(zhǎng)連續(xù)上漲多少天：

股票.sort（交易日）.group@o（收盤價(jià)《收盤價(jià)［-1］）.max（~.len（））

計(jì)算思路和前面的SQL是一樣的，但因?yàn)橐肓擞行蜻\(yùn)算后，表達(dá)起來要容易得多，不再繞了。

1億條數(shù)據(jù)中取前10名：

T.groups（;top（-10，x））

SPL有更豐富的集合數(shù)據(jù)類型，這條語句就表述了單次遍歷上實(shí)施簡(jiǎn)單聚合的高效算法，不必大排序。

高性能是大數(shù)據(jù)技術(shù)的永恒追求。在新代數(shù)支持下，我們能把數(shù)據(jù)庫計(jì)算的性能提高到什么程度呢？

幾個(gè)月前，我就去年做過一場(chǎng)性能測(cè)試寫過一篇文章《怎樣讓國(guó)產(chǎn)芯片性能超越Intel》：用SPL在低性能芯片上實(shí)現(xiàn)的高性能算法，能遠(yuǎn)遠(yuǎn)超越SQL在高性能芯片上寫出的低性能算法。這是數(shù)學(xué)的力量！

我們也敢于和傳統(tǒng)數(shù)據(jù)庫叫板，包括國(guó)際巨頭在內(nèi)，面對(duì)SQL寫出的慢代碼，改用SPL后平均能提速一個(gè)數(shù)量級(jí)。這是數(shù)學(xué)的底氣！

感謝數(shù)學(xué)

《感謝數(shù)學(xué)》是我在15年前紀(jì)念陳省身教授逝世時(shí)寫的文章，其中解釋了數(shù)學(xué)給我了什么，今年有機(jī)會(huì)應(yīng)同學(xué)之邀又做了一次題為“感謝數(shù)學(xué)”的講座，進(jìn)一步詮釋了數(shù)學(xué)對(duì)我的意義。這些內(nèi)容，同時(shí)也可以解釋我為什么可以做這個(gè)東西，或者應(yīng)當(dāng)問得更直白一些：我為什么敢做這個(gè)東西？

要撼動(dòng)有如此深厚巨大用戶基礎(chǔ)的關(guān)系數(shù)據(jù)庫，把用戶從多年的使用習(xí)慣中扳出來，當(dāng)真是談何容易。我知道有無數(shù)從業(yè)人員因?yàn)榧嫒菪远艞墑?chuàng)新，我自己也被無數(shù)次地好心勸過這路線太艱難。

“有數(shù)學(xué)，就有信心！”

數(shù)學(xué)給了我嚴(yán)格和抽象的思維。多一點(diǎn)嚴(yán)格認(rèn)真，就能發(fā)現(xiàn)更多別人看不到的盲點(diǎn)；多一點(diǎn)抽象能力，就能比別人看得更深更遠(yuǎn)。

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

在計(jì)算機(jī)的幫助下，人類第一次有了機(jī)械化處理大規(guī)模數(shù)據(jù)的能力。同時(shí)，也不可避免地遭遇許多以往不曾面對(duì)過的新問題。這些問題可能涉及到計(jì)算機(jī)的基礎(chǔ)理論，無法簡(jiǎn)單地使用工程方法去處理，而需要發(fā)展出新的數(shù)學(xué)體系，采用新的模型才能解決。

然而，與工程上取得的巨大成功相比，計(jì)算機(jī)科學(xué)在理論方面卻非常單薄，只能數(shù)出可計(jì)算性、關(guān)系代數(shù)等幾個(gè)為數(shù)不多的領(lǐng)域。計(jì)算機(jī)界使用的數(shù)學(xué)，大部分是幾十年甚至上百年前早就被數(shù)學(xué)家們發(fā)明過的。

三百年前剛發(fā)明微積分的年代，各種猜想定理層出不窮，數(shù)學(xué)家們時(shí)不時(shí)就能把名字寫進(jìn)我們的教科書，這些名垂青史的成果現(xiàn)在看來并不復(fù)雜（當(dāng)時(shí)提出來并不容易），普通理工科學(xué)生都能理解。這完全不同于當(dāng)代主流數(shù)學(xué)領(lǐng)域，不學(xué)二十年根本無法和人交流。

現(xiàn)在的計(jì)算機(jī)數(shù)學(xué)也正當(dāng)時(shí)，處于最容易出成果的時(shí)代。我也有信心，終有一天，離散數(shù)據(jù)集理論也會(huì)寫進(jìn)大學(xué)教科書！