從淘汰Oracle資料庫的事情說起

發表於2016-08-22

公司搞淘汰Oracle資料庫的事情已經搞了好久了,這個事情其實和國內淘寶系搞的去IOE(IBM、Oracle和EMC)是類似的,基本上也是迫不得已,Oracle的維護成本太高,而公司內部基於Oracle資料庫的資料倉儲,也是問題頻出;另一個原因則是scalability。我相信這兩個原因許多人都非常清楚。而這個淘汰,也不是簡簡單單換一個關聯式資料庫,比如把Oracle換成MySQL,或者換到雲上(RDS)。而是有明確階段性地演進,比如替換到DynamoDB這樣的NoSQL資料庫上面去;或者更徹底地,像我們接觸到的某個產品,資料本身換到更廉價的儲存S3上去,後設資料才存在DynamoDB裡,而原本SQL執行的運算的部分用Hadoop或者Spark來完成,這件資料來源統一和演進的事情由一個做infrastructure的團隊來完成。

Oracle資料庫要淘汰,而且還看到了NoSQL資料庫作為其中的一個替代方案,那是不是說SQL要慢慢淡出歷史舞臺了?

不!

因此不僅回答是“不”,還要補充一句——“恰恰相反”,和關聯式資料庫本身不同,SQL不但不會淡出,還要扮演更重要的角色。SQL和程式語言一樣,代表的其實是認識世界和描述世界的一種思維方式。比如下面這樣的兩個例子。

第一個,我們組日常都會接觸的產品,計算成本和利潤的邏輯,使用Scala寫的,跑在Spark上面,而隨著業務邏輯愈來愈複雜,許多Data Analyst介入來處理各種各樣的問題,他們相較於工程師來說,程式碼的能力顯然不是長處。但是他們對SQL很熟悉,對資料很敏感,把資料抽象成一系列二維表簡直是手到擒來。所以我們開始嘗試把那些核心運算邏輯重寫成Spark SQL。

第二個,前面提到的那個infrastructure團隊,對客戶要提供一層JDBC的封裝,讓內部的技術能力,也通過SQL的形式暴露出來。因為有了類似Hive這樣的工具,在這種情況下應用層的部分可以儘可能地保持穩定,原本的Oracle下的sql有改動和轉換,但依然是SQL,只不過執行的不再是資料庫引擎,而是MapReduce任務了。我覺得這件事情很有意思,也很有挑戰性。困難很多,比如索引的問題,運算透明性(包括除錯)的問題(SQL有執行計劃之類的工具可以讓我們對其執行機制瞭解清楚,但是換成MapReduce job以後顯然問題就困難得多了)等等。但是帶來的收益是顯而易見的,比如說,整個運算資源是彈性的——重要的急迫的任務優先順序高,分配資源多,參與運算的instance多,從而縮短得出結果的時間。

去Oracle是否意味著關係型資料庫不成功?

當然不是——

關係型資料庫不但在過去的幾十年內很成功,而且成功到被亂用濫用了。馮大輝以前說過一個被濫用的例子,阿里旺旺在使用者量那麼高的情況下,居然還用Oracle資料庫在做儲存。而我身邊也有這樣的例子,在我換組前,我原來的組,就把持著整個Amazon內部最大的Oracle資料庫,一大堆分割槽,動不動成天幾千萬行的資料讀寫。其實不但是資料庫這一層跟不上節奏了,還有工作流引擎也是,老的工作流引擎要淘汰,老團隊不維護了,但是因為當時我們組在這個老東西上面的job太多,沒法切換,成為釘子戶,被迫攬下了維護這個老工作流引擎的任務,直到它退休,成為全公司唯一使用它,並且是這一方面淘汰老技術最慢的……

其實整體看來,Amazon這樣的網際網路公司淘汰老舊的技術的速度已經算很快了(尤其是和傳統軟體公司比起來),有時候會遇到引進新技術和造輪子過度的問題(比如好多組都有自己搞的一套聽起來高大上的資料儲存系統,還有就是工作流系統,也是遍地開花),但是總的思路還是挺激進的:隨時準備拆了輪子重造。問題小就解決,問題大就重寫。且不說這做法利弊各佔多少,每次搞宣傳招人的時候,造新輪子和大輪子這一點,確實是吸引人啊。

再一個例子,記得剛工作那會兒,去北京聯通開局,負載分擔是F5,伺服器掛在單板上,儲存用的是磁碟陣列,資料庫雙機用的是IBM小型機(和美國車一樣,“保修期”內屁事兒沒有,“保修期”一過就開始噼裡啪啦亂出問題,然後賺修車費)。在當時這幾個玩意兒聽聽就是不差錢的主兒才能購置裝配的東西,看看網際網路公司誰敢這麼搞?無論是雲端儲存還是雲端計算,用的都是成本很低的硬體,有的功能直接替代由軟體完成,但是這恰恰解釋了和關係型資料庫的發展到輝煌,再到演退相同的現象,這些硬體也是在一定時期內代表了特定的技術流行,如今也慢慢被單裝置成本低,但是規模更大的叢集代替。

好,從這個問題繼續展開,再談談“人”和“技能”。

羅胖(羅振宇)的羅輯思維裡面,講到了社會化分工帶來的社會進步,也講到了手工藝人。簡單勞動,甚至不簡單,但是容易被模擬的勞動,還是不可逆轉地慢慢地被機器和軟體所替代。於是一大幫程式設計師都在喊技術至上,要做技術,這也是手工藝人謀生的基礎。但是同樣是技術,可不盡相同,有的也有逐漸被淘汰的趨勢,比如說:

Java總是在風口浪尖說要被淘汰,而我們也看到隨著各路程式語言大張旗鼓地發展繁榮,飽受詬病的Java佔有率確實下降了。但是JVM呢,卻欣欣向榮,其原因在於,JVM是個平臺,而Java只是一門程式語言。程式語言的可替代性在於,隨著機器效能的提升,開發一門更現代更符合問題解決思維的語言的成本,要比做成一個更現代化的穩定的虛擬機器平臺,要低得多。這也是為什麼流行的JVM上的語言有那麼多,作者往往是個人;但是熟知的JVM就只來自那麼幾家公司。再有一個,則是程式語言本身的缺陷,更難以被“繞過”。

再比如說,一些曾經熱炒的職位,比如DBA,對於很多人來說,這樣的職業已經很難再風光下去。單純靠維護賺錢,這本來就是一件無法長久的生計。因為“維護”這一件事情,要麼因為簡單而能被機器和軟體替代掉,要麼因為複雜而被革命掉。工具,永遠只是媒介,是可以被繞過的,不是最根本和最核心的問題。資料庫和很多其他的技術一樣,從軟體和工程的最本源獨立出來,壯大到現在,慢慢再回歸本源。再比如,以往小公司都要招折騰硬體的工程師,剛工作的時候和很多同事一樣,都折騰過單板和機架,但是現在呢,可以把儲存資源和計算資源掛到雲上。因此這樣的人才需求會慢慢減少,而門檻卻不見得降低,最終就只剩下少數幾家能夠提供雲服務的大戶。

因此,以後再遇到那些賣弄自己技術的人,那些虛張聲勢的人,我們其實可以思考一下,生成自己的判斷,他所顯擺的技術,到底是解決核心問題的技術,不容易被革命和替代的,還是隻是另一種魯迅筆下迂腐而無聊的“‘茴’字的三種寫法”呢?

相關文章