陽振坤：資料庫天然選擇了計算機，但計算機天然並不適合資料庫

本文整理自演講內容：

在網際網路世界裡，存在著一種怪圈：本地企業為了向本地人群推銷本地產品，卻每天都在源源不斷地把廣告費輸送給境外公司。在美國，有這麼幾家巨無霸公司，諸如Google、Amazon、Facebook等，已經逐漸壟斷了歐洲和日本的網際網路應用相關市場。

而反觀中國，我們有自己的電商網站（淘寶天貓等），自己的搜尋引擎和社交應用（微信，微博等）。我們是否可以自信的說，我們真的達到了國際一流的技術水平？從網際網路應用的角度來看，中國製造的應用在形態上不斷演變，不斷豐富，我們承認自己確實已經做得比較優秀。但是，在核心基礎部件上，我們還有很長的路要走。

今天，從大範圍普遍使用的角度來看，中國還不能說真正有自己的處理器，不能說真正有自己的作業系統，也不能說真正有自己的關聯式資料庫。或許有人會說，今天的開源生態日益繁榮，我們完全可以用開源的作業系統，開源的資料庫。

給大家提供這樣一份資料：在手機市場上，中國每一部安卓手機不僅要給國外某作業系統軟體公司繳納幾美元到十幾美元的專利費，還要給國外某通訊巨頭繳納手機價格百分之幾的通訊及晶片的專利費。

而在金融行業，幾乎所有銀行的關鍵軟體硬體基礎設施都來自美國，伺服器是IBM的，共享儲存是EMC的，資料庫軟體大部分是Oracle，剩下的少部分是IBM的DB2。我們假設，如果某一天真的發生軍事衝突，銀行系統三年得不到技術支援和裝置配件，我們的金融業會怎樣？

努力了這麼多年，在關鍵基礎的軟體硬體設施方面，我們還是把自己的命脈和財富都交給了別人。

為什麼要做中國自己的關聯式資料庫？

這既是網際網路推動的客觀需求，也是金融行業數字化轉型的必然結果。

網際網路時代的全新挑戰

在沒有網際網路的時代，不論是商場還是銀行，關聯式資料庫系統的併發量非常有限，從幾十、幾百相當普遍，幾千、幾萬以上就比較少見了。進入網際網路時代以後，併發訪問量發生了數量級的增長。2010年的雙十一，高峰期間阿里巴巴的天貓的併發訪問量已經達到幾十萬，再到去年2017年的雙十一，這個併發訪問量已經達到一千多萬。這已經是一個從量變到質變的過程。

可以說天貓雙十一所帶來的現象級的併發訪問量是源，推動了整個團隊來做這件事。
那麼另外一個重要的因素，就是在傳統模式下，不管是商場還是銀行，它的訪問量很穩定，商場/銀行擴建時有充分的時間把整個IT資料庫系統擴充套件開來。而現如今，我們的網站可能上個星期訪問量還是十萬級別的，幾天時間就可能上漲了近十倍，傳統關聯式資料庫系統硬體的半年左右的購買實施週期無法適應業務的變化。

這就是網際網路時代資料庫所呈現的兩種特性，第一是併發量非常大，隨之所帶來的也是幾百上千倍的成本。第二就是負載變化劇烈，帶來伸縮性的變化。

大家都知道，2017年天貓雙11創造了新的支付記錄：25.6萬筆/秒，那麼這究竟是個怎樣的概念？

簡單解釋來看，就是為了要達到25.6萬筆的支付，資料庫需要執行4200多萬條SQL。用一個更直觀的例子，中國的五大行是中農工建交，他們每秒鐘的支付能力可能就是一萬多筆的體量甚至還不到。

這也就是說，如果支付寶採用同樣的解決方案，則需要付出大銀行十幾倍幾十倍的IT系統成本。

迴歸關聯式資料庫的本質：事務

資料庫之所以有價值，是因為事務。它之所以困難，也是因為事務。用華東師範大學的副校長周傲英教授的一句話來概括，資料庫的本質就是做三件事：轉賬、記賬、訂票。

生活在今天的現實世界中，沒有任何地方能離得開關聯式資料庫。打電話的時候，關聯式資料庫在幫你計費；買火車票，買飛機票，銀行存取款，還有各種各樣的網站交易等等，在這背後其實都是關聯式資料庫在支撐。所以，毫不誇張的說，關聯式資料庫是今天整個資訊社會中最關鍵，最無可替代的基礎設施。

但是，資料庫卻是個不好搞的東西。如果說資料庫中最關鍵的是事務，其最重要的就是事務的ACID特性。

• 原子性（A）：一個事務要麼全部執行，要麼不執行。比如你從取款機取錢，這個事務可以分成兩個步驟：改賬戶餘額，出錢。不能餘額減了，而錢沒出來。這兩步必須同時完成，要麼就不完成。
• 一致性（C）：在金融系統中，一個典型的場景就是信用卡主副卡。比方說，你和你的家人使用了主副卡，你花了一筆錢，你們的信用額度都會相應減少，如果你的家人還了一筆款，你們的信用額度都會相應增加。如果是在一臺機器上實現起來還沒那麼難，那麼如果在兩臺不同的機器上，這件事情就會變得非常困難。
• 隔離性（I）：事務在執行的過程中，表現地像是系統中當前唯一執行的事務，不會因為系統中併發執行的另一個事務而訪問到不一致的資料。
• 永續性（D）：今天唯一能夠有永續性的東西，其實就是硬碟。資料中心硬碟的年故障率約為2%-4%，所以說如果你的硬碟都壞了，你的資料還會存在嗎？

用一句話來總結來說就是：

資料庫天然選擇了計算機，但計算機天然並不適合資料庫。

資料一條不能錯，服務一秒不能停

關聯式資料庫在業務系統中處在一個最底層的位置。關聯式資料庫之所以困難，也是因為一個非常簡單的道理：資料不能錯，服務不能停。在任何業務系統中，資料庫的資料錯誤都是巨大的災難，對於金融業務，如果你的系統停止服務超過30分鐘，你恐怕需要去銀監會說明情況。

因為有這兩個因素，更換資料庫的風險非常高，但通常卻沒有與之匹配的收益。這也是為什麼像IBM、微軟這樣的後來者也無法取代Oracle。這就導致了資料庫變成了一個門檻極高，強者恆強的領域，後來者很難居上。

OceanBase：關聯式資料庫的重塑者

傳統資料庫的侷限

上圖是一個非常簡單的傳統資料庫的架構示意圖。今天IOE的體系在銀行業已經根深蒂固。雖然IBM的伺服器和EMC的儲存目前已經有一部分國內廠商可以替代，但是Oracle的江湖老大地位卻無人撼動。

即使把一個資料庫的裝置做到最貴最好，單個裝置出故障的情況還是存在，比如停電。所以資料庫的系統一定需要一個備庫，而與此同時引發的另外一個問題就是主備同步。

但是傳統關聯式資料庫在理論上卻根本做不到主備同步。如果你一定要做到同步，那麼就意味著每一筆事務都得從主庫同步到備庫，備庫確認後才能應答客戶。假如這中間網路出現問題，或者備庫存在問題，所有的同步都會被堵塞，也就是所有的寫操作都無法進行。

對於銀行和企業來說，這是一個生死兩難的問題，要保證同步，就面臨著業務不可用的風險。所以銀行購買可靠性更高的儲存和伺服器等硬體。最好的硬體可靠性自然高，可是價錢也非常高昂。

傳統關聯式資料庫的另外一個侷限就是分散式資料庫的缺失。分散式事務兩階段提交模型看起來相當美好，但是實際上一旦節點在第二階段出現故障，則事務既無法提交也無法回滾，只能被掛起，在實際生產系統中，這會導致資料庫的連線迅速被耗盡，從而使得服務中斷。

分散式資料庫的缺失導致傳統關聯式資料庫無法進行水平擴充套件，而只能採取垂直方式進行擴充套件，這不僅進一步增加了成本，也限制了業務的發展。無論是主庫備庫不一致，還是分散式資料庫的缺失，根本的原因是傳統關聯式資料庫自身高可用的缺失，即今天的傳統關聯式資料庫都是通過外部硬體來保證可用性，而沒有從資料庫系統內部來解決問題。

OceanBase的目標：十倍價效比，做到別人做不到的事

關聯式資料庫的市場是如此之特殊，OceanBase想要生存和發展，就必須在一些點上做到極致。而OceanBase給自己定的目標就是：把價效比做到傳統資料庫的十倍，並且做到別人做不到的事。

從八年前立項至今，OceanBase一直在腳踏實地的做三件事。
1）第一件事情是保證高可用的同時解決資料一致性問題。OceanBase通過把可用性做到資料庫系統內部來解決這個問題。

前面我們分析過，高可用與主備庫資料一致的矛盾，這是一個無法改變的客觀規律。那麼，OceanBase是如何做到的？OceanBase資料庫高可用的關鍵在於：用一主兩備或一主多備代替一主一備。主庫到備庫同步的時候也不要求同步到每個備庫，而是同步到包括主庫在內的多數庫（超過半數），也就是說總共三個庫中如果有兩個成功了，這個事務就成功了。所以說，任何一臺機器出了問題，這個系統的可用性和資料一致性都是保證的。

以三個庫為例，如果壞了一臺機器，每一筆事務至少會在剩下兩臺中的一臺上出現，所以整個系統能夠很快的恢復起來，繼續提供服務。這樣既保證了資料一致性，又保證了整個系統的可行性。

如果萬一壞了兩臺怎麼辦？雖然同時壞兩臺機器的概率極其低，但是在實際生產中還是可能出現的。所以，在重要的生產系統中，OceanBase用的不是三個庫，而是五個庫。這也就意味著，即使壞了一臺機器，哪怕人為因素導致再殺掉一臺，這個系統仍然能夠正常工作。

高可用和資料的一致性，OceanBase讓兩者都得到了保證。這也就是我們說的，做別人做不到的事。OceanBase可以跟銀行保證：少量伺服器甚至機房故障不會丟失任何一筆資料，也不會停止服務，甚至人工對賬的手段也不再需要。這也是今天銀行業非常歡迎我們的原因之一。

2）第二件事是提升效能，OceanBase通過原生的讀寫分離，使得整個系統效能，特別是寫的效能得到了很大的提升，同時將成本大幅度降低。

OceanBase將新寫入的資料放在記憶體，使得整個寫事務（除了日誌）不需要隨機寫盤。這對效能來說有了質的提升。

但是原生的讀寫分離，其實是有成本的。一個成本就是需要把新的修改放到記憶體之中，記憶體容量是有限的，不可能無窮無盡地寫下去。所以每隔一段時間一定要把這個內容融合到磁碟中去。

雖然本質上還是需要把資料寫到磁碟裡，但是帶來的好處是顯著的。通過原生的讀寫分離可以完美錯開業務的高峰期。把業務高峰期要做的事情（寫盤）先放在記憶體之中，那麼等過了高峰期，在平峰期和低谷期時，再把資料寫到硬碟裡去，相當於把CPU、硬碟IO錯開利用。

3）第三件事就是我們真的把OceanBase做成了一套分散式資料庫。

有人會說這個看起來很簡單，不就是把在一臺機器上做的事在幾臺機器上執行嗎？OceanBase幾十個人的團隊花了整整五年，做了三個大的版本，才把分散式事務做到了如今比較完善的地步。

分散式的意義究竟何在呢？雙十一一年就一次，對於業務量穩定的銀行和企業而言，有人覺得這個不是必要的需求。但現如今，移動支付已經融入到了每個人的生活。一個非常普遍的業務高峰期就真實發生在每個工作日的中午，上班族們拿著手機支付餐費，隨著手機支付的進一步普及，這個常態的支付峰值會越來越高。

未來已來，砥礪前行

OceanBase Milestone

2010年6月，OceanBase正式立項；2011年，淘寶收藏夾上線；2014年，支付寶交易系統上線；2016年，支付寶賬務系統上線；2017年，OceanBase開始商業銀行推廣，至今已在多家商業銀行上線執行。

OceanBase至今已成功應用於支付寶全部核心業務：交易、支付、會員和賬務等系統，網商銀行和印度PayTM以及阿里巴巴淘寶收藏夾、P4P廣告報表等業務。從2017年開始，OceanBase開始服務外部客戶，包括南京銀行、浙商銀行、人保健康險平臺等。

下一步方向

OceanBase 2.0即將在這個夏天釋出，這是OceanBase真正把分散式事務做的比較完善的一個版本。2.0版本中同時會在事務優化、SQL優化器上做更多提升。
同時，後續我們希望通過人工智慧/機器學習來協助使用者更好的使用資料庫，包括二級索引，SQL效能優化，故障診斷等等。我們也使用包括RDMA在內的新技術，以便進一步提升系統的效能，降低總體的成本。

更多精彩內容歡迎關注“OceanBase”公眾號，回覆關鍵詞“交流群”，即可加入螞蟻金服技術交流群，快來和陽老師一起探討技術吧！