掘金 AMA：聽螞蟻金服 OceanBase 團隊的技術專家-- 慶濤聊數據庫那些事

第十四期 AMA，掘金團隊請來了螞蟻金服 OceanBase 團隊的技術專家-- OB慶濤作了爲期三天的 Ask Me Anything (AMA) 活動（活動已結束）。

咱們在此精選了一些來自用戶的提問及慶濤的回答。

關於慶濤

下面內容來自他的自白

你們好，我是螞蟻金服 OceanBase 團隊的技術專家梅慶（花名：慶濤）。目前主要負責 OceanBase 數據庫技術和解決方案的對外推廣，在阿里工做了 8 年多，目前工做地點在杭州

社區小夥伴精選提問--純技術

請問 ob 關注的是速度仍是可靠性呢？ ─ @Lanwy

請問 ob 關注的是速度仍是可靠性呢？究竟是快速處理大量任務重要，仍是保證遇到災難時仍可以提供服務重要？數據庫優化重點是在讀仍是寫呢？問題有些多，期待您的回覆，謝謝

感謝您對OB的關注。 OB的定位是一款通用的分佈式的關係型數據庫。對於大部分用戶而言這是一個新的數據庫，你說的哪一個重要在用戶而言都很重要。OB的特色以下：

1. 可用性：OB的多副本使用paxos協議同步數據和自動選舉這個設計實現了部分機器節點故障時只有部分數據短暫不可讀寫，並能迅速內部切換恢復訪問（時間在30s之內，俗稱RTO），恢復後對業務而言尚未數據丟失（俗稱RPO=0）。
2. 可靠性：OB目前內部版本主要有1.x和2.0. 其中1.x版本的OB集羣自上線後就沒有再停服過。這得益於OB的擴展性很方便，能夠在線擴容/縮容/更換服務器。性能方面是個逐步改進的結果，業務早期會根據數據庫能力適當分配壓力到OB上。現在螞蟻金服不少業務（核心和非核心的）都運行在OB上，並經歷屢次雙十一考驗。
3. 性能：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是分佈式數據庫，體如今下面幾點上：

1. 支持分區表。不一樣分區能夠分佈在不一樣機器上。理論上解決了單庫單表的空間瓶頸和性能瓶頸。分區策略參照oracle作，支持二級分區和全局索引。（個別功能點還在完善）。
2. 高可用最小粒度是分區。每一個分區有多副本，其中一個leader提供讀寫。同一個分區的多副本是分佈在不一樣可用區的機器內，不一樣表的分區能夠混布在同一個機器內。換句話說每一個機器內既有leader副本又有follower副本。沒有單純說哪一個機器是主或是備。這個好處就是限制少，機器利用率充分。真正的分佈式數據庫均可以作到這個程度。
3. 數據負載均衡時遷移的最小粒度也是分區。經過調整leader副本的分佈來改變各個機器的壓力。不須要運維作數據遷移等事情。天然也沒有數據不一致擔心。真正的分佈式數據庫也能夠作到這點。
4. 徹底的分佈式架構下，不一樣表的leader分佈很散，對業務來講並不友好。業務上表之間是有聯繫的（錶鏈接），業務也但願就近訪問數據，以及不但願跨節點取數據。因此OB提供對分區分佈規則的控制策略。這種策略主要是分區親和性設置，或者默認優先locality設置。這個用到極致就是單元化架構。
5. 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…