性能躍升50%!解密自主研發的金融級分佈式關係數據庫OceanBase 2.0

小螞蟻說:

相信大家對螞蟻金服自主研發的金融級分佈式關係數據庫OceanBase的故事不再陌生了。在剛剛過去的2018年天貓雙11中,成交額2135億再次創造了新紀錄,而支撐今年雙11的支付寶核心鏈路就是OceanBase 2.0版本。

本文小螞蟻將爲大家詳述OceanBase如何在去年同樣機器數量的情況下,來支撐今年雙11的流量洪峯,一起來學習一下吧~


本文作者爲螞蟻金服OceanBase團隊資深技術專家顏然,他也是OceanBase初創成員之一,目前負責事務引擎以及性能優化方面的研發工作。


OceanBase:在普通硬件上提供極限性能的數據庫服務

1.png


OceanBase是完全自主研發的金融級分佈式關係數據庫,從架構上可以通過擴展機器來解決集羣服務能力的擴展需求。


OceanBase採用多副本複製的方案解決了可靠性和可用性的需求,而且構建在普通PC服務器上,不依賴於高端引擎。

 

我們的目標是在普通硬件上提供極限性能的數據庫服務。那麼,OceanBase的存儲引擎有什麼特點呢?


2.png


OceanBase的存儲引擎類似於LSMTree,所有新增的修改都會先記錄在Memtable中,這些數據的變更並不會實時寫到磁盤上,而會在後臺定期寫到硬盤上。


不管是磁盤還是SSD,當有大量寫入的時候,它的讀取性能都會受到很大影響。從一開始OceanBase的架構就是爲了適應這種硬件的特性,所以沒有隨機寫的操作,對於SSD和磁盤都很友好,可以將硬盤的吞吐量優勢發揮出來,把硬件資源最好的性能壓榨出來。


OceanBase從0.x版本到1.x版本,再到現在的2.0版本,一直在推動的一件事就是把硬件的性能做到極致,希望在同樣的硬件條件下能給業務帶來更多性能的空間。OceanBase的目標一直是有極致性能並且性價比最好的數據庫。


OceanBase的性能目標:極致壓榨硬件性能

從用戶使用角度來看,數據庫有兩個重要的指標,延遲(Latency)和吞吐量(Throughput)。這是兩個非常不一樣的指標。


3.png


根據排隊論模型,這兩者之間的關係如上圖所示:隨着吞吐量增加,延遲近似指數倍增長


當整體系統的性能不是特別高的時候,可以保持延遲的穩定性。當系統性能壓力很高的情況下,延遲會增加,我們要做的事情就是要在一個合理的延遲情況下,讓吞吐量可以儘可能大。換句話說,其實就是把一個請求要做的事情儘可能的減少,然後讓單位時間內能做的請求儘可能的多。性能優化的最終目標就是在延遲可以接受的場景下,儘可能提高系統的吞吐量。


性能優化工作

在剛剛過去的2018年天貓雙11中,成交額2135億再次創造了新紀錄。那麼在螞蟻金服/支付寶這樣的場景下,支付的壓力會全部落在OceanBase 2.0版本上。在2.0版本里我們做了一個很重要的事情來進一步壓榨硬件的性能——也就是在去年同樣機器數量的情況下,來支撐今年的流量洪峯。


在同樣的硬件環境,同樣的機器規模數這些條件下,通過升級的服務器版本以及服務器的部署方式,來提供今年雙11在0:00:00洪峯到來時的抗壓能力。 雙11的支付壓力是典型的OLTP模型,有大量的增刪改查操作。OceanBase的存儲模型決定了操作主要在內存中進行,所以在滿負荷運轉下CPU是主要瓶頸。


CPU的資源如何壓榨到極致,其實主要包含兩方面的工作:

  • 一是優化語句執行消耗指令數(Instructions /SQL),即每個請求需要執行的指令數,指令越少越好;

  • 二是優化系統執行指令的效率(Cycles /Instruction),可以用CPI(Cyclesper Instruction)表示。

 

系統性能由每一行代碼決定

任何一段代碼都可能導致bug,任何一行代碼也都有性能優化的空間。針對不同的場景,我們需要深入到每行代碼裏去看可以做什麼樣的優化。

4.png

OceanBase 2.0版本進行了深度的優化獲得了很好的性能提升。上圖所列的只是其中一部分優化工作。性能優化是一個事無鉅細的工作,有點類似於測試工作,本質上每一行代碼都會影響系統的性能。


優化CPU開銷

Commit異步化


5.png

在OceanBase已有的模型裏,網絡模塊有單獨的線程池負責和客戶端通信,接受用戶請求和返回請求結果。接收到的請求會發在任務隊列中由工作線程處理。


相比較於每一個用戶的連接使用一個獨立的線程服務的模型,OceanBase的模型可以大大減少上下文切換的次數。


對於SQL語句的執行,這已經是一個很好的模型了。但是對於事務的提交操作,需要將日誌在本地持久化和發送到其他副本持久化,提交操作又會使得工作線程出現等待的情況。


Commit異步化是在事務提交日誌後不再等待日誌持久化,工作線程可以直接去隊列中取下一個任務執行。等日誌持久化完成後,通過回調的方式出發事務提交完成的操作和給用戶發送請求的結果。


優化系統擴展性

擴展性問題

我們做了很多事情讓系統少做無謂的事情,多做有用的事情,也就是增加CPU做有效工作的時間佔比。


機器的CPU核數越來越多,從原來的幾十個核和現在的一百多個核,在英特爾的PC Server上都是很常見的場景。系統在服務器上運行,多核CPU的擴展性是一個很重要的方面。這裏以計數器場景舉例,單個線程和多個線程一起操作同一個計數器,後者因爲多個核之間競爭同一個內存單元,性能會下降幾百倍。其實有時候人多不一定力量大,人多也有可能導致大家一起搶賽道。

 

在系統中也大量存在類似的競爭場景,內存分配器是一個常見場景。多個線程在操作同一個memtable時,會從連續的內存塊中分配內存,分配內存的操作就好似計數器的競爭。所以,要把memtable的內存分配操作做成分區的形式,減少多個核之間的競爭。

6.png

說到底性能優化其實就是在優化系統的各個細節,每個細節都要做到極致,最終性能才能壓榨到最好的那個點,才能把硬件本身的性能發揮到最好。


性能無止境

7.png

我們可以看到,藍色塊代表的是OceanBase 1.4版本,也就是我們現在使用的主力版本,綠色塊代表了OceanBase 2.0版本。A場景是下單場景,也就是點提交訂單時的操作,B場景是支付場景,就是登到支付寶裏去最終付款的場景。


最後結果是:在下單場景下,OceanBase 2.0版本比1.4版本的性能提升了63%,在支付場景下,提升了58%。


OceanBase的未來

未來OceanBase會加強面向全棧的優化,同時會對工作負載進行優化,也會有面向新硬件方面的優化工作。


OceanBase會持續進行性能優化的工作,目的是持續爲用戶提供具有最高極限性能以及最好性價比的產品。這是OceanBase所一直秉承的理念。


發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章