oceanbase是一個高性能、高可用、高可擴充并且廉價的關系資料庫。
<b>為什麼要做oceanbase？</b>
網際網路金融對資料庫系統提出了更高的要求。傳統資料庫在擴充性、事務特性以及資料強一緻等方面已經做了大量的工作，但是仍不足以達到現在網際網路飛速發展的要求。
以支付寶業務為例，其業務體量在平時幾乎是一個固定的值，但是在淘寶、天貓以及其他一些電商業務有促銷活動的時候，比如雙11。如何在很短的時間之内把資料系統的能力提高一個數量級甚至更高？對于普通的基礎設施系統，通過添加伺服器或者儲存設備等基本可以解決這個問題，但是傳統資料庫對于擴充能力有很大的制約。如果在資料庫層面做得更好，毫無疑問，将極大地促進業務的發展，即便是高峰期時段，也能夠給使用者提供和平時一樣的流暢體驗。
比如，平時在淘寶交易的時間為2秒鐘，那麼，使用者希望在雙11這種極限情況下交易的時間依然是2秒鐘。事實上，業界也有一些類似的技術，以試圖解決這些問題，以獲得更好的可擴充性和更高的性能，但是這些技術很難保證事務的完整性和一緻性。而網絡交易對資料一緻性的要求極高，且服務不可中斷。
oceanbase正是為了解決上述挑戰而生。
<b>為什麼oceanbase是海量資料庫？</b>
oceanbase資料庫是由阿裡巴巴集團和螞蟻金服集團自主研發的一款産品，其目标就是支援海量的資料的存儲和計算。
和傳統的資料庫相比，oceanbase所具備的可靠性、穩定性和性能對硬體裝置的依賴并不大。尤其是高可用性，oceanbase不依賴底層的硬體是無故障的。從設計之初，oceanbase的開發團隊就假設底層的硬體是不靠譜的。oceanbase就是要用普通的硬體産品打造出更好的資料庫服務。
2015年雙11創造了每秒8.59萬筆的交易支付，這是由oceanbase資料庫支撐達成的，最關鍵的是，其達到資料0丢失的目标，也就是說完全保證了資料的一緻性。oceanbase的完美表現也證明了，在普通的硬體平台之上，也可以打造出高可用的資料庫服務。
為什麼oceanbase是海量資料庫？因為，目前在oceanbase的表單容量最大已經超過3000億行，而且資料量還在不斷增長。另外，oceanbase資料庫還具備水準擴充能力，并且可以線上更新。迄今為止，在螞蟻的核心業務上，oceanbase是零故障，表現比之前的系統好很多。
目前，oceanbase資料庫處于不斷發展的階段，系統也在不斷更新，不斷演進。單個叢集的規模已經超過100台伺服器，就事務處理能力來看，單節點具備處理能力已經高達25萬個tps。
總結來說，oceanbase是全球第一個不依賴共享存儲的金融級資料庫。
<b>oceanbase的技術原理及實作</b>
oceanbase從開始就從設計理念上與傳統資料庫不同。技術團隊認為，資料本身是有熱度的，是以每天進行修改，但相對整體資料量來說都不多。為了設計更簡單，oceanbase從架構上就做了簡化。開發人員将資料分為兩個部分，第一個部分是靜态資料，持續化存儲在ssd盤上；另外一個部分則是修改增量，比如新插入的訂單資料，更新之後的賬戶資料等，都存放在記憶體裡面。傳統的資料庫所有的修改都是發生在本地的，oceanbase把修改增量放到記憶體，其好處在于，使用很少的記憶體就可以支撐更大的業務。
世上沒有完美的架構，oceanbase的這種方式會增多一些内部操作，産生一些消耗。不過，在技術團隊的反複測試驗證下，這一架構不僅能夠保證系統的性能，而且擁有更強的擴充性。
以上就是oceanbase的整體設計思路。
現在，最新的oceanbase 1.0版實作了每一個節點都可以做查詢、更新，處于一個完全對等的狀态。這樣的設計是為了增強系統的水準擴充能力。而在高可用方面，oceanbase的資料通常是至少擁有3個副本，并處于不同的機房。
oceanbase最大的叢集規模數已經達到了上百個節點，支撐的是線上交易型的資料，一套叢集可以服務很多個業務。甚至在上了公有雲服務之後，可以支撐成百上千個租戶。為此，開發人員将租戶機制放進了資料庫叢集裡面，這樣的好處顯而易見，那就是成本得到極大的降低。
線上交易中，每一筆交易都是非常少量資料的更新或者查詢操作。但是要查大量資料，比如使用者的詳單、曆史資料狀态時，如果資源排程能力不強，那将是非常危險的。oceanbase可以在租戶級别将資源的使用控制在安全的水位，進而避免了如雙11中出現大查詢而導緻網絡堵塞的情況。
對于oceanbase資料庫來說，水準擴充其實是非常簡單的。比如要增加一個節點，新購置一台伺服器，剩下的資料庫自己就能夠解決，包括資料重新的分布等。
節點故障，硬體損壞，系統更新等，這些情況非常常見，如何做到持續可用呢？oceanbase提供了一種服務，在中間設定了一層obproxy，主要是表分區資訊、位置資訊等。當要做某一個查詢的時候，根據查詢條件會自動化地将請求分發到oceanbase叢集的特定節點上，這樣就保證了路由是最短的，是以獲得的性能也是最好的。
oceanbase與傳統的資料庫不一樣，從誕生開始就沒有準備采用磁盤，而是在ssd上，包括讀寫分離、批量回刷都基于此。另外，oceanbase還充分利用記憶體計算的能力來提升性能。當然，資料不可能一直放在記憶體，為此，技術團隊設計了一些特别的機制，比如把記憶體裡的資料回寫到ssd，而且都是在系統運作低谷期進行這樣的操作。
如果性能不提升，即便是擴充性非常好，也沒有價值，因為那隻意味成本的不斷增加。為此，技術團隊針對記憶體做了大量的性能優化工作。比如通常的應用場景有兩種，一種是擷取單條的記錄，另一種是擷取一批記錄。oceanbase在記憶體裡面維持兩套索引，一個是hash索引，一個是btree索引，分别對應處理這兩種不同的請求。同時，記憶體資料結構都是設計成無鎖的，是以擴充性非常好。
這裡對比一下mysql。大家都認為mysql的性能很好，路徑很簡單，但是測試資料顯示，其單核的tps能夠達到1萬，但是32核幾乎難以做到10萬的tps。oceanbase的單核tps是8000或16000，而10核的tps則達到8萬或16萬，正因為如此，即便是跑在普通的伺服器上，oceanbase也不會産生并發瓶頸。
<b>oceanbase的發展</b>
oceanbase現在支撐了支付寶的所有核心業務，如支付、交易、賬務、花呗等，還有網商銀行以及淘寶的很多交易業務也都基于oceanbase。
在oceanbase研發之初，技術團隊在存儲方面做了較多的工作，是以sql能力不是特别強，是以也制約了一些拓展業務的能力。但近年來，技術團隊投入很大的精力提升oceanbase的sql能力，相容并超越mysql，甚至逐漸具備oracle的核心能力。這樣，未來業務的遷移會變得平滑順暢，且不需做改動。
oceanbase項目始于2010年。
在2011年開始做第一個業務，oceanbase還是一個kv系統。
2012年，oceanbase開始做sql支援，也明确了其目的——為了支援更高要求的金融級的業務需求。
2014年，oceanbase釋出了非常重要的0.5版本，通過架構的一些改進，已經可以做到持續可用且資料0丢失。在這一年，oceanbase也首次支撐了支付寶的核心業務，2014年雙11，支付寶交易有一部分流量是跑在oceanbase上的。
2015年3月，支付寶所有的交易都切換到了oceanbase上，真正意義上徹底和oracle說再見。
而很快，oceanbase就可以提供雲資料庫服務。
<b>掃碼關注，擷取更多技術幹貨。</b>
