歡迎訪問 OceanBase 官網獲取更多資訊：https://www.oceanbase.com/
3 月 25 日，第一屆 OceanBase 開發者大會在北京舉行，OceanBase CTO 楊傳輝在主論壇進行了《打造開發者友好的分散式資料庫》的分享。
以下為演講實錄：
各位 OceanBase 的開發者，大家上午好！OceanBase 在去年 10 月份釋出了最新的 OceanBase 4.0 版本，4.0 版本作為單機分散式一體化架構，我認為它給開發者帶來最核心的價值在於極大地降低了分散式資料庫的使用門檻。
今天也是第一次開發者大會，非常高興能在這裡與我們 OceanBase 的開發者談談我自己對於怎麼去構建一個對開發者友好的分散式資料庫的思考。
OceanBase整體架構演進
首先，OceanBase 宏觀上三次架構的演進，有很多人可能知道早期的 OceanBase 是一個單寫多讀的架構，存在 OceanBase 的 0.1 版本直到 0.5 版本。OceanBase 在 1.0 版本釋出了當時的全分散式架構版本 1.0，這個 1.0 架構也應用在 1.x 版本、 2.x 版本、3.x 版本，直到 2022 年釋出了最新的單機分散式一體化架構 4.x 版本，它對於使用者最核心的價值剛才已經提到了—— 在於把單機的優勢也就是單機的高效能、低成本與分散式的優勢可擴充套件的能力、高可用的能力完全融入到一套系統裡面。 這樣的一個系統對開發者是非常友好的，我們也選在這樣一個時間點跟大家來談開發友好的話題。
穩定可靠，很多個0前面那個1
首先，資料庫有很多對開發者比較有用的特性，非常強大的功能、很好的效能，或者可能有一些非常有趣的特性。比如能夠支援 Severless、多雲原生，甚至可以跟 ChatGPT 結合。我認為對於開發者而言，對於資料庫來講，開發者最看中的特性永遠是穩定、可靠。我相信在座的很多開發者應該都或多或少有過晚上 12 點處理故障的經歷，我用 “穩定可靠” 作為今天分享的開場。
阿里巴巴的 DBA 團隊有一句話，穩定可靠是資料庫這樣的基礎軟體很多個 0 前面那個 1。 沒有穩定可靠，資料庫有再多的功能效能都是沒有任何意義的。OceanBase 在 2014 年把當時支付寶的交易業務由 Oracle 遷移到 OceanBase，這是 OceanBase 第一個支撐的核心業務場景。我記得很長一段時間，其實我們睡不著覺，擔心出現嚴重的生產事故。
這個時間我也研究了航空業幾乎所有的飛機失事事件，最後發現一個法則：海恩法則，我把這個法則給大家讀一下。每次嚴重事故的背後，必然有 29 次輕微事故，300 起未遂先兆事故，以及 1000 次事故的隱患。這就表明想避免嚴重事故我們需要做的是提前解決掉事故隱患，透過解決這些事故隱患從而降低未遂先兆事故以及輕微事故的機率，從而避免嚴重事故。
OceanBase 團隊一直這麼做，我們在 2010 年開始立項，並且一直在支撐螞蟻集團所有的核心業務，支援每年的雙 11。但是大家都知道，OceanBase 從來沒有出現過一次重大的生產故障，沒有丟過一次資料，為什麼？因為我們把所有的事故隱患能夠提前解決掉。
當然，支付寶應用 OceanBase 之所以做得這麼穩定，也有自己的最佳實踐，我分享三點。
首先，支付寶有著非常特別的設計。 支付寶的業務把我們的資料庫分成兩類，一類狀態庫，一類流水庫。比如在支付寶做一筆付款操作，付款的流水放在流水庫裡面，每個賬戶有多少錢放在狀態庫裡面，這就使得當流水庫發生故障的時候，應用層能做應用層面的failover，把新的流水寫到全新的資料庫裡面，這種模式使得當OceanBase每次釋出新版本的時候，我們總是先拿流水庫來做試驗。
第二，對於資料一致性的堅持。 這裡面起了一個名字應校盡校，不管多個副本之間的資料一致性，還是說每次事務的併發操作或者讀寫磁碟都需要做校驗，即使可能增加系統複雜度，會犧牲效能，只要能夠做校驗就做校驗。我們內部有一個釘釘群，解決資料一致性的隱患。之所以線上沒有出現過一致性問題，是因為我們在群裡面把這些問題提前解決掉。
第三，支付寶是非常複雜的系統。 對於這樣的系統我們需要透過 混沌工程的方式 保證它的穩定性。我們需要給這個系統引入一些混沌因子。網商銀行經常做一件事情，很多開發者都聽說過，斷網演練。剛開始運維團隊會通知業務團隊，某某時間開始我們要做斷網演練，請做好準備。第二個階段，甚至我們都不通知業務團隊，直接拔網線，掐電源。透過很長時間的打磨，才把我們的高可用能力、RPO、無損容災的能力，由一個“PPT"變成生產系統裡面可落地的現實。
在座很多開發者有很多來自於像支付寶、阿里巴巴這樣的網際網路公司，網際網路公司有很強的技術能力，但是各位開發者有沒有想過一個問題？你所在的公司備份的資料能不能恢復出來？我給大家說一個事情，支付寶早期使用 OceanBase 的時候，我們也做了很多備份，但是當時的備份資料是不可恢復的，以後也可以去你公司問問 CTO 到底能不能恢復？我們立了備份恢復最佳化的專項，經過很長時間的打磨最終做到備份恢復成功率百分之百。
高效能 低門檻 一體化架構提升效能，將低門檻
開發者需要效能高，使用門檻比較低的資料庫。 OceanBase 早期的版本有一個被詬病的問題，很多開發者告訴我們，OceanBase 比較重。最早期的版本一臺機器要求 128G 記憶體，之所以會有這麼高的要求，要求這麼高配的伺服器，一個最本質的原因在於，我們這樣的分散式資料庫早期的架構裡面每臺機器需要使用大量的 CPU 和記憶體用於處理分散式相關的 overhead。
4.0 版本透過一體化架構避免了每臺機器上的分散式 overhead，從而提升效能，並把門檻降低下來。今天我們用自己的筆記本，用樹莓派就能部署 4.0 版本。
▋ 單機效能不足，使得 NewSQL 無法成為主流資料庫
我們對業界主流的 NewSQL 系統做了測試，發現主流的 NewSQL 系統相比 MySQL 8.0 效能差很多，只能做到 MySQL 的 1/5 到 1/10，我一度懷疑我們的測試是不是出現了問題，直到最後在它們的官網發現它們的測試結果跟我們是一樣的，我才確信不是我們的測試有問題，而是 NewSQL 系統的單機效能真的很差。
單機效能很差，使得 NewSQL 系統沒有辦法成為主流的資料庫。今天我們看到很多的分散式資料庫，比如分散式的表格系統，分庫分表，NewSQL 系統，但是任何一種系統都沒有辦法在可擴充套件性、效能、功能三方面，同時滿足開發者的需求。
Google 有一個系統叫做 Spanner，它裡面有一個設計假設，為了做全球機的時鐘同步，每個事務提交的時候需要額外等待 7-10 毫秒，Google 內部透過把應用由同步程式改成非同步程式解決延遲，也許 Google 的程式設計師很強，但是對開發者很不友好，很多地方的程式設計師沒有辦法做到這一點。
開發者需要同時具備可擴充套件的能力以及單機功能和效能的單機分散式一體化資料庫。 這個資料庫其實只要一說出來大家都想要，簡單來講既要也要，什麼都好。這樣的資料庫到底是一個願景，是一個烏托邦式的願景，還是說真的可以被實現的系統？
▋ 為什麼一體化架構能夠同時做到可擴充套件和高效能？
OceanBase 4.0 也號稱自己能夠做到單機分散式一體化架構，我們的背後到底有沒有什麼魔法？
我們說我們實現了可擴充套件和單機高效能以及整個系統的高效能，這裡面肯定有一些設計的假設。最根本的假設就在於對於所有的 OLTP 場景，雖然背後可能因為資料量很大，會是分散式資料庫，但是大部分的讀寫操作都是單機操作，只有少部分的讀寫操作才是跨機操作。
大家都有自己的銀行賬戶，假設所有的銀行帳戶存在一個銀行的資料庫裡面，相信在座的各位大部分時間你是在讀寫自己的賬戶，你的少部分時間才會給別人轉帳，大家給別人轉帳之前應該會反覆確認。對於這樣基於賬戶的資料庫，假設按照賬戶做了 Sharding，意味著大部分時間使用者都是讀寫自己賬戶是本地單機操作，少部分時間是遠端分散式操作。
我們設計一個分散式資料庫要做的首先是保證主要的 80% 以上的單機操作效能不會因為分散式架構有額外的 overhead，這個事情做起來很難，只有 OceanBase 做到了。第二，最佳化另外 20% 的效能，使得這 20% 的分散式操作雖然因為網路有一定的 overhead，但儘可能做到足夠低，最終使得整個系統不管單機還是多機層面都能夠保持高效能。
分散式系統裡面有一個特性——可擴充套件性，為了實現可擴充套件性，不同系統會有不同的設計選擇。
▷ 集中式的資料庫選擇非常簡單直接——“對不起，我做不到，我乾脆不支援。”
▷ NewSQL 系統把可擴充套件性下沉到儲存來解決。業界主流的 NewSQL 系統分成 SQL 層和 KV 層，這種方式解決了可擴充套件性的問題，但導致了新的問題——每臺機器的效能特別差，因為每臺機器都需要額外一次從 SQL 轉到 KV 層，導致延遲。
OceanBase 1.x 版本到 3.x 版本，採取是預先分割槽的方案，每個分割槽相當於是一個 mini 資料庫，有自己單獨的 redo 日誌，透過這樣的模式也能解決一部分分散式資料庫的問題，但是帶來的影響就是每臺機器要服務很多分割槽，服務很多 mini 資料庫，有很多額外的 overhead，單機要求高配的 CPU 和記憶體。在 4.x 版本做了重構，實現單機一體化架構，每個單機有很多資料分割槽，但是隻有一個資料流，使得單機讀寫沒有分散式相關的 overhead，與原來的單機可以站在同一水平線上 PK 效能。
4.x 版本做到所謂的一體化，當增加新的伺服器的時候，增加新的日誌流，原來的分割槽從老的日誌流裡面摘出來遷移/轉移到新的伺服器新的日誌流裡面，既能保證單機的高效能，又保證可擴充套件。
從單機到分散式使用者是沒有感知的，當只有一臺機器的時候，所有的資料分割槽綁到一個日誌流裡面，有點像單機的 MySQL，我們可以使用一個 MySQL 完全相容的客戶端直接訪問 OceanBase 的單機模式。
當處理能力不足增加伺服器，後臺觸發一個遷移操作，有一部分分割槽從原來的日誌流解綁出來到另外一臺機器。遷移的過程客戶端做動態的路由，這意味著如果這個分割槽分片遷移沒有完成，那還是訪問原來的伺服器。遷移完成之後，就訪問新的伺服器，原理就是這麼簡單。
整個遷移操作是後臺的操作，也一定會佔用後臺的 CPU，佔用後臺的網路，佔用後臺的伺服器頻寬。對於任何一個資料庫，這種頻寬的佔用非常少，一般來講只要不是在雙 11 凌晨這種極限高峰的場景，系統都是有餘量做動態遷移，不影響前臺正在進行的線上交易事務。
▋ 一體化架構單機效能超越 MySQL，降低開發者使用門檻
單機分散式一體架構的單機效能透過評測確實超越了 MySQL 8.0，我們對 32C 的機器做了 MySQL 8.0 和 OceanBase 4.1 效能測試。不管單行讀寫的效能，還是多行讀寫，只寫，插入，讀寫操作，OceanBase 4.1 的效能都高於 MySQL 8.0， 並且最為綜合的讀寫場景高出 39%。
單機分散式一體化架構能夠大幅度降低開發者的使用門檻，早期的 OceanBase 版本確實因為架構設計的問題，我們需要單機用很高配的記憶體，128G。隨著不斷最佳化，從 128G 最佳化到 64G、32G、16G、8G，不斷降低，現在已經能在樹莓派上直接執行我們的 OceanBase 4.x 版本。其實我們還有很大的最佳化空間，以後還會把更好的產品帶給各位開發者。
各位開發者，當你們想到一個分散式資料庫的時候，你是不是一定會想到有很多的不同角色，有的角色是做管控的，有的角色是做工作機的，有的角色做 SQL 節點，有的做儲存節點，但是 OceanBase 裡面只有一個節點，一種角色叫 OBSever，一臺機器一個 OBSever，N 臺機器 N 個 OBSever，不管一臺還是多臺，像原來的單機資料庫一樣，可以使用單機資料庫一模一樣的方式使用 OceanBase 單機分散式一體化的資料庫。
功能強大，一份資料既做交易又做分析
開發者選擇資料庫的時候會選擇功能強大的資料庫，很酷。大家今天都談一個概念，HTAP，前面的報告裡面包括很多其他廠商也在講這個概念。我認為，今天國內的 HTAP 有三種不同的模式。
第一種 HTAP 又能做 OLTP，又能做 OLAP，什麼都可以，這往往是很多人的理解，這個理解往往存在於“PPT”裡面。
第二種 HTAP，做 OLTP 做不到極致，做 OLAP 比不過單獨獨立的 OLAP 資料庫，那就做 OLTP 與 OLAP 的交集。這是做交集的思路，把 HTAP 做窄了。
OceanBase 講的 HTAP 非常簡單，那就是 OLTP Plus，先把 OLTP 做到極致，在 OLTP 做到極致的基礎上一份資料既做交易又做線上分析，這就是我們 OceanBase 講的 HTAP。
我們認為 HTAP 不是萬能的，有它的適用場景，剛才周校長講到，一個比較好的做法是有一個套件，這個套件裡面有多個系統，其中一個系統叫 HTAP，另外一個叫離線 AP，可以共享一套引擎，內部元件可以做外掛化，這是可行的思路。
僅僅針對 HTAP 的話，沒有辦法解決所有的場景。最典型的離線分析場景，HTAP 是不適合的。HTAP 比較適合用在線上 OLTP 場景以及線上的實時分析場景裡面。對於中小企業一般來講不會構建一個非常複雜的公司級的資料倉儲，要求簡單性，想要非常輕量實時分析，一箇中小企業一個 HTAP 系統大部分情況下能搞定所有資料庫的需求。對於大企業一定有自己獨立的資料倉儲，這樣的資料倉儲適合用單獨的離線 OLAP 系統。每個大企業裡面又有很多業務，業務裡面有很多輕量級的實時分析，每個業務適合使用一套 HTAP 資料庫，這是 OceanBase 理解的 HTAP。
HTAP 的關鍵在於採用一套系統，一套 schema。 不能讓開發者定義兩張表格，使用方式太複雜了，開發者也沒有辦法接受。有一些不同的實現方式，對於一個分散式資料庫而言，大家知道它一定會有多個副本，最簡單的實現方式就是在主副本里面又做 OLTP，又做 OLAP，讓 TP 和 AP 的效能都好，當然不可能把兩種效能同時做到極致，這種適合比較輕量的實時 OLAP 場景。
第二種，分散式資料庫裡面有多個副本，主副本做 OLTP，備副本單獨拉出來做實時的 OLAP，適合比較重量級的線上 OLAP 場景。
第三種，兩個系統，透過表同步或者分割槽同步來實現 HTAP。真正的 HTAP 應該是前兩種的實現方式，第三種實現方式有可能會導致一些問題，比如延遲比較大，甚至有可能因為資料不一致，導致額外的一些問題。
OceanBase 的做法是前面兩種模式，現在支援第一種模式，在一個主副本里面又做 TP 又做 AP，我們正在做第二種模式，列存方案，希望 Q3 把第二種模式做出來。
講到 HTAP，開發者肯定會有一個問題，一份資料是不是真的能夠解決資源隔離的問題。 OceanBase 3.x 版本支援透過 cgroup 來實現 CPU 資源隔離，有一個功能叫做 resource manager，實時生效。左邊的圖裡面開啟 resource manager 功能之後，很快 OLAP 請求的負載大幅下降，OLTP 的併發能力大幅度上升，這個操作實時生效。
我們在 OceanBase 4.x 版本進一步增加了對於 IO 隔離的支援能力。在右圖的例子中，有租戶 1、租戶 2 權重分別是兩萬和一萬，租戶 4 的最大 iops 是 5000，租戶 3 在 10 秒之後加入這個系統，最大 iops 是 10000。可以看到不管我們的系統如何增加壓力，租戶 4 的 iops 都不會超過 5000，等到租戶 3 加入之後，使用10000 iops，租戶 1 和租戶 2 的 IOPS使用很快等比例下降，永遠保持在 2：1 這樣一個狀態。測試資料表明，OceanBase CPU 的隔離和 IO 隔離做得不錯，能夠滿足絕大部分 OLTP、OLAP 的隔離需求。
大家都吃過海底撈，原來使用單機資料庫，有擴充套件能力不足的問題，也面臨交易和分析因為鏈路複雜有延遲的問題，透過 OceanBase HTAP，TCO 下降了 35%，這個是 HTAP 的魅力。
符合技術趨勢：多雲原生
我們跟開發者溝通，他會問我一個問題，OceanBase 是不是支援公有云？這個問題的背後想問，OceanBase 是不是符合技術趨勢的？
今天包括前面的分享，我們也看到了公有云、多雲、混合雲一定是未來資料庫領域最大的技術趨勢， OceanBase 明顯是符合技術趨勢的，不僅是雲原生的，我們還是多雲原生，能夠部署在多雲平臺，甚至是一些混合雲平臺，對使用者提供完全一致的使用體驗。
OceanBase 早期在螞蟻集團的支付寶，大家可以把支付寶和螞蟻集團想象成一個特別大的私有云平臺，我們已經在支付寶螞蟻集團部署了幾萬臺伺服器，幾百萬 CPU 核，早期上雲其實很簡單，就是把支付寶的物理伺服器變成公有云上面的裸金屬伺服器，原來使用大規格的伺服器、大規格的記憶體不變。我們做好產品的工具，做好雲上的適配，這個階段叫 IaaS 上雲。
做了一段時間之後，開發者給 OceanBase 提了一些需求，最典型的需求有兩個： 第一個，開發者希望能夠分別購買 CPU 和儲存，並且儲存需要做到按需使用按需計費，這是一個典型的儲存計算分離的需求。第二個，開發者希望使用一個比較小規格的伺服器，不希望使用特別大規格的，因為便宜，這是小規格的需求。
我們第二階段主要完善了儲存計算分離和小規格的方案，並且在阿里雲上面做了大量生態工具的適配。去年又進一步支援了多雲原生，支援了 AWS 以及其它一些國內外流行的雲平臺，我們的儲存計算分離方案也進一步升級為開放的儲存計算分離方案，並且在多雲安全與多雲生態做了大量投入、大量的適配工作。
我提一個觀點，我認為開放的儲存計算分離是多雲原生的必然路徑。 我認為所謂的開放儲存計算分離就是對於一個資料庫軟體一個資料庫廠商來講不要自己做儲存，不要自己做分散式檔案系統，不要自己做分散式 Key value，而是基於雲廠商的雲端儲存做二次開發，透過一些技術手段比如快取、容災方案解決雲端儲存的延遲問題，解決雲端儲存的穩定性問題等等。OceanBase 對於多雲原生開放的儲存計算分離探索了很長時間，也發現了很多問題。
這個方案的複雜度是超出我最早的想象，我們做了很長一段時間之後發現，不同的雲端儲存雖然它的介面差不多，但是它們在功能、效能、穩定性以及成本上面都有非常大的差異。舉幾個簡單的典型例子。
第一，阿里雲有一個物件儲存 OSS，能夠支援追加寫入，這個功能對於資料庫來講是非常有用的，大家都知道資料庫要寫 redo log，除了阿里雲其它都不支援。
第二，我們還發現這個雲端儲存的網路跟本地的機器網路相比頻寬非常小，為了做好多雲原生，需要做大量的資料壓縮工作，雲端儲存裡面不同的儲存成本差異巨大，物件儲存很便宜，雲盤非常貴。怎麼把冷資料放到物件儲存裡面，這也是我們需要解決的問題。甚至發現讓我自己都覺得很驚訝的現象，某一些雲廠商是比較穩定的，但是還有一些雲廠商的雲端儲存非常不穩定，這個不穩定是持續會發生的，這就使得需要在資料庫層面做更好的容災能力。
OceanBase 在公有云上一個非常明顯的優勢，那就是價效比。 我們的價效比領先於國內外同類產品，我對 OceanBase 的價效比在公有云上簡單算一筆帳，假設在阿里雲和 AWS 上分別購買 4C16G 的 ECS，分別部署 MySQL 8.0 和 OceanBase 4.1，到底大家的價效比怎麼樣？
價效比的衡量指標 Price/ Performace，也就是每個 tps 需要的硬體價格，這個比值越小，價效比越高。OceanBase 的單機效能高於 MySQL 8.0，OceanBase 儲存成本只有 MySQL 的1/3。 MySQL 部署兩臺機器，OceanBase 部署三臺機器，我們做三副本，OceanBase 可以兩臺機器是全功能副本，還有一臺機器只存日誌可以使用更便宜一點的機器。150G、300G、500G、1TB。
無論任何一種場景，OceanBase 的價效比都是領先於 MySQL，而且隨著儲存容量的越來越大，OceanBase 相比 MySQL 的優勢也越來越大。阿里雲上是這樣，AWS 上也是這樣。我們做了測算， 在同等效能的前提之下，相比雲上的 MySQL 8.0，OceanBase可以降低 18.57%-42.05% 的整體成本。如果儲存空間變得更大，OceanBase 降低會更多。
GCash 是菲律賓版的支付寶錢包，原來用的 MySQL 伺服器，成本非常高，管理非常複雜。透過遷移到 OceanBase HTAP 分散式資料庫之後，最終做到把所有的MySQL 整合到一套系統裡面集中化管理，整體擁有成本下降了 40%，當然因為我們的儲存優勢，我們的儲存容量壓縮，儲存裝置甚至下降了 70%。
基於開源，持續降低開發者參與門檻
對於開發者來講，前面分享的都是一些 OceanBase 系統技術特點和技術優勢、產品特性。開發者也會關心一個東西，這樣的產品對我來講意味著什麼？到底好不好用？它的門檻有多高？就是我們經常談到的使用者體驗的問題。
OceanBase 在 2021 年 6 月份，我們正式開源之後持續地基於 OceanBase 開源社群版來持續降低開發者參與和使用的門檻。 我們在剛開始開源的時候，第一個階段非常簡單，只是把核心先開源出去，當然核心開源之後找了第一批種子使用者，基於種子使用者的核心生產系統的需求來完善我們的生態工具。
這個過程完成之後，越來越多的使用者開始把他的核心 OLTP 場景應用 OceanBase 開源的社群版本。我們蒐集到更多使用者的需求之後，基於他們的需求來打磨我們的易用性，讓 OceanBase 從能用變得更加好用。今天為止，OceanBase 在使用者體驗上坦率講我認為還有巨大的提升空間，我們在 OceanBase 4.x 版本也對使用者體驗層面做了大量重構和最佳化工作。
首先，4.x 版本安裝更加簡單，兩分鐘就能夠實現一鍵安裝部署。 去年一段時間我去了一趟矽谷，發現北美的軟體公司有一個特點，所有的使用者對軟體的需求都是自助服務，遇到問題使用者自己看文件，自己用工具來解決這個問題。國內使用者遇到問題，大家總是第一時間想到的是找人，最好是原廠交付，最好是原廠研發，這是兩個不一樣的特點。
OceanBase 開源出去之後，我們遇到了很多最初級的安裝部署問題，有兩類問題特別典型，第一類問題，找不到依賴包；第二類問題，很多元件配置起來特別複雜。 於是我們在內部定了一個目標，兩分鐘——吃一包泡麵喝一杯咖啡的時間，就能夠實現一鍵安裝部署 OceanBase demo 環境。 最後確實實現了這個目標，在去年年底內部的產品技術總結會上讓 HR 小姐姐，她是學文科的女生，透過看文件、點滑鼠，實現了兩分鐘一鍵部署。
其次，OceanBase 4.0 版本文件更加有效。 開源之後很多開發者就跟我講，你們 OceanBase 團隊挺用心的，你們的文件很多，但是，對不起，我看不懂，我找不到。我們態度很好，能力有限。在 4.x 版本對文件做了大規模重構，基於使用者旅程和使用者場景的思路來解決文件不好找和文件不好用的問題。
為了解決文件不好找的問題，我們的核心思路是兩個，第一個 20% 的文件解決最主要的 80% 的使用者場景問題；第二，要按照使用者的使用鏈路和使用者的旅程來重新組織文件，我們對怎麼了解 OceanBase，怎麼去使用，怎麼開發，怎麼部署，怎麼遷移，怎麼管理這些最基礎的開發者最常用的一些文件做了重新梳理。我自己非常有信心，可能過不了多久，經過我們對文件的不斷打磨，我們甚至能夠基於 OceanBase 的文件寫一些書，書名我都想好了《21 天學會 OceanBase》《7 天從入門到精通》。
為了解決文件不好找的問題，我換了一個思路，原先的文件告訴使用者我們有什麼，你來用吧，現在的思路是我們解決使用者什麼問題，以簡單的運維功能比如隔離節點為例，為什麼做這個事情，背後的原理是什麼，怎麼操作，操作有什麼風險，有沒有其它的使用建議等等，把這樣一些問題從使用者開發者使用的角度講清楚。
再次，4.x 版本的工具更加輕量級。 4.x 版本有一個運維管控工具 OCP，也是功能非常強大，看到 OCP 之後，開發者給我們提建議，OCP 功能非常強，但是，對不起，裡面大部分的功能我不需要。OCP 很強，但是它很重，每次安裝部署需要消耗特別多的資源，於是我們就乾脆推出了輕量級的 OCP Express，非常輕量簡單，佔用的資源非常少，可以做到開箱即用。
也就是說，當我們在前面兩分鐘完成一鍵安裝部署 OceanBase Demo 的時候，順便把 OCP Expresss 啟動起來，兩分鐘之後能夠開啟一個網頁來直接檢視OceanBase的內部執行狀態。未來，OCP Express 也是一個開源軟體，在六七月份也會把原始碼開放出去。
最後，4.x 版本的程式碼共建更加簡單。 原來社群版程式碼和企業版程式碼是兩個分支，內部定期把商業版程式碼合併到社群版本，這就帶來兩個問題。第一個問題，有延遲；第二個問題，開發者貢獻程式碼的鏈路比較長，需要在社群版本里面做程式碼的 review 再合併到商業版本里面，在商業版本里面做完測試，整個提交才算完成。
在 4.x 版本里面把社群版程式碼和商業版程式碼合併成一個分支，以後不管內部的開發者，還是外部的開發者，大家都基於同樣的分支，在同一個水平線上給 OceanBase 貢獻程式碼，解決之前的兩個問題。
經過 OceanBase 的單機分散式一體架構，在使用者體驗上的提升，在研發模式上的改變，我們確實也發現 OceanBase 的社群活躍度得到了大幅度提升。我們在去年 10 月份釋出 OceanBase 4.0 版本以來，不管是程式碼的提交頻率，還是程式碼貢獻者的數量都呈現直線上升。
大家可以看到，雖然程式碼貢獻者更多了，雖然 OceanBase 社群的問題變得更多了，但是我們 OceanBase 團隊投入了更大的人力在開發者社群，我們的響應時間和 PR 處理時間反而得到大幅度下降。
OceanBase 4.1 正式釋出，面向開發者的里程碑版本
今天我也借這個場合來發布 OceanBase 4.1 版本，大家都知道，OceanBase 4.0 版本是我們首次釋出的單機分散式一體化架構底座，4.1 版本在 4.0 版本的基礎之上進一步提升了效能，完善了功能，增強了穩定性，在核心能力上面在分散式事務和儲存都做了大量最佳化。
同時我們也推出了很多對開發者來講非常重磅級的功能，包括 GIS，包括 JSON，包括增強 LOB，包括租戶級的主備庫。大家可以看到， OceanBase 的 4.1 版本相比原來的 4.0 版本有很大的效能提升，我們在小規格的場景，相比 4.0 版本提升了 40%，在 OLAP 的場景提升了 15% 以上， 在 4.1 版本還實現了在開發者群體裡面呼聲很高的旁路匯入功能，透過旁路匯入， OceanBase 4.1 版本的資料匯入效能比 4.0 版本提升了 6 倍。
OceanBase 也在持續完善 MySQL 8.0 的相容，我們還實現了一個功能，MySQL Binlog，以後可以直接把 OceanBase 4.1 版本接入到下游的 MySQL 生態。OceanBase 4.1 兩分鐘吃一碗泡麵的時間完成一鍵安裝，希望作為開發者能夠到我們的社群跟我們一起來體驗 OceanBase 4.1 版本，並且給我們提更多的反饋建議。
OceanBase 的版本迭代速度非常快，但是因為 OceanBase 的願景是做一個像MySQL 流行的主流資料庫，我認為我們的迭代還不夠快，我們還會接下來調整我們的研發模式，每隔三個月就釋出一個大版本，從 Q2 開始釋出 4.2，Q3 的 4.3，Q4 的 4.4，明年 5.1、5.2、5.3、5.4。
4.2 版本，我們會把輕量級的 OCP Express 開源出去，同時也會把 ODC 開源出去，開發者可以透過 ODC 寫一些 SQL、儲存過程，做一些儲存過程的除錯，做一些資料脫敏等。4.2 版本還會做 Severless，支援單機版。
4.3 版本，我們會在 OLAP 能力上大幅度提升，做一個非常有用的列存功能，也會進一步增強在 OLTP 場景對複雜查詢的支援，還會做 DBA 應該很熟悉的資料庫快照功能，實現資料庫的閃回，這在很多時候對於 DBA 來講是“救命”的功能。我們還會發布黑屏的運維工具。OCP 是白屏的運維工具，功能很強大但是白屏不夠酷，我自己也是開發者，開發者會更想要一個黑屏的工具。
4.4 版本，OceanBase 會進一步完善 MySQL 8.0 的相容性，實現 MySQL 8.0 所有主流功能的相容，而且會進一步完善大寬表的 OLAP 線上分析能力。並且，我們會進一步把整個 OceanBase 內部的研發流程開發到 GitHub 裡面去，以後所有的外部開發者和內部人員都可以在 GitHub 裡做研發，直接看到內部的 Issue 和 Roadmap。
OceanBase 的迭代速度很快，在這個過程中我們得到了包括今天在場各位以及參加直播的各位開發者的大力支援，你們的反饋，你們的需求是 OceanBase 能夠快速進步的最大前提和動力。
在這裡，我也感謝每一位與 OceanBase 共同成長的開發者，因為有你們，OceanBase 的社群變得越來越活躍，越來越繁榮；因為有你們，OceanBase 的程式碼迭代的速度越來越快；因為有你們，OceanBase 的生態變得越來越完善，讓 OceanBase 的每個使用者能夠使用 OceanBase 更加省心，更加放心！
歡迎訪問 OceanBase 官網獲取更多資訊：https://www.oceanbase.com/