陽振坤：當我們在談論金融級分散式資料庫的時候，其實是在說性能的代價

最新 03-29

在開始說正題之前，我想先說說激光照排、伺服器和操作系統。

我是1965年生人，在做分散式系統和資料庫的研發之前，跟著老師王選，做了十多年的激光照排，親身經歷了北大方正激光照排系統從無到有，從小到大的過程，也看到了王選老師的創新對媒體出版產業、對億萬大眾的信息消費產生了多麼巨大的影響。王選老師的一句話讓我銘記至今：「高科技產業應實現『頂天立地』模式。『頂天』就是不斷追求技術上的新突破；『立地』就是把技術商品化，並大量推廣應用。」這讓我清楚地知道，如果要做一個好的創新，不僅要技術上牛，更要真正應用到生產和生活的實際場景中去。就像CPU的國產自主研發，我們十幾年前就能做出來「狗剩」（Godson），如今更有寒武紀，但都還沒有機會得到大規模商用化，這是讓人扼腕嘆息的事情。

所以當我們2010年前後開始做分散式資料庫，也就是設計OceanBase架構的時候，一開始瞄準的目標，就是要把它做成一個通用的關係資料庫產品，而不是一個僅僅在公司內部使用的產品。2017年，讓我們團隊最高興的是，通過8年研發抗戰，我們不僅做到了承擔螞蟻金服「雙十一」全部核心業務的重壓，還在6家商業銀行落地，成為他們互聯網金融類新業務系統的數據核心。

站在這樣一個有紀念意義的時間點上顧盼今昔，我發現，雖然資料庫已是一個看起來不那麼性感的研發領域，但當我們看看，在企業級系統里，和資料庫分不開的伺服器和操作系統的演進後，就會知道，分散式資料庫引發的創新變革，尤其是金融服務領域的變革，或許才剛剛開始。

當年研究分散式系統的時候，對一篇2005年Google首席工程師Luiz André Barroso發表在美國計算機學會學報上的論文印象頗深，那篇文章就叫做《The Price of Performance》，所以我這篇文章的標題也是向他致敬。在該文里，Luiz的主要觀點就是表達了，Google作為當時全球最大規模計算基礎架構的技術平台，需要在設計基礎架構的時候，更好地平衡性能和價格，而他作為首席工程師，首先必須回答的問題就是：對於業務部門所需要的計算能力，在經濟上是否能夠承受？他開發出一套思路，能深入理解計算的總體成本，並且不斷地尋找合適的硬體/軟體設計來優化每個成本單位的性能。Luiz將Google計算基礎設施的TCO（總體擁有成本）分解為四個組件：硬體成本、能源消耗、數據中心的建設及運營成本，以及軟體成本。在雲還沒有誕生的年代，最昂貴的TCO組件是軟體，Luiz將TPC-C測試中使用的系統價格進行粗略分解後發現，平均到每個CPU，操作系統和資料庫引擎的成本約為4000～20000美元，如果再算上其他操作系統組件、應用和管理軟體的授權費用，成本還得增加許多。性能第二大的代價是能源消耗，根據Luiz測算，Google自行組裝的貼牌PC伺服器，TCO的40%來自電能消耗，即使他明明知道有70%以上的CPU時間是被浪費掉的。至於硬體採購成本和IDC的運營成本，相比前兩個單項，只佔到10%不到的比例，都可以忽略。

所以，當我們一開始想做OceanBase，這個從架構上就和Oracle、DB2完全不一樣的「分散式」資料庫的時候，首先想實現的也是幫助業務部門降低TCO，尤其是在更加便宜的分散式硬體+操作系統上，用最低的代價，實現最高級別金融級資料庫的性能和可用性。

這個想法在當時，被許多同行看成是異想天開，因為這和我們在大學裡學過的資料庫基本常識違背，分散式系統怎麼可能實現CAP的要求呢？而且那個時候，大多數金融機構，包括阿里自己用的都是IOE架構，雖然當時IOE架構的並發交易處理能力已經不能滿足「雙十一」的需求，但勝在穩健；雖然IOE架構臨時擴容收費的都是天文數字，但勝在阿里掙得更多，支付得起。所以我們要干這件事情，先不說成功的概率有多大，而是它重不重要，緊不緊急？

為了回答這些問題，我們不僅和業務部門做了兩周的緊急調研，確認了這件事情的重要性，也看到了一些行業的大趨勢——從2004年開始，全球每年約450-500億美元規模的伺服器市場，已經從x86+Windows/Linux與RISC&大型機+AIX/HP-UX/Solaris/Mainframe各佔一半銷售額，快速變換為2010年的x86佔據80%以上份額，出貨量更是相差兩個數量級；而早在2006年，就已經有建設銀行這樣的國有大銀行，已經在嘗試「總行用主機+省行用小機」的嘗試，而且表示不排斥在關鍵業務系統里用Linux，前提是得有成熟的、兼容性好的應用。作為互聯網公司，我們更不應該落後於傳統金融行業的老大哥。

所以，不管是內部要求，還是外部環境，在當時都發生了一些微妙的變化，這也給了我們一些信心，能夠做出一個先滿足內部業務需求，進而滿足金融行業需求的資料庫產品。

基於應用場景，挑戰不可能

光有信心沒用，還得擼起袖子加油干。正如李國傑院士所說：Database之所以難，不只是難在Data上，而是難在後面的Base上。OceanBase能做成金融級資料庫，主要是做了五個關鍵創新。

第一點，我們做到了CAP的最佳平衡。單機資料庫要做到既滿足事務ACID特性，又可擴展已經非常困難了，而OceanBase則是在做三個庫或者五個庫的時候，要多台機器同時來做，在具備高可用、高可擴展的同時，追求數據強一致，保證事務ACID，這個是OceanBase系統裡面最複雜的部分之一，也是今天其他人很難在這塊領域出彩的原因。

第二點，我們重新設計了數據存儲模式。資料庫有兩種性能，一種讀，一種寫，讀可以緩存而寫是無法緩存的，即使是固態硬碟，隨機寫的能力也是受到限制的。所以OceanBase在關係資料庫領域首創了把寫操作放到內存中，改幾個位元組就記錄幾個位元組，再把日誌放到硬碟上，如果出現類似電腦掉電重啟的情況，只需要回放日誌做恢復就可以了。因為日誌在硬碟上是順序寫入，所以性能不是問題。因為不需要在硬碟上隨機寫，用能夠隨機讀的廉價硬碟就可以，最終結果就是把性能提高一半以上，同時把成本又降一半。但有人會問，內存那麼貴，你用來做資料庫是不是太奢侈，還談什麼降低一半成本？的確，受制於內存成本和IDC機架的功耗限制，我們沒有把全部寫操作都放到內存里，而是採用內存與硬碟都用的折中方案，只把一些最常用的數據和最近的修改數據保存在內存裡面，這樣既維持了一個適當的成本，又得到一個很好的性能。

第三點，我們實現了變長數據塊存儲。傳統資料庫的塊是定長塊，塊的大小從幾個KB到十幾個KB不等，並且是原地修改，如果修改後的數據總長度超過塊大小，需要鏈接到新的塊，後續對該記錄的訪問就會跨塊，會有性能損失；如果一頁剩餘空間不足以存下一行，就只能空閑。而OceanBase的塊大小是2MB，在塊內，記錄是順序存放的，由於沒有原地更新，數據緊湊存放，空間利用率會更高。還有一點就是，資料庫其實也是CPU佔用率很高的應用系統，它的業務在高峰期的時候，CPU是沒有多少空閑的，所以只能用一些很簡單的壓縮演算法，而OceanBase因為第二點的優勢，白天不做大規模寫入，到夜裡再會把數據寫入硬碟，可以更加充分、均衡的利用CPU和硬碟，這樣做的效率比商業資料庫的資料庫效率要高一倍以上，而且是一次性寫入，出錯的幾率也會降低很多。

第四點，我們用校驗和的方式，做到了高一致性。螞蟻金服和銀行一樣，最關鍵的業務就是交易系統，也就是記賬和轉賬。作為記賬系統的核心基礎，OceanBase的賬本不能出錯。對此，我們做了個類似CRC的「校驗和」機制，每天晚上對每一條數據、每一台機器進行大合併，合併完了之後，檢查這個「校驗和「是不是一樣，如果不一樣肯定有問題了。我們對「事務」也加了這個校驗和，因為事務中包含的對數據表的修改也是一種數據，把這些數據每次都累計生成一個校驗和，在備機回放日誌的時候，一旦發現這個校驗和不對，我們的系統就會報警。在新版本的OceanBase里，校驗和做的更嚴格，會對每張表的每一行都做一個校驗，每一列也做一個校驗，整個表再做個校驗，一旦有任何一點的不一致，就會被發現，這樣的操作能讓業務部門充分放心。

第五點，我們做到了資料庫主庫故障後數據無損（RPO=0）。單機資料庫通常是一主一備，最大的問題就是沒有仲裁，資料庫主庫要是出問題了，伺服器產商和資料庫提供商會不惜代價救回主庫，實在救不回來了，銀行要開會決策用不用備庫，因為備庫數據是有損的，損失要由銀行自行承擔，所以銀行都有自己的人工對賬系統用來應對這種緊急情況。OceanBase採用了Paxos協議（一種分散式一致性協議），即使用了三個都有可能出錯的庫，但通過多數派贏的表決的方式，對外提供穩定可靠的服務，很好地兼顧了數據一致性與服務可用性。所以，當支付寶和首批六家合作銀行用了OceanBase之後，容災演習就不再需要人工對賬系統。

從支付寶到商業銀行，天時地利人和

金融級分散式資料庫能夠在行業生產場景中真正用起來，需要天時、地利和人和。

天時，就是隨著互聯網，尤其是移動互聯網的爆髮式增長，對金融行業的在線事務並發處理能力、數據處理能力和系統彈性提出了再上一個數量級的要求。舉個例子，網點最多的中國工商銀行號稱是「你身邊的銀行」,也不過幾萬個網點，每個網點一般10多個服務櫃檯，每天能服務的企業和個人客戶是相對有限的，所以在那個時代，大型主機足以滿足業務需求，一個分行的TPS、IOPS一般在幾百，峰值一兩千就夠了，數據量級一般在若干GB；但到了PC網銀時代，網路開戶、交易和轉賬的需求就多了一個數量級，這個時候就有一些省級分行或者城市商業銀行開始嘗試小型機+Unix的方案，資料庫的TPS、IOPS在三四千到一萬左右，數據量上升到TB級，系統整體成本就比用大型主機便宜很多了。到了2010年之後的移動互聯網大爆發時代，大型主機或小型機+Unix+傳統商業資料庫就都hold不住了——且不說能不能處理動輒百萬、千萬的並發請求，就算能完成，在傳統架構上獲得千萬級並發處理能力、PB級資料庫管理能力、一天之內系統擴容百倍並在業務高峰期後立即釋放，要獲得這樣的性能，又該付出怎樣的代價？放眼全球金融行業，我們還沒有看到任何一個這樣的先例。

地利，就是從淘寶到螞蟻金服的內部環境。資料庫跟手機不同，只要有一次死機就沒人用了，所以超高的要求和複雜的系統都是阻礙。而OceanBase從淘寶收藏夾到承載螞蟻金服100%業務的每一步進展，讓一個新產品，從不是特別重要的應用場景開始嘗試，一步步地將這個資料庫做成了關鍵系統。而且從互聯網公司做出來的產品，和傳統資料庫有一個特別大的有點就是性價比高，理由就是我們特別關注「性能的代價」，我們利用高性價比的PC伺服器和Linux，便可實現金融級業務需求。相對於一台幾十萬到幾百萬的小型機，甚至幾千萬、幾億的銀行總部用大型機，用5%的成本，做到了商業資料庫性能。

人和方面，就是人才和人心都正當時。人才正當時，是說能做分散式系統研發、運維和調優的人才已經遍地開花，不再是很高門檻的高精尖。正如開頭提到的，2005年玩好了分散式系統，有了自己的方法論和工程經驗，寫篇論文都是可以上ACM的；如今的互聯網公司里，還有核心業務不是分散式架構的嗎？那些勇於創新並嘗到甜頭的金融機構新業務部門裡，還有不是分散式架構的嗎？人心正當時，是說金融行業客戶的心理需求也產生了變化，比如南京銀行就是期望通過打造互金平台，將交易與消費和生活場景結合，提升用戶量和活躍度，更加普惠，更加服務民生，這跟螞蟻金服要做「助力普惠金融的科技公司「的願景是高度一致的，所謂「獨行快，眾行遠「，和價值觀相同的同事和客戶謀事，才更容易彼此成就，走得更遠。

變局：誰能真的千秋萬載，一統江湖？

在談論OceanBase未來的時候，我想先聊聊上面這三張圖。這是Gartner的魔力象限圖，對最近三年操作型資料庫管理系統的分析。有意思的是，2015年收錄了31家公司，其中一大堆領導者；第二年還有21個，基本上領導者就只剩下微軟SQL Server，Oracle，SAP，亞馬遜和IBM了，去掉了一半不贏利（死掉）的；到了2017年，只剩下11家，微軟和Oracle仍然穩如磐石，亞馬遜繼續上升，SAP落到第四，IBM與前三名差距拉大。因為推出了Spanner，谷歌從一招鮮玩家殺入到遠見者。因為不贏利，MongoDB居然都能被幹掉。從上面可以看到，在資料庫這樣一個非常成熟的細分領域裡，最近三年居然產生了如此劇烈的變化，這意味著什麼？會不會像當年分散式計算和虛擬化催生了雲計算一樣，資料庫領域也會產生類似的變化？這一現象背後的趨勢，值得我們深思。

特別想說說Spanner，谷歌認為Spanner是一個具備跨數據中心、跨全球事務處理能力的資料庫平台，但問題是Spanner不兼容ANSI/ISO SQL標準，導致兼容性和行業普及會成問題。其實心情很複雜，一方面，做了這麼多年分散式資料庫，好不容易找到一個有共鳴的Google，有他鄉遇知音的感覺。但或許是Google的業務部門過於強勢，資料庫的設計開發應用基本是為滿足自身需求，所以有上面的問題存在，如果Spanner商用前景不好，那也是很讓人痛心的。

整體來說，OceanBase走的是基於互聯網場景，加上金融交易資料庫類型，支持標準資料庫介面、標準資料庫語言的標準化研發道路，也通過這些年在容災、業務流程、零故障的表現，受到螞蟻金服內部和各大銀行的認可，我們還是有信心走得更快、更遠。

最後放兩張圖，與同事、同行、客戶共勉，但願若干年後，經過我們的共同努力，也能達到HPC領域裡聯想、曙光、浪潮、華為這樣的地位，成為資料庫領域裡的Top Tier！