分享:作業幫在多雲環境下的高可用雙活架構最佳化實踐

OceanBase技術站發表於2023-04-13

歡迎訪問 OceanBase 官網獲取更多資訊:https://www.oceanbase.com/


本文來自OceanBase社群分享,僅限交流探討。作者介紹:劉強,就職於作業幫基礎架構 DBA 團隊,負責分散式資料庫的探索和使用,協同研發團隊在公司內部推進分散式資料庫在業務上的落地。

在作業幫剛上線OceanBase 4.0 時,我分享過作業幫的業務架構痛點。目前,作業幫是多雲架構(阿里雲、百度雲、騰訊雲),並同時使用 MySQL、Redis-Cluster、MongoDB、Elastisearch、TiDB 、OceanBase這幾款資料庫。出於高可用和降本需求,我們決定將更多 MySQL業務場景用 OceanBase 代替,本文將和大家分享具體原因,以及OceanBase 4.0 與 MySQL5.7 的對比資料。

高可用雙活架構方案升級需求

由於作業幫業務的多樣性和複雜性,我們對於分散式資料庫的使用需求主要基於以下幾個方面。

第一,在海量資料的情況下希望減少分庫分表的複雜度,並解決單機儲存瓶頸。

第二,對 I/O 密集型的 SQL 及 CPU 密集型的 SQL 來說,我們希望能夠提高響應速度,減少它在 MySQL 中對線上業務的影響。

第三,每個業務內部都需要業務人員頻繁查詢、錄取線上資料,並有相應的報表服務以供上級 Leader 檢視,而且大資料部門也會有報表需求接入線上資料,這對於線上 MySQL 來說難以支撐,在資料歸檔及彙總的情況下,也缺乏良好方案。

第四,由於MySQL的特性限制,我們需要基於一個外部的高可用元件來實現 MySQL 的高可用架構,在多雲環境下,網路環境相對複雜,這對高可用的穩定性提出了更高要求。如果部分業務的請求鏈路長或複雜,跨雲訪問會使業務相應耗時增加,影響使用者體驗。

因此,我們需要探索良好的雙活架構方案,初步方案是基於 MySQL ,並引入 DTS 來實現雙活架構。這種架構的複雜性及引入過程中 DTS 的異常或中斷,對於資料的一致性有很大的挑戰。同時在使用公有云的情況下,也希望能夠最大程度降低硬體的使用成本。

出於高可用和降本需求,我們決定將更多 MySQL 的業務場景替換為 OceanBase,並對OceanBase 和 MySQL5.7 進行了多方面的對比。

OceanBase 4.0 對比 MySQL5.7

1、效能對比

我們使用32C64GB的硬體規格分別對 OceanBase 和 MySQL 進行效能、CPU使用率、磁碟空間佔用的測試。

首先,從圖1可見,OceanBase效能明顯超過 MySQL。

1680761564

圖1 OceanBase 和 MySQL 的效能對比

其次,從圖2得知,在相同的併發環境下,OceanBase 的 CPU 使用率比 MySQL 低至少一倍以上。

1680761588

圖2 OceanBase 和 MySQL 的CPU使用率對比

另外,由於 OceanBase 資料壓縮及編碼的技術相較於 MySQL,能夠節約 2/3 以上的磁碟空間,因此,綜合上述三方面的對比結果,我們認為 OceanBase 能為作業幫的降本增效提供極大幫助。

在效能方面,我們還測試了DDL的執行速度。對於耗時較長的 DDL,MySQL 會有補充延時問題,需要我們引用額外的稽核工具來控制它的延遲,而 OceanBase 不存在延時問題。對於執行速度,MySQL 和 OceanBase 相差不大,這讓我們更加期待 OceanBase 4.1 的資料旁路匯入功能,可以將 DDL 的執行速度大幅提升。不過,我們也發現了一些語法相容性的問題,例如,OceanBase 對主鍵的操作語法不支援多個 DDL 合併執行,只能各自單獨執行。

2、架構對比

除了降本增效的需求,高可用也是我們在探索雙活架構中最看重的一方面。相較於 MySQL ,OceanBase 的高可用是有延伸的,不需要額外的高可用元件,這有利於解決資料不一致的問題。再加上OceanBase 的日誌具備多副本特性,能夠支援在多機房或多城市靈活部署。OceanBase 還便於作業幫實現一些單元化的需求,我們可以將業務單元內的 Leader 資料排程在某一個機房內,實現業務訪問的流量閉環,減少跨域讀寫。

3、字符集對比

最後,我們測試了字符集的支援程度。作業幫成立十年,我們使用 MySQL 的場景和字符集種類都比較多。OceanBase 4.0當前支援圖3 中顯示的幾種字符集,在4.1版本中增加了對拉丁字元的支援。後續我們也希望 OceanBase 能夠擴充套件字符集及校驗集的支援種類。

1680761622

圖3 OceanBase 4.0支援的字符集

以上就是作業幫對 OceanBase 和 MySQL的主要對比資料。在將更多業務場景切換至 OceanBase 的過程中,我們發現,在高可用雙活架構方案之外, OceanBase 4.0 的HTAP和資源隔離能力也為我們帶來許多意外之喜。

低成本與低延時,更好地降本增效

OceanBase 是一個具備 HTAP 能力的原生分散式資料庫,如何理解 HTAP?引用 OceanBase CTO 的一句話:HTAP 就是在高效能 OLTP 資料庫的基礎上擴充套件 OLAP 的能力,能很好支援實時分析。

在作業幫的業務場景中,我們 感受到 HTAP 的兩大顯著優勢:低成本和低延時。

低成本 :我們希望一套系統能同時支援OLTP場景和OLAP場景,相比兩套系統擁有更高的價效比。

低延時 :省去了繁瑣費時的ETL過程,降低延時,更好支援實時分析。

我們知道,在一套系統同時實現OLTP和OLAP的能力,其中一項挑戰是資源隔離,使業務之間互不影響。這便是OceanBase 帶給我們驚喜的地方。

對於核心業務來說,我們希望能夠使用物理資源管理,比如行存副本服務 OLTP,列存副本服務 OLAP,這兩種業務是不共享物理資源的,可以 做到絕對的隔離 。 OceanBase 可以增加額外的只讀副本,再透過配置 OBProxy 的 proxy_idc_name 實現讀寫分離

圖 4 為OceanBase 的物理資源隔離方案,基於只讀副本,再增加邏輯機房的情況下,在 OBProxy 中配置邏輯機房的位置。所有 OLAP 的 只讀流量都會錄入只讀副本中,避免與 OLTP 副爭搶資源。

1680761703

圖4 OceanBase 的物理資源隔離方案

對於成本敏感的邏輯資源隔離,OceanBase 在同一租戶內就可能實現 OLAP 和 OLTP 的物理資源共享,進而實現資源隔離。

對於邏輯隔離來說,首先 OceanBase 定義了一個大查詢,預設將執行時間超過 5 秒的請求判定為大查詢,當大查詢和短查詢同時爭搶 CPU 時,大查詢會被降低優先順序,待 CPU 資源充足時再被掛起,我們可以設定Large_query_worker_percentage 在同一租戶內,大查詢最多可以佔用30%的使用者執行緒數。在這種情況下,我們可以有效隔離大查詢對 OLTP 業務的影響,優先保證了 OLTP 業務的執行。

我們使用了一些線上業務資料和 SQL 來對比 MySQL 和 OceanBase。在作業幫的業務場景中,一個大業務部門的報表需要多級 Leader甚至上百人頻繁檢視,因此,即使是 OLAP 型別的業務,QPS也可以達到幾十甚至上百。我們使用了60個併發去壓測較複雜的 SQL,透過圖 5 可以看出,OceanBase 比 MySQL 最起碼快了一倍以上。OceanBase 的CPU使用率也基本控制在25%以下。

1680761728

圖5 OceanBase 與 MySQL執行SQL耗時

在60個併發執行 OLAP 業務的同時,我們也用256個併發去執行 Sysbench 任務,在 OLAP SQL 掃描量較大的情況下,我們可以看到它的耗時出現了一些抖動(見圖6)。

1680761741

圖6 併發量256 執行 Sysbench 任務

以上就是作業幫對OceanBase 4.0 的探索過程,目前,我們已經使用 OceanBase 半年了,總結出一些心得及建議,供大家參考。

使用 OceanBase 的心得和建議

首先,對於 OceanBase OCP 管理平臺有如下幾點建議。

• 建議增加 DDL 任務列表顯示,需要在每一個租戶下,可以看到有多少任務正在執行。

• 建議增加 SQL 稽核的功能,如果有業務正在從 MySQL 遷移,可以儘快保證業務上線,減少 DBA 工作,聚焦於對業務的落地。

• 在使用過程中我們發現,每個租戶下磁碟的使用量、資料庫的大小及表的大小,這一部分資料的監控是缺失的,需要完善。

• 在叢集中測試時,需要實時監控效能資料,比如 QPS 響應時間、CPU 的使用率等,建議在現有能力上再縮短延遲。

其次,對 OceanBase 叢集的一些問題,我們也給出反饋,希望得以提升。

• DDL無法實時檢視任務的進度百分比,希望後續可以增加該功能。

• 現在叢集升級時需要確保每個租戶的 leader 都聚集在單個 Zone 下,這樣對於每個叢集有上百個租戶來說,操作會比較繁瑣,希望可以最佳化。

• 對於大家在使用過程中需要注意大小寫敏感的引數設定,一旦建立後業務上線不合理則無法透過 SQL 語句進行修改,希望最佳化。

• 建議注意redo log 磁碟跟記憶體大小的配比,防止出現當磁碟空間還有富裕的時候,建立 redo log ,顯示磁碟空間不夠的問題。

最後,還有一些關於 OMS 資料遷移平臺的小建議:目前存在的問題有三個,一是在資料遷移過程中不支援新增 DB 的同步,對於資料歸檔或彙總的需求不友好;二是 OpenAPI 開放的太少,不利於我們內部平臺的改造;三是 ghc 的臨時表忽略寫法過於繁瑣,需要每一個 DB 都寫一個配。由於 OMS 資料遷移是測試中常用的功能,我們希望後續能有統一的配置,可以將 ghc 臨時表統一過濾掉。


歡迎訪問 OceanBase 官網獲取更多資訊:https://www.oceanbase.com/

相關文章