> **此前，由 OceanBase 社群主辦的 「分散式資料庫——企業降本增效新引擎」成都 Meetup已經落下帷幕，OceanBase 佈道師李曉東和周躍躍、美團技術專家何啟航、攜程資深 DBA 陳堯、阿里雲智慧計算平臺技術專家李劍、多點大資料部門資料架構師任偉在現場和大家進行了技術交流。本文整理自李曉東（花名：和順）的演講內容，介紹了資料庫系統架構發展史、資料庫系統如何助力企業降本增效。**

## 資料庫架構發展史

自20世紀60年代資料庫系統誕生以來，其架構在企業成本、技術、業務需求等因素的驅動下不斷變化。縱觀資料庫系統架構發展的這幾十年，我們可以把它分為三個階段（如圖1）。

- 第一階段：集中式+叢集資料庫架構。

- 第二階段：基於中介軟體+資料庫的分散式資料庫。

- 第三階段：基於多副本架構的原生分散式資料庫。

![截圖2022-08-26 11.47.30.png](https://intranetproxy.alipay.com/skylark/lark/0/2022/png/206564/1661493124255-b8d27b6c-2229-4111-97c8-429e8f56aa1d.png#clientId=ub5b9b5ce-7e06-4&crop=0&crop=0&crop=1&crop=1&from=ui&id=FrYCP&margin=%5Bobject%20Object%5D&name=%E6%88%AA%E5%B1%8F2022-08-26%2011.47.30.png&originHeight=1076&originWidth=1948&originalType=binary&ratio=1&rotation=0&showTitle=true&size=997194&status=done&style=none&taskId=u97d4011e-c078-479b-8942-0f61d124d9f&title=%E5%9B%BE1%20%E6%95%B0%E6%8D%AE%E5%BA%93%E6%9E%B6%E6%9E%84%E5%8F%91%E5%B1%95%E7%9A%84%E4%B8%89%E4%B8%AA%E9%98%B6%E6%AE%B5 "圖1 資料庫架構發展的三個階段")

**集中式+叢集資料庫的架構以 Oracle 為例**，其典型特點是：高昂的 License 費用、依賴於高階的硬體儲存。同時， Oracle 作為商業資料庫，由於政治、經濟等特殊原因可能會對使用該資料庫的別國企業帶來“卡脖子”風險。因此，越來越多的公司開始使用 MySQL 或 PostgreSQL 等基於中介軟體+資料庫的開源分散式環境。
**基於中介軟體+資料庫的分散式資料庫的一大作用**是，單機儲存容量透過中介軟體得到了釋放。但與此同時，會引入一些新的問題，如全域性唯一性、多表交易操作，此外，在企業沒有一定的運營平臺或運營能力時，做 DDL操作也會帶來一些挑戰。由於基於中介軟體+資料庫的分散式資料庫對業務並不透明，企業原有的資料庫架構無法直接切換到中介軟體+資料庫的架構下，導致架構遷移時需要對業務層進行改造，不僅增加了額外的改造成本，還可能影響業務正常執行。
**基於多副本架構的原生分散式資料庫**擁有多個副本，資料均勻的打散在多個副本中，且每個副本中都有完整的使用者資料，也帶來了靈活擴縮容到特點。企業無需依賴越用越貴的硬體儲存，也無需對業務層進行改造，增加成本與複雜性，避免了從架構、成本、業務等方面對企業不友好的問題。
無論是哪種資料庫的架構，企業在做選型時，其目的都離不開“降本增效”，希望能透過技術的提升，帶來效益的提升與成本的下降。那麼，一套資料庫系統可以從哪些方面實現“降本增效”呢？

## 資料庫助力企業降本增效的要點

企業的降本增效主要依賴於資料庫系統彈性擴縮容的能力、HTAP 能力、資料壓縮能力，以及原生分散式的高可用、高效能、高相容。透過上述能力結合完善的周邊工具來降低企業的人力、財力及時間成本，進而打造一個用起來簡單穩定、快速響應的資料庫系統。

1. **彈性擴縮容能力**

每種資料庫都有一定的擴縮容能力，以 OceanBase 為例，OceanBase 會將所有的使用者資料分散在副本中，保證每個副本都有一份完整的使用者資料。從圖2可見，該架構中有三個副本，每個副本中有 2 個 OBServer包含八個分割槽，藍色圓柱體代表分割槽的 Leader 。正常的讀寫都在Leader 上進行，當算力或儲存出現瓶頸時，可以給每個副本新增一個 OBServer，在新增之後，資料庫內部會進行自動負載均衡排程，可以將 P2 或 P6 分別調到新加的節點上（如圖3），不需要額外的修改路由策略。

![截圖2022-08-26 13.55.20.png](https://intranetproxy.alipay.com/skylark/lark/0/2022/png/206564/1661493338640-ba070473-d77b-42fe-9356-daaa24bead77.png#clientId=ub5b9b5ce-7e06-4&crop=0&crop=0&crop=1&crop=1&from=ui&id=u6cfc452a&margin=%5Bobject%20Object%5D&name=%E6%88%AA%E5%B1%8F2022-08-26%2013.55.20.png&originHeight=1146&originWidth=2182&originalType=binary&ratio=1&rotation=0&showTitle=true&size=938346&status=done&style=none&taskId=u985948ed-fecd-4943-9095-a5f66cf926a&title=%E5%9B%BE2%20OceanBase%E4%B8%89%E5%89%AF%E6%9C%AC%E6%9E%B6%E6%9E%84 "圖2 OceanBase三副本架構")
![截圖2022-08-26 14.02.47.png](https://intranetproxy.alipay.com/skylark/lark/0/2022/png/206564/1661493851170-387482b3-51d4-45a1-bad4-8bfd74ff2f99.png#clientId=ub5b9b5ce-7e06-4&crop=0&crop=0&crop=1&crop=1&from=ui&id=ub3461a12&margin=%5Bobject%20Object%5D&name=%E6%88%AA%E5%B1%8F2022-08-26%2014.02.47.png&originHeight=1144&originWidth=1314&originalType=binary&ratio=1&rotation=0&showTitle=true&size=695816&status=done&style=none&taskId=ucb27074d-e151-4d84-8462-7cd82d3b4ac&title=%E5%9B%BE3%C2%A0%20OceanBase%E8%B4%9F%E8%BD%BD%E5%9D%87%E8%A1%A1%E7%AD%96%E7%95%A5 "圖3  OceanBase負載均衡策略")

2. **HTAP 能力**

在 OceanBase 中有一種理念：真正的 HTAP 在一套引擎中既支援 AP 負載又支援 TP 負載。為了避免 AP 業務對 TP 業務造成影響，將 AP 和 TP 業務從資源側進行隔離。在一套系統中，如果同時包含了 AP 和 TP ，可以在一定程度上減少企業重複性建設的成本。在這裡也需要說明一點：由於 AP 系統在一些特定的場景下，有自己的使用場景，因此，HTAP 能力並不能完全替代 AP 的系統。

3. **資料壓縮能力**

LSM-Tree 會將離散且隨機的資料寫入請求中再轉化成批次的順序請求，可以減少隨機寫。一般 B-Tree 架構在寫作時，是一個實時刷盤的過程。而 LSM-Tree 是將實時寫轉換成一步寫。傳統的資料庫有壓縮功能，但在日常使用的過程中，你可能也會很少見到資料庫的壓縮功能，這是因為：

- 傳統的資料庫有定常塊。當你在做資料壓縮後，如果沒有達到定常塊就需要進行資料補齊。

- 原地更新。原地更新的成本較高。

- 傳統的資料庫是實時寫入的。在 LSM-Tree 架構中，實時寫入且需要壓縮的時候，對 CPU 資源的消耗較高。

![截圖2022-08-26 14.48.46.png](https://intranetproxy.alipay.com/skylark/lark/0/2022/png/206564/1661496541354-15df71ca-7df9-4e85-835d-88cc257fb8fa.png#clientId=ub0d1bde2-b2e3-4&crop=0.0396&crop=0&crop=1&crop=1&from=ui&height=788&id=u4bac29c5&margin=%5Bobject%20Object%5D&name=%E6%88%AA%E5%B1%8F2022-08-26%2014.48.46.png&originHeight=820&originWidth=1170&originalType=binary&ratio=1&rotation=0&showTitle=true&size=504268&status=done&style=none&taskId=u9b53b433-2094-4179-ab9f-0d22eb47c1a&title=%E5%9B%BE4%20%E5%9F%BA%E4%BA%8E%20LSM%20Tree%20%E6%9E%B6%E6%9E%84%E7%82%B9%E5%8E%8B%E7%BC%A9%E6%8A%80%E6%9C%AF&width=1124 "圖4 基於 LSM Tree 架構點壓縮技術")

OceanBase 資料庫的儲存引擎基於 LSM Tree 架構，將資料分為靜態基線資料（放在 SSTable 中）和動態增量資料（放在 MemTable 中)兩部分，其中 SSTable 是隻讀的，一旦生成就不再被修改，儲存於磁碟；MemTable 支援讀寫，儲存於記憶體。資料庫 DML 操作插入、更新、刪除等首先寫入 MemTable，等到 MemTable 達到一定大小時轉儲到磁碟成為 SSTable。在進行查詢時，需要分別對 SSTable 和 MemTable 進行查詢，並將查詢結果進行歸併，返回給 SQL 層歸併後的查詢結果。同時在記憶體實現了 Block Cache 和 Row cache，來避免對基線資料的隨機讀。

圖 5 是某使用者生產環境真實的資料，從圖中可以看出從其他資料庫遷移到 OceanBase 後，依賴良好的壓縮率，儲存成本收益顯著。這裡很多人就會好奇，為什麼 OceanBase 及 LSM-Tree 架構可以開啟壓縮功能？在 OceanBase 中所有的壓縮都是在合併階段進行的。在合併 SSTable 靜態資料時，由於在OceanBase 的SSTable 粒度更小：由定長的宏塊組成大小為2MB，宏塊的內部是由若干個變長的微塊組成，變長也是很好壓縮的，而且在不影響效能的同時做到高壓縮比。在OceanBase 現有的業務中，當客戶將 MySQL 遷移至 OceanBase 後，遷移前在 MySQL 中資料量為 1TB，遷移後可能只有 300～400 GB，壓縮到原資料量1/3或1/4左右。

![截圖2022-08-26 14.56.48.png](https://intranetproxy.alipay.com/skylark/lark/0/2022/png/206564/1661497138627-b3ec39ba-e12f-41a8-930e-7ec446b9aaa0.png#clientId=ub0d1bde2-b2e3-4&crop=0&crop=0&crop=1&crop=1&from=ui&id=u40945a4d&margin=%5Bobject%20Object%5D&name=%E6%88%AA%E5%B1%8F2022-08-26%2014.56.48.png&originHeight=776&originWidth=1818&originalType=binary&ratio=1&rotation=0&showTitle=true&size=638830&status=done&style=none&taskId=u99369b34-7abf-4f98-8aa5-28ef25dedcd&title=%E5%9B%BE5%20%E6%9F%90%E7%94%A8%E6%88%B7%E9%87%87%E7%94%A8OceanBase%20%E6%95%B0%E6%8D%AE%E5%BA%93%E7%9A%84%E5%8E%8B%E7%BC%A9%E7%8E%87%E5%89%8D%E5%90%8E%E5%AF%B9%E6%AF%94 "圖5 某使用者採用OceanBase 資料庫的壓縮率前後對比")

3. **原生分散式的高可用、高效能、高相容能力**

每一種資料庫都提供了高可用能力，而OceanBase 是基於 Paxos 協議來實現三副本部署模式，原生資料自帶強一致性，具備高可用，達到最高階別的容災恢復能力的要求：RTO小於30秒，RTO等於0。在 OceanBase 中有很多部署模式，可以提供不同級別的容災，比如：單機故障、機房級別融災、城市級故障，可以保障自動故障切換，不停服，不丟資料。
當你有一套資料庫系統需要遷移到基於多副本架構的原生分散式資料庫如 OceanBase 時，你會需要了解 OceanBase 的相容程度如何？以 MySQL 為例，OceanBase 社群版目前可以相容 MySQL5.6、5.7絕大多數語法，也可以相容  MySQL 8.0新特性 CTE。在我們使用 MySQL 時常用的工具有 Navicat、dbeaver、datax、canal等，這些第三方工具做到了與OceanBase 良好適配。正因具備高相容性的因素，你就可以平滑地從 MySQL 遷移到 OceanBase。

4. **完善的周邊工具**

一款資料庫系統具備多種能力後，還需於完善的生態工具配合，才能助力企業降本增效。對於 OceanBase 而言，其主要的生態工具有：OceanBase 資料庫遷移服務（OMS）、OceanBase 運維管理平臺（OCP）、OceanBase 開發者工具（ODC）。

- **OMS**是 OceanBase 提供的一站式資料傳輸產品，支援多種關係型資料庫、大資料（OLAP）及訊息佇列等資料終端與 OceanBase 之間的資料複製，是一種集資料遷移、實時資料同步和增量資料訂閱於一體的資料傳輸服務。 
- **OCP**是一款為 OceanBase 資料庫叢集量身打造的企業級管理平臺，相容 OceanBase 所有主流版本。OCP 提供對 OceanBase 叢集的圖形化管理能力，包括資料庫元件及相關資源的全生命週期管理、監控告警、效能診斷、故障恢復、備份恢復等，協助客戶更加高效地管理 OceanBase 資料庫，降低企業的IT運維成本和使用者的學習成本。
- **ODC**作為 OceanBase 資料庫量身打造的企業級資料庫開發平臺，幫助企業安全、高效地使用資料庫。還可以透過 ODC 建立和管理資料庫中的表、檢視等 10 餘種資料庫物件。基於 WebSQL，ODC 提供了 SQL 視窗和匿名塊視窗作為資料庫開發者開發和診斷 SQL 和 PL/SQL 的工作區。你還可以為指定角色分配對應資源及該資源的訪問許可權，企業內不同角色間的開發協作亦會變得簡單可控。

總的來說，沒有完美的資料庫架構，不同架構的資料庫對企業降本增效的效果不同，企業使用者選擇適合自己的架構最重要。上述內容其實都跟我們企業降本增效息息相關，做好其中任何一點，都可以幫助企業降低成本，提升效率。未來，在 OceanBase 4.0版本，還會有更多的功能，將助力企業進一步實現降本增效的目的，簡單列舉一些：

1. **AP 能力進一步提升。**
- 4.1 版本支援向量化及部分下壓到儲存層。
- 在向量化執行的過程中也可以對執行的列進行解碼，降低了投影的開銷。
2. **儲存壓縮率更高。**
- 在通用壓縮基礎上，開放資料編碼功能（ Encoding），行列混合儲存。微塊會按列對資料進行編碼，編碼後的定長資料儲存在微塊內部的列存區，儲存空間進一步壓縮。
3. **靈活的高可用和容災能力。**
- 主備叢集為客戶提供更加靈活的高可用和容災能力。主叢集透過向備叢集,傳送事務日誌的方式實現資料同步，從而確保生產叢集能夠在遇到資料損壞、災難等情況下仍然可以快速恢復業務。
4. **資源隔離更加徹底和靈活。**
- 在已有 CPU、記憶體隔離的基礎上，支援 I/O 隔離。
- 支援使用者級別資源（CPU）隔離。
5. **效能進一步最佳化和提升。**
- 單日誌流，增加分割槽數上限，減少分割槽帶來的額外開銷。
6. **更加靈活。**
- 支援主鍵變更等涉及資料騰挪的 Online DDL。
7. **遷移和使用更加簡單。**
- 在 MySQL 模式下，支援儲存過程，在進行業務遷移時不需要對儲存過程進行改造，遷移和使用更加方便。

以上就是我的分享，希望能給你帶來參考價值。另外，對於降本增效和有關 OceanBase 的疑問，歡迎在釘釘群（群號：33254054）和我探討。

![](https://img.alicdn.com/imgextra/i3/O1CN01s1A7li21lxXIHdD46_!!6000000007026-0-tps-2248-7912.jpg)

資料庫系統助力企業降本增效的技術要點｜Meetup 回顧與預告

相關文章