第十四期 AMA，掘金團隊請來了螞蟻金服 OceanBase 團隊的技術專家-- OB慶濤做了為期三天的 Ask Me Anything (AMA) 活動（活動已結束）。
我們在此精選了一些來自使用者的提問及慶濤的回答。
關於慶濤
下面內容來自他的自白
大家好，我是螞蟻金服 OceanBase 團隊的技術專家梅慶（花名：慶濤）。目前主要負責 OceanBase 資料庫技術和解決方案的對外推廣，在阿里工作了 8 年多，目前工作地點在杭州
社群小夥伴精選提問--純技術
請問 ob 關注的是速度還是可靠性呢？ ─ @Lanwy
請問 ob 關注的是速度還是可靠性呢？到底是快速處理大量任務重要，還是保證遇到災難時仍能夠提供服務重要？資料庫優化重點是在讀還是寫呢？問題有些多，期待您的回覆，謝謝
感謝您對OB的關注。 OB的定位是一款通用的分散式的關係型資料庫。對於大部分使用者而言這是一個新的資料庫，你說的哪個重要在使用者而言都很重要。OB的特點如下：
- 可用性：OB的多副本使用paxos協議同步資料和自動選舉這個設計實現了部分機器節點故障時只有部分資料短暫不可讀寫，並能迅速內部切換恢復訪問（時間在30s以內，俗稱RTO），恢復後對業務而言還沒有資料丟失（俗稱RPO=0）。
- 可靠性：OB目前內部版本主要有1.x和2.0. 其中1.x版本的OB叢集自上線後就沒有再停服過。這得益於OB的擴充套件性很方便，可以線上擴容/縮容/更換伺服器。效能方面是個逐步改進的結果，業務早期會根據資料庫能力適當分配壓力到OB上。如今螞蟻金服很多業務（核心和非核心的）都執行在OB上，並經歷多次雙十一考驗。
- 效能：OB的架構是基於LSM-Tree（Log-Structured Merging Tree)，資料儲存格式是SSTable（Sorted String Table）。應用寫表的一行資料時，OB會將該行資料所在塊讀入記憶體的Block cache中（保持只讀），然後在另外一塊記憶體中記錄該行的修改的資料（增量資料，即memtable）。同一行資料多次修改的時候，相應的增量會以類似連結串列的結構串起來。這部分增量資料會一直在記憶體裡不落盤。在事務提交的時候，事務日誌時會即時落盤並同時發往該資料其他副本所在節點落盤。資料讀的時候通常會將block cache中的基線資料（sstable）跟對應的增量資料（memtable）合併就是業務需要的資料。OB會有機制去保證同一行資料的增量鏈條不會太長（即minor compaction事件）以保證讀效能不會受鏈條長度影響。所以，OB的這種“讀寫分離”的設計，天然對寫友好，對讀也友好。OB後期的效能優化重點在通過強化優化器能力，讓複雜的SQL的讀效能儘可能的更好。
再補充幾點。MySQL常用sql在OB裡都相容，oracle部分sql也相容。目前內部在全力研發相容oracle更多功能。明年很快就會推出對儲存過程，遊標和包，統計分析函式等高階功能的相容。
處理的資料量級不大的情況下，OB相較別的資料庫它的優勢在哪？ -@Hodmin
OceanBase作為一個分散式資料庫，在保持資料的一致性這塊是如何處理的？還有一個問題，看你描述的都是千萬級別的業務，對於小公司，處理的資料量級不大的情況下，OB相較別的資料庫它的優勢在哪呢？
1.OceanBase是多副本(N=3,5,7...)。副本之間的資料同步是通過複製事務日誌(redo)並應用實現。以三副本架構為例，每個表的三副本角色有一個leader副本和兩個follower副本。預設只有leader提供寫入和讀取。當事務提交的時候關鍵一步是事務日誌持久化。不僅要持久化到本機硬碟還要持久化到其他follower副本所在主機硬碟。但又不必等待所有成員落盤成功。每個副本把事務日誌落盤成功就有個類似投票的動作。投票決議的協議是multi-paxos.只要leader副本收到一半以上成員投票確認持久化事務日誌成功就會返回繼續走完commit.應答應用。另外一個成員只是持久化略微晚了,不是可以不成功。所以這裡的三副本跟傳統一主兩備並不完全相同，在不考慮應用redo延時的情況下，這裡三副本是絕對強一致的。
2.業務規模不特別大情況下，如果買了oracle，說明這資料對業務還是很重要的。那OceanBase就是一個新的選擇項，成本比oracle低，相容oracle(目前還不是完全相容，取決於業務怎麼用). 相比Oracle，OceanBase的高可用和容災是自動的，不需要dba及時線上處理。OceanBase可以線上擴容，縮容，更換機器。這些運維操帶給dba的工作量很少，對業務的影響也相對小一些。OceanBase就是為故障設計的，所以自身"反脆弱性"很強，對運維人員要求也就低一些。 當然前期會有一定學習成本。此外，如果有擴充套件性需求，容災或多活需求，那不需要再單獨去設計新方案了，OceanBase擅長做這個。
相對於pgsql說，OceanBase具備哪些優勢呢？ ─ @古大官人
大佬好，先給大佬遞茶。作為阿里雲的客戶，我們目前在使用RDS for pgsql,相對於pgsql說，OceanBase具備哪些優勢呢？
PG我不是很懂。我就說OB吧，然後你對比一下。
OceanBase是分散式資料庫，體現在下面幾點上：
- 支援分割槽表。不同分割槽可以分佈在不同機器上。理論上解決了單庫單表的空間瓶頸和效能瓶頸。分割槽策略參照oracle做，支援二級分割槽和全域性索引。（個別功能點還在完善）。
- 高可用最小粒度是分割槽。每個分割槽有多副本，其中一個leader提供讀寫。同一個分割槽的多副本是分佈在不同可用區的機器內，不同表的分割槽可以混布在同一個機器內。換句話說每個機器內既有leader副本又有follower副本。沒有單純說哪個機器是主或是備。這個好處就是限制少，機器利用率充分。真正的分散式資料庫都可以做到這個程度。
- 資料負載均衡時遷移的最小粒度也是分割槽。通過調整leader副本的分佈來改變各個機器的壓力。不需要運維做資料遷移等事情。自然也沒有資料不一致擔憂。真正的分散式資料庫也可以做到這點。
- 完全的分散式架構下，不同表的leader分佈很散，對業務來說並不友好。業務上表之間是有聯絡的（表連線），業務也希望就近訪問資料，以及不希望跨節點取資料。所以OB提供對分割槽分佈規則的控制策略。這種策略主要是分割槽親和性設定，或者預設優先locality設定。這個用到極致就是單元化架構。
- OB的彈性伸縮能力很強，可以線上做，線上替換伺服器。不用擔心高可用問題和資料一致性問題。
此外，OB對Oracle的相容性有了，還沒有做到PG那個水平，只是時間問題。
大佬，再問個問題，OceanBase主打分散式，這個分散式具體是如何實現的呢？在前面的提問中有看到是保持一致性的工作原理，但是針對分散式實現原理這塊，能否做一個大概的介紹，方便我們瞭解OceanBase粗略的工作原理？
前面回答你的那個“分割槽”對理解OB的分散式很重要。詳細一點的你可以看公眾號裡技術文章，或者直接參加週末我們在上海的線下活動。瞭解分散式資料庫產品可以從下面幾點入手：資料模型，多副本技術，拆分技術，高可用技術，事務，彈性擴充套件能力等。
不知道 ob 和 scylladb、tidb 相比如何呢？ ─ @楚陽
不知道 ob 和 scylladb、tidb 相比如何呢
Scylladb瞭解不多，似乎是NoSql資料庫。tidb是架構最接近OB的資料庫，不過二者定位和場景也不完全一樣，功能上也有一些區別。OB定位是一款通用的分散式關係型資料庫，完全自主研發，不依賴任開源元件或產品，同時儘可能的規避其他公司專利。效能方面可以看公眾號裡文章，或者看這個 m.aliyun.com/bbs/read/58…
OB 是如何實現智慧運維？─ @吃提子不吐葡萄籽
終於來了個運維大佬，我之前讀過你們的技術文章，某篇文章提到過智慧運維的概念，可以具體地講一講 OB 是如何實現智慧運維的嗎？
【智慧運維】是理想，可以無限接近。現實中更多體現為自動化運維，彼此自動化程度上不一樣。我這裡就說【自動化運維】方面的。
運維最基礎的功能就是監控和告警。OB內部效能指標非常豐富（不比Oracle的效能指標少），這為運維提供了很豐富的素材（資訊）。告警的目的是提前發現異常，【異常】的定義取決於業務要求和運維人員經驗。以前是靠為監控指標定義範圍或者波動範圍去識別異常，近幾年可以通過機器學習去識別以查。 個人認為理論上不會有一個統一的標準能適應所有的業務，機器學習也是一門不確定性技術。所以【漏報】和【誤報】永遠是運維人員的痛。
資料庫告警問題如果是資源相關，有兩個處理思路，都可以自動化做。
一是優化SQL，降低SQL對CPU/記憶體的消耗。自動獲取DB執行的所有SQL，並及時分析其執行計劃，應用DBA的經驗和相關執行時效能資料，程式自動初步判斷SQL是否有效能問題，並給出初步的索引優化建議，這個是SQL自動優化的方向。準確率不會太高，但是隻要高於絕大部分研發人員水平，在資料庫規模很大的公司內，這個是自動化診斷對研發和運維都是很有意義的。OB的所有SQL都可以計入審計，有詳細的執行時效能資料。這是源材料。怎麼加工發揮就是運維產品的水平了。
二是資源擴容或遷移，提升資料庫享用的資源或者資料庫遷移到壓力很小的主機上。雲資料庫就是在資源管理方面做的比較好。RDS的mysql和sqlserver都是這個思路。不過這個資料遷移是靠運維產品用資料庫自身的備份恢復技術去做（搭建級聯備庫，然後切換應用的資料庫連線等）。OB在這方面做的自動化程度非常高。OB是支援多租戶管理。資源有叢集和租戶兩個維度。租戶是提供給業務的例項。租戶資源不足就對租戶擴容，一個命令瞬間完成，前提是叢集資源有餘量；叢集資源不足就加機器，也是一個命令。擴容命令結束後會引起租戶以及內部Unit的負載均衡（詳情請關注OB微信公眾號，看歷史文章【負載均衡】）。均衡操作會有資料重分佈動作，都是OB內部非同步完成，不依賴外部運維產品，不用擔心資料不一致，不用擔心中間出現異常或可用性故障等。當然，決策是否擴容目前還是運維人員判斷的。原因也一樣，沒有一個統一的標準適合所有的業務場景，還是人把關比較靠譜。
【監控】-【告警】-【處理】-【反饋】。當形成閉環後，這個自動化的運維產品的價值就體現了。反饋就是能跟蹤SQL在【處理】之後的改進情況。這還是要依賴資料庫的效能指標和SQL的執行時資訊等。這個反饋也是對開發做的處理的正向反饋，讓他知道應用的效能狀況，優化狀況，知道哪裡做的好哪裡做的不好，資料庫開發設計方面的能力也得到提升。
社群小夥伴精選提問--非技術直接相關類
只是寫業務程式碼的程式設計師該如何去學習分散式系統方面的知識？ ─ @Chatc鯨魚
大佬好，平時只是寫業務程式碼的程式設計師該如何去學習分散式系統方面的知識技能呢
先了解一些理論基礎，推薦看書《資料密集型應用系統設計 》。英文ok的話看原版。 介紹 book.douban.com/subject/303…