摘要：簡介本文首發(fā)公眾號一名打字員據(jù)悉，年的月份，螞蟻金服已經(jīng)宣布，螞蟻金服及阿里巴巴自研的關(guān)系型數(shù)據(jù)庫已經(jīng)支撐起和淘寶的日常業(yè)務(wù)需求，成功替換了之前所采用的單機數(shù)據(jù)庫如或者開源的。

Tip:本文首發(fā)公眾號【一名打字員】

據(jù)悉，17年的4月份，螞蟻金服已經(jīng)宣布，螞蟻金服及阿里巴巴自研的關(guān)系型數(shù)據(jù)庫OceanBase已經(jīng)支撐起Tmall和淘寶的日常業(yè)務(wù)需求，成功替換了之前所采用的單機數(shù)據(jù)庫如Oracle或者開源的MySQL。OceanBase作為一個金融級應(yīng)用，已經(jīng)做到了可以容納數(shù)百TB以及數(shù)千億條數(shù)據(jù)的跨表事物，其最大的亮點就是可擴展，未來很可能會成為支持跨域多地的數(shù)據(jù)中心。

阿里巴巴首席DBA馮春培在一次大會中曾分享了阿里數(shù)據(jù)庫的演變歷程，其中大致分為幾個階段：

Oracle

04年以前，淘寶是使用的MySQL數(shù)據(jù)庫，眾所周知，5.6以前的PHP在數(shù)據(jù)庫方面有著極大的隱患，所以后來開始向ORACLE遷移。據(jù)馮春培介紹，04年阿里的數(shù)據(jù)庫經(jīng)常出現(xiàn)問題，后來，業(yè)務(wù)超速發(fā)展，ORACLE的優(yōu)化還是承載不了業(yè)務(wù)的發(fā)展，這個時候阿里和淘寶進行了拆分。雖然ORACLE作為一個優(yōu)質(zhì)的商業(yè)級DB來說，他提供了一個健碩的應(yīng)用環(huán)境，但是也依然無法擺脫上億級數(shù)據(jù)操作的困擾。當然我猜，成本上也是一個很大的方面，每年投入的成本都在1千萬以上，另外由于當時淘寶內(nèi)部團隊大都很擅長商業(yè)DB，能很便捷的配合業(yè)務(wù)的擴展。

MySQL

07年以后，阿里感受到數(shù)據(jù)庫方面的貧瘠，開始選擇在開源數(shù)據(jù)庫上動手腳，這意味著需要放棄熟悉的，重新開始，并將固化思維進行改變。這個時候的MySQL作為開源領(lǐng)域的佼佼者，具有很強的開發(fā)易用性以及具有成熟的中間層，這樣極大程度的減少了開發(fā)難度，底層的數(shù)據(jù)存儲引擎也十分強大。而且，當時國內(nèi)某銀行使用服務(wù)商提供的全套產(chǎn)品之后，無法替換，所以阿里徹底向MySQL進行遷移。在長達三年的遷移中，阿里一方面與ORACLE簽署了一份采購協(xié)議，使得ORACLE的授權(quán)可以隨意使用，然后另一方面，平穩(wěn)的推進MySQL的發(fā)展，在當時，傳統(tǒng)的關(guān)系型數(shù)據(jù)庫在擴張方面是沒有一個好的解決方案的。

NoSQL,OceanBase

10年，淘寶的大部分業(yè)務(wù)擴張很快，這些業(yè)務(wù)通常涉及到安全、交易以及數(shù)據(jù)的穩(wěn)定性等問題，DB方面已經(jīng)完成不了了，這個時候，淘寶開始重新架構(gòu)自己的系統(tǒng)，據(jù)說，在10年頭，阿里系里出現(xiàn)了一系列優(yōu)秀的架構(gòu)師。而且市面上開始掛起大數(shù)據(jù)的熱風，很多人開始意識到數(shù)據(jù)的重要性。而大數(shù)據(jù)主要分為存取數(shù)據(jù)，挖掘數(shù)據(jù)和運營數(shù)據(jù)，數(shù)據(jù)可廣泛作用于各個領(lǐng)域。
這個時候比起昂貴的ORACLE和各種坑坑洼洼的MySQL來說，阿里開始拋棄開始汲取市場上僅有的非關(guān)系型數(shù)據(jù)庫和關(guān)系型數(shù)據(jù)庫的優(yōu)點，決定使用自己掌握的核心技術(shù)研發(fā)出一款自己的數(shù)據(jù)庫。OceanBase可以自動擴展，具有強一致性，能夠達到機房級的容災(zāi)，最重要的一點，OceanBase能夠達到真正的完全不丟數(shù)據(jù)。

之前也已經(jīng)提到，MySQL、ORACLE與OceanBase的發(fā)展歷程，也簡單描述了相關(guān)的優(yōu)缺點，在這里也只簡單的安利一下OceanBase的特點，其中大部分思路源于@日照(OceanBase)的官方推文。
在這之前，不得不說說MySQL,當我們切換到MySQL上時，通常會有下面幾個疑問：

MySQL的容災(zāi)解決方案

MySQL的性能數(shù)據(jù)

MySQL自身穩(wěn)定性如何

MySQL DDL解決方案

MySQL主備同步延遲以及數(shù)據(jù)一致性校驗

當然，在這里我就不一一解答了，在互聯(lián)網(wǎng)上有一系列的解決方案，另外我會在后面的文章中陸續(xù)給出自己的看法以及相應(yīng)的解決方案，有興趣的童鞋也可以私下與我交流交流。
讀過《MySQL技術(shù)內(nèi)幕：InnoDB存儲引擎》的童鞋都應(yīng)該知道，MySQL被設(shè)計為一個但進程多線程架構(gòu)的數(shù)據(jù)庫，與SQL Server類似，與Oracle的多進程架構(gòu)有所不同。大名鼎鼎的InnoDB被ORACLE收購，應(yīng)用十分廣泛，其體系結(jié)構(gòu)主要分為后臺線程和內(nèi)存。后臺線程主要作用是負責刷新內(nèi)存池中的數(shù)據(jù)，保證緩沖池中的內(nèi)存緩存的是最近的數(shù)據(jù)，這時將已修改的數(shù)據(jù)文件刷新到磁盤文件，同時中途如果出現(xiàn)異常還要能恢復(fù)到正常狀態(tài)。
MySQL后面我們會詳細介紹，畢竟也是開源圈內(nèi)的一桿大旗，說回來我們的OceanBase，從13年的設(shè)計到后面15年的崛起，從官方推文來說，OceanBase達到了分布式數(shù)據(jù)庫基本的幾個核心部分，一個是查詢，一個是存儲還有一個就是事務(wù)。

事務(wù)處理

首先我們得理清數(shù)據(jù)分布情況，傳統(tǒng)的關(guān)系型數(shù)據(jù)庫都有一種叫做兩級分區(qū)表的概念，就是：時間+業(yè)務(wù)主鍵。常見的分布式系統(tǒng)中，分區(qū)要不就是用哈?；蛘呤欠秶?。OceanBase能夠?qū)⒉煌姆謪^(qū)分布到不同的數(shù)據(jù)庫。這是當下傳統(tǒng)關(guān)系數(shù)據(jù)庫所無法完成的。
OceanBase是如何達到多機的事務(wù)呢，這又得分為單分區(qū)和多分去的操作。因為操作單個分區(qū)就是在一臺機器上，也就是使用的一臺機器的服務(wù)，本質(zhì)就是一個單機事務(wù)。和其他傳統(tǒng)數(shù)據(jù)庫的原理差不多，基于導(dǎo)個版本進行并發(fā)控制，不同的是，OceanBase做了一些優(yōu)化例如日志同步以及加入了內(nèi)存數(shù)據(jù)庫的無鎖結(jié)構(gòu)、內(nèi)存多版本并發(fā)控制、SQL編譯執(zhí)行等等。
多個分區(qū)則分為兩種情況，單服務(wù)器和多服務(wù)器。由于多個服務(wù)器肯定會跨多個觀察者，所以O(shè)ceanBase也對此進行了一系列的優(yōu)化，而且里面的里面高可用是基于Paxos協(xié)議實現(xiàn)的，OceanBase的開發(fā)者和Google Chubby系統(tǒng)的發(fā)明者也一致認同“Paxos協(xié)議實現(xiàn)的高可用機制都是耍流氓”的話語。

分布式查詢

OceanBase里有一個ObProxy的代理服務(wù)器，功能則就是一個透明轉(zhuǎn)發(fā)代理，可以解析SQL，能夠識別操作對應(yīng)的哪一個分區(qū)，然后將其轉(zhuǎn)發(fā)過去，據(jù)說他的性能是能夠達到百萬級的QPS。內(nèi)部人員對它的評價就是：
輕量級SQL Parser
高性能異步框架
支持線程本地化
另外。在運維方面，它支持熱升級、全鏈路監(jiān)控。說到熱升級，主要是新老版本發(fā)出不同的請求，對應(yīng)到相應(yīng)的新老版本提供服務(wù)，一段時間后將自動退出。
OceanBase的執(zhí)行計劃主要分為本地計劃、遠程計劃和分布式計劃。這樣一個SQL請求到了Observer的服務(wù)端，經(jīng)過一系列的解析、重寫和優(yōu)化過程，再由SQL執(zhí)行器負責執(zhí)行。

其它

其它OceanBase還有很多很好的優(yōu)點，雖然它年齡還小，各方面還很稚嫩，比如說他的強一致性和它的高可用的優(yōu)化，以及等等等等。。
更多的優(yōu)點可以移步官方推文

據(jù)說OceanBase也曾經(jīng)開源過0.4的版本，但是目前的版本已經(jīng)和開源中的架構(gòu)風馬牛不相及，也意味著OceanBase肯定是遇到了許多坎坷，但是最終還是遇到了自己的伯樂。雖然許多關(guān)鍵性的指標OceanBase還沒有達到，也沒有辦法在處理互聯(lián)網(wǎng)實時大數(shù)據(jù)量的處理進行高度的契合，生態(tài)圈也不夠完善，但是一切都在起步，就和我們每一個打字員一樣，都在成長的路上，We always on the road。