金磊 發自 凹非寺
量子位 報道 | 公眾號 QbitAI
「美眉，來嘍，來嘍，上鍊接！」
話音剛落。
「沒了，全沒了，都被搶光嘍！」
頭部主播李佳琦，一夜100億元銷售額這件事，著實震驚了不少人。
而經歷過這位「大魔王」雙11預售的友友們，或多或少肯定是見過剛才這種名場面了。
短短1秒不到的時間，數萬甚至更多商品瞬間被搶了個精光。
從下單到支付，那叫一個一氣呵成，卡頓一點點都得被搶購大軍甩開十萬八千里。
……
但你有沒有想過一個問題：
為什麼在這麼短時間，面對如此高流量，付款卻又是這般絲滑？
不賣關子，上答案。
因為在李佳琦瘋狂賣貨的背後，一直有位「硬漢」在默默發力。
它叫做OceanBase，是螞蟻集團自主研發的純國產資料庫。
至於它的能力，講真，讓李佳琦直播帶貨體驗變得絲滑「無感」，這都是小兒科了。
畢竟，OceanBase可是頂得住每年雙11支付、金融級場景超級大流量狂虐的那種資料庫。
經得起雙11考驗的OceanBase
先來感受一下歷年雙11成交額的恐怖增長。
光是去年的成交額，就達到了4982億元之多。
什麼概念？平均到雙11當天每秒的成交量，那就是：
每秒58.3萬筆訂單！
而在如此海量又迅猛的交易面前，資料庫就成了交易是否能夠絲滑完成的關鍵。
這是為什麼？
先來簡單科普一下資料庫在這個過程中起到的作用。
我們可以把資料庫當做是一個「賬本」，當一個客人在店裡買了一瓶醬油，作為店主的你，是不是得在賬本上記賬？
何時何地、誰、買了什麼、單價多少、交易是否成功、還剩多少瓶醬油……
所有與這次交易相關的資訊，都得一五一十地紀錄在這個賬本中。
看似簡單的流程，但往往會出現各式各樣的問題，比如人數。
一個客人還好應付，但如果同一時間，客人一窩蜂的到店裡，擠成一團吆喝著「快點記賬」呢？
若是店裡只有零星的幾個賬本，那你只能無奈地迴應：「請……排……隊……」。
再例如，即便你「奮筆疾書」，但訂單源源不斷，把整個賬本記得滿滿當當呢？
那你只能跟後邊的客人說：「抱歉，賬本滿了，沒法再交易了。」
再或者你記賬的時候寫太快了，漏掉了哪點資訊，或者把資訊寫序列了，那這幾筆交易可就亂套了。
……
所以，這個賬本，也就是資料庫，在整個交易過程中，就顯得尤為重要。畢竟在金融支付行業當中有一句話：
賬目是支付系統皇冠上的明珠。如果一個系統可以被應用在賬目上，那麼意味著它有能力應對所有系統。
而阿里巴巴，更準確點來說，是它使用的交易系統支付寶，所採用的資料庫，正是OceanBase。
但就像剛才提到的，像雙11這種大促，資料庫所面臨的壓力，在全球範圍來看都是數一數二的。
也就是說，即便客人、交易再多，支付寶的「賬本」也不許出現讓客人排隊、賬本不夠用，甚至賬本出錯等問題。
但仔細回憶一下，每年雙11剁手的時候，支付過程似乎都是非常絲滑無感的（除非沒搶到）。
而這，便歸功於OceanBase經過數年考驗，所沉澱下來的十八般武藝了。
整體來看，它的核心能力包括四點。
首先，是資料一致性。
這一點，不僅是對於OceanBase，對任何一個資料庫來說，都是最基礎但又是最難修煉的「功法」。
還是以醬油為例，假設它在資料庫中有2張表，分別是商品類型和商品品牌。
當商店裡進了一批醬油，那你就需要在商品類型裡插入「醬油」屬性，然而這個醬油是剛剛上市的新牌子，需要在商品品牌表裡新增對應的牌子。
但如果沒有資料一致性，那就會出現一個「沒有牌子的醬油」了。
因此，每當在事務完成的時候，必須保證所有資料都具有一致的狀態。
OceanBase便具備資料塊級實時校驗、事務級實時校驗、副本級定期校驗等特性。
而且資料一致性，必須是在任何情況下都得滿足的一點，而不是說能應付某次任務就行的那種。
為此，OceanBase的資料一致性，還具備運行連續的特點。
具體來說就是在高併發場景不會出現抖動、在極端異常場景下無損容錯，以及還內建灰度變更的能力。
其次，是極致彈性。
在雙11這種大促場景下，當天所需要的資料的容量，是平時的幾十倍，普通機房在這種量級面前是招架不住的。
而OceanBase則修煉了快速上雲、下雲的功力，這便是所謂的彈性。
當需要超大資料庫容量的時候，OceanBase可以飛速的將資料、服務部署到雲上；而當不需要這麼大容量時，就又可以飛速的從雲上撤下來。
這個過程聽起來非常簡單，但實際上對於資料庫來說，是一件非常有挑戰的事情。
不論是上雲還是下雲，絕對不可能是一個一個地「複製」，定然海量並行，這個過程基本涉及了接近50萬次的變更操作。
而所有的操作，絕對不能對業務產生任何的影響，是有種「一步錯便天下大亂」的感覺了。
第三，是極致容量。
剛才我們也提到，去年雙11平均每秒的成交量是58.3萬筆。
但其實這個數字對於OceanBase來說並不算什麼，因為它的真實實力，是能hold住每秒100萬筆訂單支付的那種。
這個數字對於一個資料庫來說，可能就是接近億級的QPS（每秒查詢率）。
為了應對這種難題，OceanBase採用的是兩級彈性架構。
第一級資料庫經常會採用的分庫分表，也就是從單個資料庫拆分成多個資料庫、從單張表拆分成多張表。
這樣一來，就可以把資料「打散」處理，降低每個資料庫的QPS。
除此之外，OceanBase還基於此做了一個「中介軟體」，它的作用就是避免重複勞動。
上述過程拆過一次，以後就交給OceanBase自動擴容就可以了。
最後，是高性能低成本。
光是資料庫能力上去還不行，還得考慮成本的問題，畢竟資料儲存和管理花費巨大，已經成為了業內不爭的事實。
而OceanBase可以說是那種「既能幹又省錢」的資料庫。
光是與去年相比，在性能提升61%的情況下，諸如LSM樹通用壓縮成本節省50%、資料編碼成本節省25%。
……
由此可見，OceanBase確實是一個經得起雙11考驗的資料庫了。
更強版本來襲，但今年沒上「戰場」
今年剛剛過去的雙11，成交額資料再創新高。
那麼問題來了：
OceanBase是否還能依舊堅挺？
答案很明顯是肯定的。
OceanBase自6月1日宣佈步入「3.0時代」後，目前已經3.2版本。
但是劃重點——今年沒用最新版！
理由很簡單：因為現在的OceanBase就已經完全能hold住了。
不過既然升到了最新版本，也是有必要了解一下更強的性能。
從資料層面來看，OceanBase3.2的性能可謂是猛增。
在相同環境和任務下，與3.1版本相比：
Sysbench OLTP 性能提升24%
BMSQL tpmC 性能提升30%以上
TPC-H 性能提升655%
而且OceanBase以前的目標可能就是如何撐住雙11，解決的是一種純粹的交易類問題。
而將來則不同，OceanBase劍指更智慧和更實時。
智慧化方面，就是通過AI的能力自動發現問題，而且還把診斷和決策「權利」，也一併交給OceanBase自己來處理。
以往我們看到的雙11「戰場」上，都會有眾多一線員工把守，生怕突發一些重大問題。
但以後就不一樣了，甚至身兼要職的OceanBase CTO楊傳輝都表示：
我不用去了！
這份自信，也是可見一斑了。
而在實時化方面，以往很多人會認為雙11只是一個交易的場景，但其實細看下來，它還是一個實時智慧分析的場景。
因為在雙11的時候，是要對商家做分析的，以往的方式在交易完成之後會到資料倉儲裡再做分析，這就需要消耗很長時間才能得出結果。
而理想的狀態是什麼呢？當然就是交易完立即出分析結果。
而現在，這已經不是一種理想了。
OceanBase3.2把很多對商家分析的工作，整合到了一套HTAP（混合事務和分析處理）系統裡面，既可以做實時交易又可以做實時分析。
這裡需要補充解釋的是，HTAP是OceanBase主打的資料庫類型。
而目前市場主流的是OLAP（聯機實時分析）和OLTP（聯機事務處理）兩種類型。
HTAP作為「新起之秀」，不僅打破了OLAP和OLTP之間長久以來固有的隔閡，而且在複雜場景中的優勢也是顯而易見。
就目前來看，OceanBase對這條道路的選擇是持堅定不移的態度。
而從上結果來看，能hold住全球數一數二複雜場景的OceanBase，是邁出了正確的一步。
從一個收藏夾開始，走向世界
現在的OceanBase，說是發展到全球最強原生分散式資料庫方隊也不足為過。
除了能輕鬆應對雙11這種「超高壓」場景，在全球權威的性能測試TPC-C上，也是獨佔鰲頭。
國產原生分散式資料庫打破了巨頭Oracle、IBM等集中式資料庫，長期壟斷全球資料庫的局面。
2019年，OceanBase以6088萬tpmC的線上事務處理性能創造了世界紀錄，終結了Oracle九年的霸榜。
而時隔僅1年，又以7.07億tpmC的成績，刷新了自己的紀錄。
……
但誰又能想象，就是這樣「功成名就」的資料庫，它的起點卻是一個小小的「收藏夾」呢。
故事還要從2010年開始講起。
在這一年，OceanBase在淘寶正式立項，但當時的情況是卻是「一無所有」。
但唯有一點是貫穿至今的，那就是它要走的路線——分散式系統。
簡單來講，就是把大活變成多個小活一起來搞。
而關於路線的確定，就不得不提一個人了，OceanBase創始人陽振坤。
在他看來，分散式系統就是資料庫的未來：
相比於集群等已有的模式，分散式系統具備更「抗壓」、「無限大」等優勢。
項目和路線是確定了，但技術嘛，「實踐才是檢驗真理的唯一標準」。
但這也成了OceanBase邁出第一步的最大阻礙——沒人敢用。
即便陽振坤和小夥伴們，像銷售一樣「地推式」地去推廣，依舊是無濟於事。
當時的淘寶雖然在使用Oracle等資料庫時，面臨著瓶頸問題，但當時已經做出了「拆分」這樣的應對措施。
加之還要MySQL的加持，基本上平穩運行是沒有問題。
在這節骨眼上，換誰想從頭折騰一遍，又有誰敢承擔其中的風險呢？
但淘寶的收藏夾，卻成為了重要轉折點。
因為當時收藏夾團隊的一個需求，無論是Oracle或者其它資料庫，都沒有辦法解決。
簡單來說，就是商品資訊在發生變更的時候，「收藏夾資料庫」和「商品資料庫」中對應的兩張表，需要做一個join的操作。
但以當時無論何種技術來看，開銷著實過大。
而陽振坤團隊卻說：I Can！
收藏夾團隊選擇信任陽振坤和他的團隊，讓他們放手一搏。
最終，憑藉著分散式系統的優勢，收藏夾在「換骨」之後安全度過了當年的雙11。
雖說首戰告捷，也算是打出了一點名氣，但不敢換資料庫這事，依舊還沒有得到解決。
於是，當時任職阿里巴巴CTO的王堅做出了一個重要決定——把OceanBase調入支付寶。
但在支付寶，畢竟涉及到的是金錢相關的問題，絕不容出任何差池。
雖然陽振坤團隊喊出「要替換掉Oracle」的口號，但同時也直接被質疑：
你怎麼保障一分錢都丟不了？
對此，陽振坤採用了「副本」的策略（上文中提到的能力之一）。
而當時的螞蟻集團CTO魯肅，將當年雙11的1%的流量交給了OceanBase。
但有意思的事情發生了。
在雙11之前的壓力測試過程中，身負99%流量的Oracle一蹶不振，bug層出不窮。
每次超過90%這個門檻，就會出現問題；但OceanBase在自己「一畝三分地」的表現卻出奇的穩。
於是，魯肅也算是背水一戰，決定讓OceanBase負責的流量，從1%升到了10%。
最終，OceanBase沒有辜負厚望，順利幫助支付寶度過了當年的雙11。
而截至當時，OceanBase的版本才迭代到0.5。
就這樣，OceanBase用一次又一次的行動，證明了自己的價值，證明了分散式資料庫的正確性。
時至今日，OceanBase已經進入第12個年頭了，陽振坤當年喊出的口號也已成真：
支付寶所有資料庫，均已替換成OceanBase！
……
若是從OceanBase的發展歷程來看，大致可以把它分為三個階段：
1.0時代 （2010-2014）：是「堅定走向分散式架構」的時代，包括髮布了新一代分散式引擎、實現海量儲存低成本、處理準記憶體引擎高性能業務。
2.0時代 （2016-2019）：是「原生分散式資料庫」的時代，實現了永遠線上，突破容量限制無限擴展，突破地域限制單機到城市級容災能力。
3.0時代 （2020-2021）：是「混合引擎、混合部署」時代，核心架構全面升級，打破邊界，同時支持TP和AP、混合雲部署。
而到了現在，OceanBase要做的還有「走出去」。
第一層，是走出阿里巴巴，而且是最具挑戰、最具難度的金融業務。
例如，OceanBase通過它高可用的架構，已經幫助一些銀行的核心繫統，實現兩地三中心容災。
不僅實現了跨地域無損容災，還提升了快速適配開發的能力。
第二層，是走出國內。
畢竟在資料庫界有句話，叫做「能處理金融行業的資料庫，其它場景都能處理」。
OceanBase確實也做到了如此，已經涉足國內多個行業，幫助提升資料庫質量，完成資料化轉型。
而目前OceanBase也在把目標慢慢向國外發展，在更大的舞臺、更強勁的對手較量。
最後一層，是走向開放。
截止到上個月末，OceanBase開源版本已經發布了140余天。
就在這短短的時日裡，它的開源社區已經累計了21000多使用者，斬獲4200+ Star。
不僅兼容MySQL，還提供越發開放的接口、部署工具、遷移工具和資料庫運維工具供使用。
同時在人才培養方面，與高校合作開設課程、出教材、辦比賽，還完成了1000多的人才認證。
……
這，就是國產資料庫OceanBase的故事。
那麼最後，站在這樣的一個時間點，又該如何重估它呢？
套用主播們經常用的一句話，或許就是——國貨之光吧。
