突破資料存儲瓶頸！轉轉業财系統億級資料存儲優化實踐

1.背景

1.1 現狀

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

轉轉業财系統于2021年開始建構，前期為了滿足需求短時間内上線，選擇了主動接收上遊業務系統的資料。然而随着時間的推移，資料量在不斷增長，系統已經達到無法承載的邊緣，引發了許多問題。是以，我們需要對資料存儲進行優化。

1.2 資料量統計

業财系統資料量較大表統計：

表名行數資料長度索引長度出庫明細表10628017629.48GB34GB出庫單頭表253441107GB6GB入庫明細表227669108GB5GB銷售訂單表2957865910GB9GB應收單表246862675GB2GB入庫單表207774574GB6GB應付單表153877244GB2GB

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

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. 考慮後續接入更多的業務資料，由于目前無法統一資料格式，那麼可能就需要重新考慮邊界等問題。

• 方案三：TiDB
• 優點

1. 高度相容 MySQL：大多數情況下，無需修改代碼即可從MySQL輕松遷移至TiDB。
2. 水準彈性擴充：通過簡單地增加新節點即可實作 TiDB 的水準擴充，按需擴充吞吐或存儲，輕松應對高并發、海量資料場景。

• 缺點

1. 仍有一些MySQL的特性和行為，TiDB目前暫時不支援或表現與MySQL有差異。
2. 系統複雜，元件太多。

• 适用場景

1. 對資料一緻性及高可靠、系統高可用、可擴充性、容災要求較高的金融行業屬性的場景。
2. 對存儲容量、可擴充性、并發要求較高的大量資料及高并發的OLTP場景。
3. 資料彙聚、二次加工處理的場景。

• 業财系統适用分析

1. 由于TiDB相容了MySQL，是以改動點也較少。
2. 近幾年是不用考慮資料量問題，可以接入更多樣化資料。
3. TiDB能夠支援大表經常有加列減列的需求，可擴充性高，目前也比較符合業财現狀。

• 方案四：OceanBase
• 優點

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方案。

方案業财适用分析寬表1.寬表可能包含大量重複資料，導緻存儲空間的浪費。這會增加資料庫的存儲需求，尤其在大規模資料集上會更為顯著

2.由于涉及到大量列和關聯資料，後續性能優化可能需要考慮更多的因素，而且可能需要采用複雜的索引政策

3.複雜度增加，改動量比較大ES1.通過建立索引方式解決聯表問題，也一并提高了查詢效率

2.後續可擴充性比較高，增加查詢條件等，都易實作

3.需要保持資料源與ES資料一緻問題

4.可以減低現有的資料庫索引資料量

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。

同步方式優點缺點同步雙寫這種方式簡單粗暴，實時性高1.業務耦合：這種方式代碼侵入性強，耦合大量資料同步代碼，要在寫DB的地方寫ES的代碼

2. 影響性能：寫入兩個存儲，響應時間變長，系統的性能必然會下降

3.不便擴充：搜尋可能有一些個性化需求，需要對資料進行聚合，這種方式不便實作

4.高風險：存在雙寫失敗丢資料風險異步雙寫1.性能高

2.不易出現資料丢失問題

3.多源寫入之間互相隔離，便于擴充更多的資料源寫入1.寫死問題，接入新的資料源需要實作新的消費者代碼

2.系統複雜度增加，引入了消息中間件

3.MQ是異步消費模型，使用者寫入的資料不一定可以馬上看到，造成延時定期同步實作比較簡單1.實時性難以保證

2.對存儲壓力較大資料訂閱1.業務入侵較少

2.實時性比較高需要選型資料訂閱架構，系統複雜度增加

1. 在增量資料同步以後，最後一步就是需要完成曆史資料的同步，此次我們選擇的同步方式是公司内部提供的ECP，可以參考文章：不可思議！億級資料竟然如此輕松同步至ES！

5.總結與成果

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

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

關于作者

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

來源-微信公衆号:轉轉技術

出處:https://mp.weixin.qq.com/s/jyUunH1NyGUMo_0o0OZbWg