淺談支撐起支付寶整個「11-11」的幕後功臣OceanBase數據庫

簡介

Tip:本文首發公衆號【一名打字員】

據悉，17年的4月份，螞蟻金服已經宣佈，螞蟻金服及阿里巴巴自研的關係型數據庫OceanBase已經支撐起Tmall和淘寶的平常業務需求，成功替換了以前所採用的單機數據庫如Oracle或者開源的MySQL。OceanBase做爲一個金融級應用，已經作到了能夠容納數百TB以及數千億條數據的跨表事物，其最大的亮點就是可擴展，將來極可能會成爲支持跨域多地的數據中心。

發展歷程

阿里巴巴首席DBA馮春培在一次大會中曾分享了阿里數據庫的演變歷程，其中大體分爲幾個階段：

• Oracle

04年之前，淘寶是使用的MySQL數據庫，衆所周知，5.6之前的PHP在數據庫方面有着極大的隱患，因此後來開始向ORACLE遷移。據馮春培介紹，04年阿里的數據庫常常出現問題，後來，業務超速發展，ORACLE的優化仍是承載不了業務的發展，這個時候阿里和淘寶進行了拆分。雖然ORACLE做爲一個優質的商業級DB來講，他提供了一個健碩的應用環境，可是也依然沒法擺脫上億級數據操做的困擾。固然我猜，成本上也是一個很大的方面，每一年投入的成本都在1千萬以上，另外因爲當時淘寶內部團隊大都很擅長商業DB，能很便捷的配合業務的擴展。

• MySQL

07年之後，阿里感覺到數據庫方面的貧瘠，開始選擇在開源數據庫上動手腳，這意味着須要放棄熟悉的，從新開始，並將固化思惟進行改變。這個時候的MySQL做爲開源領域的佼佼者，具備很強的開發易用性以及具備成熟的中間層，這樣極大程度的減小了開發難度，底層的數據存儲引擎也十分強大。並且，當時國內某銀行使用服務商提供的全套產品以後，沒法替換，因此阿里完全向MySQL進行遷移。在長達三年的遷移中，阿里一方面與ORACLE簽署了一份採購協議，使得ORACLE的受權能夠隨意使用，而後另外一方面，平穩的推動MySQL的發展，在當時，傳統的關係型數據庫在擴張方面是沒有一個好的解決方案的。

• NoSQL,OceanBase

10年，淘寶的大部分業務擴張很快，這些業務一般涉及到安全、交易以及數據的穩定性等問題，DB方面已經完成不了了，這個時候，淘寶開始從新架構本身的系統，聽說，在10年頭，阿里系裏出現了一系列優秀的架構師。並且市面上開始掛起大數據的熱風，不少人開始意識到數據的重要性。而大數據主要分爲存取數據，挖掘數據和運營數據，數據可普遍做用於各個領域。
這個時候比起昂貴的ORACLE和各類坑坑窪窪的MySQL來講，阿里開始拋棄開始汲取市場上僅有的非關係型數據庫和關係型數據庫的優勢，決定使用本身掌握的核心技術研發出一款本身的數據庫。OceanBase能夠自動擴展，具備強一致性，可以達到機房級的容災，最重要的一點，OceanBase可以達到真正的徹底不丟數據。

安利

以前也已經提到，MySQL、ORACLE與OceanBase的發展歷程，也簡單描述了相關的優缺點，在這裏也只簡單的安利一下OceanBase的特色，其中大部分思路源於@日照(OceanBase)的官方推文。
在這以前，不得不說說MySQL,當咱們切換到MySQL上時，一般會有下面幾個疑問：

1. MySQL的容災解決方案

2. MySQL的性能數據

3. MySQL自身穩定性如何

4. MySQL DDL解決方案

5. MySQL主備同步延遲以及數據一致性校驗

固然，在這裏我就不一一解答了，在互聯網上有一系列的解決方案，另外我會在後面的文章中陸續給出本身的見解以及相應的解決方案，有興趣的童鞋也能夠私下與我交流交流。
讀過《MySQL技術內幕：InnoDB存儲引擎》的童鞋都應該知道，MySQL被設計爲一個但進程多線程架構的數據庫，與SQL Server相似，與Oracle的多進程架構有所不一樣。大名鼎鼎的InnoDB被ORACLE收購，應用十分普遍，其體系結構主要分爲後臺線程和內存。後臺線程主要做用是負責刷新內存池中的數據，保證緩衝池中的內存緩存的是最近的數據，這時將已修改的數據文件刷新到磁盤文件，同時中途若是出現異常還要能恢復到正常狀態。
MySQL後面咱們會詳細介紹，畢竟也是開源圈內的一杆大旗，說回來咱們的OceanBase，從13年的設計到後面15年的崛起，從官方推文來講，OceanBase達到了分佈式數據庫基本的幾個核心部分，一個是查詢，一個是存儲還有一個就是事務。

• 事務處理

首先咱們得理清數據分佈狀況，傳統的關係型數據庫都有一種叫作兩級分區表的概念，就是：時間+業務主鍵。常見的分佈式系統中，分區要不就是用哈希或者是範圍。OceanBase可以將不一樣的分區分佈到不一樣的數據庫。這是當下傳統關係數據庫所沒法完成的。
OceanBase是如何達到多機的事務呢，這又得分爲單分區和多分去的操做。由於操做單個分區就是在一臺機器上，也就是使用的一臺機器的服務，本質就是一個單機事務。和其餘傳統數據庫的原理差很少，基於導個版本進行併發控制，不一樣的是，OceanBase作了一些優化例如日誌同步以及加入了內存數據庫的無鎖結構、內存多版本併發控制、SQL編譯執行等等。
多個分區則分爲兩種狀況，單服務器和多服務器。因爲多個服務器確定會跨多個觀察者，因此OceanBase也對此進行了一系列的優化，並且裏面的裏面高可用是基於Paxos協議實現的，OceanBase的開發者和Google Chubby系統的發明者也一致認同「Paxos協議實現的高可用機制都是耍流氓」的話語。

• 分佈式查詢

OceanBase裏有一個ObProxy的代理服務器，功能則就是一個透明轉發代理，能夠解析SQL，可以識別操做對應的哪個分區，而後將其轉發過去，聽說他的性能是可以達到百萬級的QPS。內部人員對它的評價就是：
輕量級SQL Parser
高性能異步框架
支持線程本地化
另外。在運維方面，它支持熱升級、全鏈路監控。說到熱升級，主要是新老版本發出不一樣的請求，對應到相應的新老版本提供服務，一段時間後將自動退出。
OceanBase的執行計劃主要分爲本地計劃、遠程計劃和分佈式計劃。這樣一個SQL請求到了Observer的服務端，通過一系列的解析、重寫和優化過程，再由SQL執行器負責執行。

• 其它

其它OceanBase還有不少很好的優勢，雖然它年齡還小，各方面還很稚嫩，好比說他的強一致性和它的高可用的優化，以及等等等等。。
更多的優勢能夠移步官方推文

思考

聽說OceanBase也曾經開源過0.4的版本，可是目前的版本已經和開源中的架構風馬牛不相及，也意味着OceanBase確定是遇到了許多坎坷，可是最終仍是遇到了本身的伯樂。雖然許多關鍵性的指標OceanBase尚未達到，也沒有辦法在處理互聯網實時大數據量的處理進行高度的契合，生態圈也不夠完善，可是一切都在起步，就和咱們每個打字員同樣，都在成長的路上，We always on the road。