本文主要從oceanbase的起源開始講起，進而和大家分享了oceanbase的曆程與架構演進，重點介紹了雲資料庫oceanbase，最後談及了oceanbase未來的發展。
以下為演講内容整理：
什麼是oceanbase
oceanbase是在2010年6月份開始立項的，oceanbase不是nosql系統，它是結合傳統關系型資料庫功能上的優點和分布式系統在可擴充性、可靠性上的優點打造的一款分布式關系型資料庫。oceanbase支援完整的acid，可擴充、高可用，相容mysql協定。
oceanbase的發展曆程
<b>網際網路對傳統關系型資料庫的挑戰</b>
<b>可擴充性</b>
傳統關系資料庫本質上是單機資料庫，當你的性能或容量不足時，需要換一台更大的機器，我們是一直向上擴充。想要水準擴充需通過讀寫分離 & 分庫分表來解決，這也極大的增加了應用層的複雜度。以圖中收藏夾業務為例，收藏一個商品稱為收藏資訊，包括收藏本身和收藏商品的資訊，收藏的商品資訊是變化的，商品降價需要在使用者收藏夾裡展現出來，收藏資訊隻能按使用者區分，商品隻能按商品id區分，當一個使用者收藏了多個表的商品時，需要在中間件層完成join操作，這樣會加大業務的負擔，相當于在中間件層或業務層完成了資料庫本該完成的工作。
<b>可靠性</b>
傳統關系型資料庫本質上是一個單機系統，主備間是需要進行資料同步的，資料同步有三種模式：最大可用模式、最大保護模式、最大性能模式。最大保護模式要求主庫和備庫都寫成功後才會應答客戶，一旦網絡抖動或者備機當機等，整個服務就中斷了，網際網路行業中用這種模式比較少。最大可用模式要求主庫寫成功後就立即應答客戶，然後把資料異步同步給備庫，一旦主庫當機，極有可能造成資料不一緻的情況，為了解決資料不一緻的問題，一般會加共享存儲等保證可靠性；主備機無法決策出誰是主誰是備，如果主機當機，備機無法自己切換成主機，需要通過第三方元件切換。
oceanbase的目标
在使用普通pc伺服器，不使用共享存儲、小型機等昂貴硬體，以及伺服器、磁盤、網絡、機房(idc)等并非持續可用的情況下，oceanbase的目标是：
首先要保證關系型資料庫的功能、支援跨表跨行事務，其次要保證資料可以分布式水準擴充，對應用透明，另外，資料庫要高可靠、資料強一緻，可抵禦單機、機架、機房(idc)故障，且高性能。
oceanbase主要面臨的問題
資料庫的功能：傳統關系型資料庫發展時間較長，功能豐富
分布式一緻性：分布式系統的多副本如何保持一緻性；最終一緻性、弱一緻性不符合使用者需求
分布式事務：理論成熟，工程與性能上的優化
資料庫資料總量非常大，但增删改量很少。
我們設計了如圖架構，把資料分成兩個部分，一部分為基線資料，另一部分為增量資料。每次的修改我們就放到一個單機的記憶體中，基線資料拆分到多個機器上，這樣就避免了分布一緻性的問題。
增量資料不可能永遠放在記憶體中，是以記憶體寫到一定程度後會做每日合并，合并會在資料庫每天的通路低谷時進行，對業務沒有影響。
<b>最初版本</b><b>v0.2</b>
存在兩個單點rootserver和updateserver，通過ha(http://linux-ha.org/)來實作高可用
基線資料節點可任意擴充
寫節點半同步，不能區分insert / update
v0.2相對較原始，我們的用戶端代碼由業務同學來寫，我們的更新直接會到updateserver端，不能區分insert / update，這樣解決了收藏夾的一個業務痛點（通過資料備援+join更新資訊消滅随機讀/寫）。
<b>v0.3 </b><b>多</b><b>idc & olap </b>
相比于v0.2不同的是，v0.3去除updateserver的ha，改由rootserver來決定誰是master
支援多idc部署、但idc切換需要人工介入
在查詢層面對并發作了優化，可滿足輕量級的olap
v0.3綁定的業務是廣告報表，主要是把資料在離線的平台計算好後導到關系資料庫中，實作資料分塊、并發查詢，旁路導入資料。v0.3達到了千億條記錄和百t規模資料，但用戶端的表現力差。
<b>v0.4 </b><b>支援</b><b>sql</b>
v0.4支援sql，并不是單純改一個接口那麼簡單，我們在資料庫功能方面邁出了一步。v0.4相容mysql協定，區分update/insert，支援并發更新。
v0.4去除自定義協定的用戶端，沒有特别多的核心業務，主要是曆史庫、結構化key/value類型的非核心業務，我們也對外開源，并開始核心業務的嘗試。
<b>v0.5 </b><b>多機房同步</b>
rootserver分布式選主，不再依賴ha
多機房部署，少數派機房故障自動容災，資料不丢失
覆寫螞蟻多個核心系統
在遷入核心業務系統時，我們也積累了經驗，形成一套模闆。比如最開始上線的螞蟻交易核心系統；當年雙11承擔20%的流量；2015完成支付在内的多個核心系統遷移；第一個支撐的銀行的非商業資料庫。我們積累了一整套遷移方法，比如用螞蟻中間層向應用屏蔽掉了sql的差異，中間層通過通路資料的類型去調用不同的模闆，灰階引流，随時復原，我們稱螞蟻為流水型的系統。
回過頭考慮0.5之前的架構，得出單updateserver的意義手至關重大的，極大簡化實作，避免分布式事務，具有較簡單的資料模型。當然在叢集規模、資料導入上也有諸多限制。
<b>v1.0</b>
v1.0變更了資料模型，我們把資料分布引入了傳統觀念資料庫的分區表，交給使用者來定義，根據業務特點可能把資料分成一片一片，這時，我們把四種角色都合并到一個角色中，稱為observer。每個observer是對等的，它可以負責一個分區或者多個分區的資料，每個分區會部署在3個機房，這三個副本之間會自行通過分布式選舉，選舉出一個組來提供服務，此時我們具備很高的靈活性，使用者可以根據業務邏輯來分區。
<b>同步機制</b>
主庫執行寫事務并同步到備庫，超過半數成功則事務成功。
<b>錯峰合并</b>
逐idc合并，灰階引流，緩存預熱，對使用者沒有影響
同樣的用在更新流程上，往往是在備庫更新好，再切到主庫中
oceanbase有着天然的優勢，無論是在版本更新還是維護，都可以應用到這套機制，整個維護或者故障都可以做到對使用者透明，使用者感覺不到變化。
<b>降低每日合并耗時</b>
最開始資料分布采用範圍分布，一條記錄修改，整個資料重寫。我們在每日合并上也做了優化，采用了更細粒度的分片，把資料分塊，如果某塊資料發生更改，隻對這條資料進行重寫即可。
雲資料庫oceanbase
雲資料庫oceanbase是一款阿裡巴巴自主研發的高性能、分布式的關系型資料庫，支援完整的acid特性。它高度相容mysql協定與文法，讓使用者能夠以最小的遷移成本使用高性能、可擴充、持續可用的分布式資料庫服務，同時對使用者資料提供金融級可靠性的保障。雲資料庫oceanbase相對于傳統資料庫的特點如下：
基于oceanbase的dbaas：提供自助化服務，一鍵即可擁有oceanbase執行個體；免管理；提供使用建議
在螞蟻和集團長期使用，原生态輸出
具備輸出到專有雲的能力：網商銀行
總的來說，雲資料庫oceanbase具備多可用區部署，與内部最新版本保持同步，以及生态支援和叢集共享模式、無縫動态伸縮、即時生效。
未來發展
oceanbase目前仍然在快速疊代
灰階更新對應用透明
讓資料庫的歸資料庫，一切以簡化使用者使用為目标
未來oceanbase主要應考慮以下幾個方面：
<b>完善功能：</b>以業務需求驅動，業務不符合什麼功能我們就做什麼功能；滿足内部業務的平滑遷移，完善資料庫相容性問題；oceanbase重點完善支援flashback。
<b>曆史庫：</b>曆史庫是關系型資料庫的一些瓶頸造成的，oltp系統有典型的冷熱資料；為了降低成本等，冷資料需要遷移，oceanbase正在做冷熱資料自動識别、異構機型等。
<b>oltp & olap</b><b>混合負載：</b>oceanbase比較适合olap的，oceanbasek可以做線上資料和離線資料同時進行分析，可以做observer内的資源隔離、大查詢限流、利用備副本等。
<b>成本：</b>保持高可用的情況下，降低副本數。