某遊戲公司基於OceanBase 4.0的運營分析AP實踐

業務痛點及選型背景

在遊戲業務發展階段早期，我們考慮到迭代迅速、運維簡單、架構輕量，使後端資料庫均採用了AWS上的MySQL單例項，承擔遊戲執行、運營分析等各項業務。

運營分析業務主要面向公司內部員工，用於觀察生產業務運營情況、追蹤異常使用者資料，針對遊戲日誌進行分析計算，處理生成BI報表。該業務幾乎24小時都有資料寫入，大部分資料量集中在幾張日誌表、流水錶中，且21:00-24:00點的資料量會是其他時段的1-2倍。隨著業務的發展，我們發現，運營分析業務使用MySQL資料庫的弊端越來越凸顯。

弊端1：效能瓶頸。隨著多張表一天產生的資料量由百萬級增長到億級，原來的MySQL例項在讀場景的效能出現明顯下滑，例如，針對單天的統計計算從原來的10s延遲至300+s才能出結果；在寫場景下，由於80%以上的資料集中在幾張日誌表、流水錶中，且24小時不間斷寫，造成寫熱點、資料入庫慢等問題。

弊端2：分析瓶頸。寫熱點場景下，資料入庫慢，疊加讀效能下滑的影響，導致運營分析的資料一直有延遲，僅能獲取準實時報表。

弊端3：擴充套件瓶頸。資料量突增的情況下，出現上述效能、分析瓶頸後，暫時只能升級MySQL配置，但隨著業務的進一步擴充套件，升無可升。同時，由於MySQL的侷限性，難以採用線性擴充套件方案，即使想用分庫分表，前期的應用適配改造及後期的運維工作量也很大，無法短時間解決問題。

基於上述三個弊端，我們在制定解決方案時想到了關注已久的原生分散式資料庫 OceanBase。早在OceanBase開源（2021年6月）前與CloudCanal的合作直播中，讓我們瞭解到這款資料庫產品。當我們再度想起OceanBase時，它已經開源並計劃釋出OceanBase 4.0版本。在我們從OceanBase官網及社群深入瞭解相關資訊時，觀察到OceanBase的文件比較完善，其寫效能、AP能力、擴充套件性、遷移成本都符合我們對新方案的預期。當即展開小規模調研。即搭建低配測試環境觀察基本的語法相容和業務適配。

測試與部署

在小規模測試過程中，使用者資料突增，資料從原來的日增百萬級別，直接跳躍到日增1.2億左右，公司內部報表業務接近癱瘓，更新替換迫在眉睫。我們迅速搭建了測試環境，測試公司基本的業務流程、相容情況，為正式部署做準備。測試過程中主要考量以下幾個因素。

1、高效能

抽取MySQL中多張日誌、流水錶的部分資料至OceanBase 4.0單節點中，測試各類分析SQL的查詢效能，如分組求和、總數統計等。

對比示例：模擬單表2600w的資料量，OceanBase中全表count(1)毫秒級響應，而在MySQL中執行是分鐘級。

2、低成本

資料儲存方面，原來千萬級別的資料在MySQL中大概佔用超400 GB的儲存量，遷移到OceanBase中億級別的資料僅需260 GB。

MySQL 5.7遷移至OceanBase4.0時，使用了MySQL dump匯出MySQL 5.7資料，再使用OBLOADER 4.0匯入OceanBase 4.0，方便快捷。

遷移至OceanBase4.0以後，少部分儲存過程存在不相容的情況，在程式碼層面做了修改，相較於分庫分表的改造、運維方案，這塊的人力投入比較可控。

3、易用性

採用OBD方式部署單節點例項簡單快捷，另外自帶的ODC開發者工具和以前習慣使用的Navicat都能方便的測試OceanBase。

基於上述測試資料，我們決定部署OceanBase 4.0，生產環境部署資訊如下。

版本	OceanBase：4.0.0_CE_BP1OBD：1.6.2
拓撲	OceanBase：單節點OBServer+OBProxy
配置	16C/64G/3*1T租戶資源：12C/48G

而在實際的測試到生產過程中，線上業務飛速發展，單表日增資料量到上億級別，導致在生產環境實際跑業務分析SQL時，效率不佳。因此，我們針對幾張核心表的查詢也做了一定的最佳化措施。下面以SQL為例展開說明，以供參考。

比如這是一張遊戲的流水錶，拿到使用者的流水記錄以後，我們在內部會統計最近幾天，不同遊戲、不同渠道使用者的各類消費情況，根據統計的各遊戲的運營資訊及時調整遊戲的活動策略。

CREATE TABLE `games_play_flow` (
 `event_time` int(11) DEFAULT NULL COMMENT,
 `game_id` int(5) DEFAULT NULL COMMENT,
 `account_id` bigint(20) DEFAULT NULL,
 `uid` bigint(20) DEFAULT NULL,
 `channel_id` varchar(20) DEFAULT NULL,
 `play_id` varchar(100) DEFAULT NULL,
 `mfr_id` int(11) DEFAULT NULL,
 `money_type` tinyint(4) DEFAULT NULL,
 `output` bigint(20) DEFAULT NULL,
 `consume` bigint(20) DEFAULT NULL,
 KEY `idx_ix_event_time_63917445` (`event_time`) BLOCK_SIZE 16384 LOCAL,
 KEY `idx_ix_account_id_1050842020` (`account_id`) BLOCK_SIZE 16384 LOCAL
) DEFAULT CHARSET = utf8mb4 ROW_FORMAT = DYNAMIC COMPRESSION = 'zstd_1.3.8' REPLICA_NUM = 1 BLOCK_SIZE = 16384 USE_BLOOM_FILTER = FALSE TABLET_SIZE = 134217728 PCTFREE = 0
SELECT /*+ parallel(10)*/ "2022-12-09" date,
game_id,
channel_id,
sum(output) as pay_output,
sum(consume) as pay_consume
from games_play_flow
where money_type = 2 
and event_time between 1670515200 and 1670601600 
group by game_id ,channel_id

在測試此類業務SQL的過程中，也出現了一些意料之外的問題，在日增資料量突增的情況下，OceanBase4.0中單表分組統計SQL效能表現沒有在測試環境的表現好。並且因為業務24小時均勻寫入的特點，業務沒有明顯的高低峰期，導致當天最新資料入庫時，統計資訊未更新，統計最近三天運營資料時，SQL執行計劃不走索引。

我們也和OceanBase社群的同學一起商量了解決方案，做了三方面的工作，最終保證了業務SQL的效能滿足運營需求。第一，重新規劃運營資料的保留週期，計劃僅保留1-2個月資料，並且將多張核心的單表（幾億行資料）改造為分割槽表，按天分割槽；第二，根據CPU佔用增加SQL執行的並行度，利用分割槽裁剪+event_time索引提升查詢效率；第三，針對統計資訊未及時更新的問題，定時任務觸發手動收集統計資訊。

實踐總結

從整體來看，選用OceanBase 4.0對公司業務效能的提升還是很大的，也為公司節約了很多成本。

首先，解決了MySQL的效能瓶頸問題，依據生產環境實際執行情況，分割槽表的改造加上OceanBase準記憶體架構，解決了熱點表寫的問題，OceaanBase 4.0單機寫效能是之前MySQL的5-6倍。其次，針對兩條業務線（MySQL與OceeanBase）在遊戲正式服的查詢效能表現，對於分組聚合查詢業務，我們按天進行資料分割槽，MySQL對單天的資料進行統計計算需要130s，而OceanBase 僅需18s，且OceanBase業務線日增資料是MySQL業務線的2倍左右。按這樣的比例來算，同配置下，在我們的業務場景下OceanBase的分組查詢效能是MySQL的12倍左右。效能得到了巨大的提升。

當然，在業務切換到OceanBase 4.0的過程中，我們也遇到了一些問題，比如上文提到的剛開始啟用生產環境發現按天分割槽的分割槽表查詢效能和測試環境相差較大，後來同OceanBase社群的同學一起快速定位到了問題。原來是當天的分割槽統計資訊未收集到，導致查詢語句走的全表掃描，透過手動觸發收集分割槽資訊後，查詢效能就立馬上來了，據瞭解，OceanBase 4.1版本將提供線上收集統計資訊功能，解決這個問題。

除此以外，我們還反饋了一些關於相容性、功能等問題，OceanBase社群的同學也一一做了解答，可參考如下：

cpu_count不實時生效：

mySQL遷移到ob遇到相容問題：

未來暢想

總的來說，在本次業務解決方案替換過程中，我們重點關注於AP場景下的效能最佳化，期間遇到的一些問題都已解決，但還有些未來可能遇到的問題，我們也做了一些規劃。

1. 未來會將OceanBase4.0BP1升級至正式版本。
2. 為支援業務發展，後續可能會繼續擴充套件例項節點數，針對大表最佳化，可能進一步做二級分割槽。
3. 在運維管理方面，試用OCP Express，簡化叢集管理的操作。

這次試用OceanBase 4.0，整體而言比較驚喜，短時間內的調研、測試、替換上線，既解決了我們的業務痛點，又不用擔心擴充套件問題。未來，我也會積極參與OceanBase的社群，和大家共迎更好的OceanBase。