文 / OceanBase解決方案架構師 韓冰
該企業成立於 1999 年，是國內領先的財稅資訊化綜合服務提供商，主要為稅務機關提供稅務系統開發與運維，為納稅企業和財稅中介提供網際網路財稅綜合服務。
經過多年發展，為了更好地支撐使用者業務需求和資料需求，該企業發展出規模龐大的 IT 基礎設施規模，擁有公有云、私有云等多樣基礎設施，軟體層面同樣具有很高的複雜度。這無疑給企業在成本、運維、開發效率上帶來了種種挑戰。
作為一家重視技術，希望透過技術給社會帶來美好改變的公司，該企業一直在緊密關注、密切跟蹤前沿技術的發展趨勢。透過不斷地調查研究新技術並引入新技術，不僅完成了對業務的賦能，還同時實現了各項效率的提升和成本的降低。本文，僅就資料庫這一維度，分享其發展歷程、選型思考以及收穫成效。
從集中式到真正的分散式
如下圖所示，資料庫從集中式到真正的分散式，經歷了四個階段的發展歷程。在企業發展初期，業務規模較小時，集中式架構的資料庫產品就可以滿足業務發展需求，MySQL 成為業務的首選，透過 RAID 和主備叢集就可以比較好地滿足容災需求。
但隨著業務量的大幅增長，給資料庫帶來大量流量和大量資料支撐的需求，此時，集中式資料庫已經無法很好地滿足業務需要。 為了滿足業務需求，企業不得不對資料庫進行拆分，以分庫分表方式的分散式架構方案尤為流行。 其中，主流的分庫分表方案如下：
- 方案一：嵌入業務的分散式架構，應用嵌入分散式 SDK，在業務層做分庫分表處理；
- 方案二：中介軟體的分散式架構，透過引入分庫分表中介軟體，集中處理分庫分表。
使用分庫分表的方式可以快速增加資料庫的服務和儲存容量，但同時也對業務和運維工作提出了新的要求和挑戰。比如：
- 應用分散式改造， 無論使用嵌入業務或者中介軟體的分散式架構，都需要業務 SQL 為了適應分散式進行改造，並且因為底層的節點都是各自獨立的，對於索引、複雜事物、和關聯業務都有比較多的限制；
- 節點無法按需擴充套件， 因為使用比較固定的分庫分表規則，同時考慮擴容需求，分庫分表的方式一般要求擴容都是等比擴容，即擴容一次就要擴容到原來資源配置的一倍，靈活度比較低；同時，因為各自例項獨立，導致擴容後有大量的節點間資料遷移，對服務質量有比較大的影響；
- 初始節點數多， 因為以上兩個原因的限制，為了遮蔽掉改造和擴容對業務以及資料傾斜的影響，一般都會一次規劃到位，導致初始節點數量比較多，整體資源利用水位比較低。
分庫分表的分散式架構在承載業務發展的同時，也暴露出各種弊端，這也證明了這種方案只是分散式架構的中間過渡方案。之後，新資料模式的分散式架構，即原生的分散式架構出現，很好地解決了分庫分表的分散式架構的問題。原生分散式架構能夠提供更好的服務能力，也是更好地解決當前業務階段降本提效訴求的一種更有效的手段。
選擇進步技術收穫明顯成效
明確採用原生分散式架構的資料庫後，企業開始從眾多產品中選型能夠替換分庫分表中介軟體的資料庫產品，考慮到未來的長遠發展以及與業務契合度，最終選定 OceanBase，並迅速開展遷移工作。
▋ 資源整合，多套例項收歸一套叢集
原有分庫分表架構下，各個物理表分別由不同的 MySQL 例項提供服務。因為業務高峰時段資料傾斜的存在，必然導致不同 MySQL 例項在不同時間段複雜不均衡。為了保證業務平穩，需要為每個 MySQL 配置滿足業務安全的最大配置規格，這必然導致資源使用上的浪費。
OceanBase 可以透過使用分割槽表方式將原來的分庫分表的物理表匯聚到一個物理表，同時還可以保留原來的對映關係。
透過將物理分割槽合理分佈到多個計算節點上，充分使用所有計算資源，在保證資源使用在合理的水位基礎上，將原來多個 MySQL 例項的計算資源整合到一個 OceanBase 叢集中。透過 OceanBase 提供的自動均衡能力，保證每個節點的資源使用相對平均，保證資源的充分利用。
企業將原來配置了 16 個 8C16G 資源規格的 MySQL 遷移到 OceanBase，僅使用 32C 雙機房的 OceanBase 叢集就能穩定支撐業務服務質量，計算資源節約顯著。
▋ 高階壓縮技術，節省 85% 儲存空間
經過二十餘年的發展，企業有著龐大的資料存量，一直在尋找一款既能節省資料儲存成本，還能保有原效能甚至提升效能的資料庫。經瞭解和調研，得知 OceanBase 使用 LSM-Tree 儲存引擎，採用密實儲存消除了儲存空洞，在儲存上使用行列混存的方式，同時透過對列資料進行編碼，並且對編碼後的資料最終提供了高階壓縮的能力。
使用該高階壓縮能力，儲存壓縮效果非常明顯。比如，某個業務原來的資料量在 原資料庫大約上有 20T，將這些資料遷移到 OceanBase 後，只佔用了 3T 的資料儲存，相當於節省了 85% 的儲存空間。
▋ HTAP 讓一份資料既能事務處理又能實時分析
因為原資料底層儲存實際分佈在不同的 MySQL 例項上，如果想在全庫級別進行復雜查詢，需要將資料彙集到一處，且需要多條資料遷移鏈路和匯聚分析庫的配置。如此一來，會導致兩個問題：
- 問題一，資料時效性。 因為使用資料同步鏈路進行資料遷移，分庫分表中介軟體後端實際的 MySQL 例項越多，需要的資料同步鏈路就越多。在所有鏈路正常同步的情況下，資料延遲取決於同步的速度。如果任何一條同步鏈路發生延遲都會產生木桶效應，資料的最大延遲取決於最慢鏈路的速度。
- 問題二，成本上漲。 當前架構下的成本分列為兩項，一項是同步鏈路的成本，這個成本由同步的鏈路數量和資料的決定；另一項是匯聚分析庫的成本，這個成本由資源配置和資料量決定。
大資料時代，實時資料分析必不可少，作為國內領先的財稅資訊化綜合服務提供商更是如此。然而，以上資料時效性和成本上漲的問題，一直困擾著企業。
OceanBase 可以在一份資料上進行 HTAP 的處理，不需要資料同步和新採購匯聚分析庫。同時，企業可以設定分析業務使用的資源配置或者調整主可用區獨立一份資源給到分析業務使用。透過以上手段保證不會因為分析 AP 業務佔用過多資源，導致線上 TP 業務的不穩定性。
攜手共進，期待遷移便利性更上一層樓
如下圖所示，為遷移過程示意圖。
- 正向遷移過程： 使用 OMS 工具遷移分庫分表中介軟體後端實際的 MySQL，如此，分庫分表中介軟體後端的每一個 MySQL 需要單獨一條鏈路進行資料遷移到 OceanBase；在遷移之前，需要根據分庫分表中介軟體的表結果先修改 DDL 在 OceanBase 建立表結構。
- 反向遷移過程： 在業務切換到 OceanBase 之後，業務寫入的資料需要從 OceanBase 將增量資料透過 OMS 工具寫入到分庫分表中介軟體裡。
透過上述遷移過程可以看到，雖然整體使用過程在功能和效率上都有所保證，但是需要很多獨立的 OMS 鏈路，整個流程的配置和維護複雜度都比較高。
作為 OceanBase 的使用者和受益者，為了讓更多業務享受分散式升級帶來的降本提效收益，從業務角度出發，OceanBase 遷移的便利性改進，將是最期待的改進點：
- 自動結構遷移。 因為分庫分表中介軟體的建表 DDL 遷移到 OceanBase 的修改過程，規則是比較固定的，後續將分庫分表中介軟體的結構遷移自動完成將帶來很大便利性；
- 統一的正向資料遷移。 在正向遷移過程中需要根據實際的 MySQL 數量配置 OMS 實際遷移鏈路，包括後續的資料校驗和切換都需要單獨操作，將這個過程統一化將大大增強操作便利性。更進一步，在將正向的資料遷移過程統一後，可以方便地增加反向遷移的鏈路。