突破數據儲存瓶頸！轉轉業財系統億級數據儲存最佳化實踐

1.背景

1.1 現狀

目前轉轉業財系統接收了上遊各個業務系統（例如：訂單、oms、支付、售後等系統）的數據，並將其轉換為財務數據，最終輸出財務相關報表和指標數據，幫助公司有效地進行財務管理和決策。

轉轉業財系統於2021年開始構建，前期為了滿足需求短時間內上線，選擇了主動接收上遊業務系統的數據。然而隨著時間的推移，數據量在不斷增長，系統已經達到無法承載的邊緣，引發了許多問題。因此，我們需要對數據儲存進行最佳化。

1.2 數據量統計

業財系統數據量較大表統計：

以下是數據量較大的表數據增量趨勢圖，可以觀察到近幾個月由於新業務的增加，每月的數據增量已經達到一千萬。

1.3 慢查詢情況

從慢查詢監控平台可以看到，每天慢查詢個數已經到達千量級別。慢查詢不僅影響使用者體驗，還會大量消耗所在機器資源，嚴重可能導致機器宕機。另外，轉轉MySQL資料庫架構屬於單機多例項，一台物理機上部署多套集群的例項，所以不僅會影響系統本身集群，還會拖累其他集群，引發雪球效應。

2.設計目標

2.1 解決數據量問題

在未來五年，不用考慮資料庫數據量問題，能夠輕松應對未來的業務增長和覆蓋公司全量業務，且具備良好的擴充套件性，最終可以穩定向外輸出更多數據報表等。

2.2 解決讀寫效能

透過此次最佳化，提升報表查詢效率，減少定時任務執行時間，避免因為慢查詢導致任務失敗和介面超時問題，提高服務穩定性。

3.方案選擇

3.1 db儲存方案選型

為解決底層表數據量問題，我們對比了以下四個方案：

1. 將數據分散到多個資料庫和表中，從而減輕單一資料庫的負載壓力。這樣可以提高資料庫的讀寫效能和響應速度，降低查詢延遲。

2. 拆分的表結構相同，程式改造較少。

1. 需要提前規劃好分片規則，一旦定好規則就難以移動，擴充套件性比較差。

2. 拆分規則很難抽象出來。

3. 跨庫事務問題。

1. 資料庫面臨高並行存取的壓力，又需要面對海量數據的儲存問題，這時需要對資料庫既采用分表策略，又采用分庫策略，以便同時擴充套件系統的並行處理能力，以及提升單表的查詢效能。

2. 數據有統一的業務規則主鍵，使數據可以均勻分布。

1. 業財系統作為底層系統，接受了各個業務系統的數據，數據比較多樣性和復雜性，很難定義出一個業務主鍵，數據分布均勻困難。

2. 若某業務數據量迅速增長或接入其他業務數據，那麽可能又會面對數據量問題。

1. 將不常存取的數據從線上儲存中移動到歸檔儲存中，減少了線上儲存的容量需求，從而降低了儲存成本。

2. 減少了線上儲存中數據的數量，因此可以提高資料庫讀寫效能。

3. 可以將歷史數據長期保存，避免了數據的遺失。

4. 可以將數據備份到不同的儲存位置，以便在需要時進行數據恢復。

1. 需要保證歸檔事務性，防止歸檔數據同時出現在冷熱庫，出現數據重復。

2. 需要考慮合適的歸檔策略，不影響服務存取。

3. 需要有明確的業務邊界，業務復雜的數據不適用。

1. 資料庫中存在大量的歷史數據，且查詢頻率比較低。

2. 資料庫的寫入操作比讀取操作更頻繁。

3. 資料庫的儲存成本較高，需要降低成本。

1. 業財系統業務數據復雜，現階段還會更改和查詢歷史數據，時間口徑不統一，邊界比較模糊，無法確認一個準確的邊界。

2. 考慮後續接入更多的業務數據，由於目前無法統一數據格式，那麽可能就需要重新考慮邊界等問題。

1. 高度相容 MySQL：大多數情況下，無需修改程式碼即可從MySQL輕松遷移至TiDB。

2. 水平彈性擴充套件：透過簡單地增加新節點即可實作 TiDB 的水平擴充套件，按需擴充套件吞吐或儲存，輕松應對高並行、海量數據場景。

1. 仍有一些MySQL的特性和行為，TiDB目前暫時不支持或表現與MySQL有差異。

2. 系統復雜，元件太多。

1. 對數據一致性及高可靠、系統高可用、可延伸性、容災要求較高的金融行業內容的場景。

2. 對儲存容量、可延伸性、並行要求較高的大量數據及高並行的OLTP場景。

3. 數據匯聚、二次加工處理的場景。

1. 由於TiDB相容了MySQL，所以改動點也較少。

2. 近幾年是不用考慮數據量問題，可以接入更多樣化數據。

3. TiDB能夠支持大表經常有加列減列的需求，可延伸性高，目前也比較符合業財現狀。

1. 高效能：采用了讀寫分離的架構，把數據分為基線數據和增量數據。其中增量數據放在記憶體裏（MemTable），基線數據放在SSD槽（SSTable）。對數據的修改都是增量數據，只寫記憶體。所以DML是完全的記憶體操作，效能非常高。

2. 高相容：相容常用MySQL/ORACLE功能及MySQL/ORACLE前後台協定，業務零修改或少量修改即可從MySQL/ORACLE遷移至OceanBase。

3. 高可用：數據采用多副本儲存，少數副本故障不影響數據可用性。

1. 對環境要求極高，需要采購使用其指定的伺服器。

2. 學習和運維成本比較高。

3. 盡管OceanBase具有高可用性的特性，但其實作仍然依賴於底層硬體和網路的穩定性。

1. 金融級數據可靠性需求。金融環境下通常對數據可靠性有更高的要求，OceanBase 每一次事務送出，對應日誌總是會在多個數據中心即時同步，並持久化。

2. 資料庫面對飛速增長的業務數據量。

1. 目前運維沒有維護，所以就不考慮此方案，大家可以參考此方案是否適用於本身系統。

綜合以上各個方案的分析，目前最適用於轉轉業財系統的方案是TiDB。該方案能夠在短時間內解決數據量問題，並且改動成本相對較低。

3.2 慢查詢最佳化方案

在分析了慢查詢語句以後，發現大部份慢查詢都是由於聯表查詢導致的，所以此次主要解決聯表問題。聯表解決方案對比如下，根據適用分析選擇ES方案。

4.方案實踐

4.1 方案實踐步驟

根據方案選擇分析，最適合業財系統當前狀況的方案是首先切換底層數據儲存，然後再接入ES。在實施這兩個方案之前，我們需要考慮它們的先後順序，並分析業財系統的現狀。由於數據量的突增，考慮到現有業務和後續新增業務，同時在不影響現有使用的前提下，首要需要解決的問題是數據量。因此，我們建議首先切換底層數據儲存。這樣做的好處是，即使在後續的實施中遇到問題，我們仍然可以回滾到原有的數據儲存。這樣既可以保證數據的完整性，也減少了實施過程中的風險。另一方面，如果我們選擇先接入ES，就需要考慮如何保證數據切換過程中的數據完整性，並且同步方式也需要考慮兩種不同數據儲存方案之間的相容性，這將增加許多額外的工作量和風險。

綜上所述，我們選擇的最佳化步驟是首先切換底層數據儲存，待其穩定後再接入ES。這樣能夠有效解決當前的數據量問題，同時保證系統的穩定性和數據完整性。隨後，我們可以繼續進行ES的接入，以進一步最佳化業財系統的效能。

4.2 切換底層數據儲存步驟

在選擇數據遷移方式時，考慮到業財系統對即時性要求並不是很高，且評估了下目前大部份數據接入寫入方式，是可以接受停寫幾分鐘，這樣便大大降低了整個數據遷移成本。

遷移過程要求：

1. 檢查TiDB是否都能相容目前服務中的SQL語句，保證遷移之後系統不會報錯。

2. 數據需要保證完整性，遷移之後需要保證MySQL庫和TiDB庫的數據是嚴格一致。

3. 遷移過程中需要做到可以回滾，一旦遷移過程中出現問題，可以立即回滾到MySQL庫，不會對系統可用性造成影響。

   

4.3 接入ES

1. 根據報表查詢頁面的功能和聯表SQL分析，我們進行了索引模型設計，核心是最佳化查詢效能和提高系統的響應速度。

2. 在建立索引模型之後，我們需要考慮資料庫（DB）與Elasticsearch（ES）之間增量數據的同步方式。

以下表格是對比了四種不同的同步方式，我們根據已設計的索引分析，考慮到每個索引涉及的表較多、相關業務程式碼尚未收口以及對即時性較高的需求，我們決定采用數據訂閱的方式進行同步。在當前公司提供的實作方式中，我們選擇了Kafka。

3. 在增量數據同步以後，最後一步就是需要完成歷史數據的同步，此次我們選擇的同步方式是公司內部提供的ECP

5.總結與成果

目前，業財系統已成功完成底層數據儲存的切換，可以看到近幾年來不再擔心數據量儲存的問題，並且成功接入了更多的業務數據。隨著引入了Elasticsearch（ES），業務人員也不再反饋報表頁面超時等問題。這次針對數據儲存的最佳化實質上是對系統的重構，選擇方案時考慮了對系統影響範圍較小且不影響業務人員使用的因素，這也是最佳化的核心所在。

由於歷史原因，業財系統仍存在許多需要最佳化的方面，如慢SQL的持續治理、定時任務最佳化等。因此，我們需要保持此最佳化的核心理念，並在後續的重構中繼續完善，以使業財系統更加穩定。

關於作者

戴美琪，轉轉交易中台研發工程師

IT交流群

致力於幫助廣大開發者提供高效合適的工具，讓大家能夠騰出手做更多創造性的工作，也歡迎大家分享自己公司的內推資訊，相互幫助，一起進步！

組建了程式設計師，架構師，IT從業者交流群，以 交流技術 、 職位內推 、 行業探討 為主

加小編 好友 ，備註"加群"