本文介紹了某省婦幼健康管理系統的建設和數據庫架構優化的過程。原有的數據庫架構使用了 StarRocks 作爲分析層，但隨着業務的發展，這套架構暴露出諸多痛點，不再適應婦幼業務的需求。爲解決這些問題，該系統選擇了將原有架構中的 StarRocks 替換爲 TiFlash 組件，並引入了 Yearning 自動化 SQL 審計平臺，提高了運維效率和業務擴展能力。新架構在人力成本釋放、運維成本降低等方面取得了顯著的成效。
業務背景
某省婦幼健康管理系統建設內容包括：婦幼健康信息數據庫；婦幼健康信息採集系統、婦幼健康信息管理及分析系統；母子健康管理 APP、婦幼健康管理與分析 APP 等 62 個功能模塊。
原有數據庫架構
原有技術架構以及痛點
我們選擇 StarRocks 作爲分析層，通過 DataX + CloudCanal 的模式實現實時+離線數據同步。隨着業務的迭代，這套架構不太適應婦幼業務的發展需要。
架構總體上分爲四塊，自底向上分別是：
- 數據層：源端數據源主要是 MySQL 爲主的關係型數據庫。分別搭建 5 套（10 臺）主從分別承接 14 個子庫和 1 個總庫 MySQL 子庫 700+表。
- 處理層：使用 CloudCanal+datax 進行實時和離線的數據同步。
- 離線：將報表、大屏、數據交換服務採用離線方式構建 DM 主題數據集市。使用到的就是 Datax 工具結合實現。
- 實時：使用 CloudCanal 將 MySQL 數據 1:1 同步到 Starrocks 中。
- 分析層：分析層會保存計算好的指標數據以及用於加速查詢的中間結果數據。
- 業務層：使用 3 臺 32C128G 搭建 SR 集羣，分別對應報表業務、大屏業務、數據交換服務、數據查詢加速。
痛點:
- 業務變動頻繁：業務需求導致數據庫結構頻繁變動，最初每週需變更至少兩次。經與事業部協商，現將變更頻率控制在每週一次。變更需要 DBA 對 14 個地市 MySQL 、StarRocks 以及數據調度進行調整。
- 服務器資源存在浪費現象：出於數據安全考慮，MySQL 採用主從架構，但目前從庫的資源尚未得到充分利用。
- 業務更新對運營的影響：在應用層面，我們採用微服務架構，涉及衆多研發人員，他們通常只專注於自己的業務模塊。通過 SQL 審計平臺，研發人員提交 DDL 語句，然後由 DBA 執行。然而，DBA 可能對具體業務不太熟悉，難以確保所執行的 DDL 語句完全符合業務需求。
- 研發與 DBA 人員對 SQL 調優技能無法得到提高：由於 MySQL 數據 1:1 打到 StarRocks 中，複雜查詢全部用 MPP 替代，在 SQL 調優、數據表合理拆分方面不再關注（以前感覺這是個好事情，提高研發人員效率），這個問題會在 MPP 瓶頸後統一爆發，只能通過升級服務器配置解決，無法從根本上解決問題。
- DBA 工作壓力巨大：當前架構對 DBA 的工作強度要求較高。根據每週一次的變更頻率，DBA 需在晚上 6 點後的業務低峯期執行 DDL 操作，同時負責維護 30 多套數據庫和近 20,000 張表。 操作完之後，發佈程序然後測試再跟進。 已經到半夜，如果出現問題在回滾操作，對業務影響較大。
- 按地市分割的數據庫不利於跨市業務服務的兼容，例如，報表通常需要通過創建寬表來彙總各數據庫的數據，這導致寬表數量不斷增加。此外，還存在檔案重複和無法跨地市查詢服務記錄等問題。
- 無法應用自動化數據庫審計平臺，數據庫分散操作複雜，自動化實現難度高。
架構選型
數據庫合併
在數據庫合併後，表的數量分佈如下：超過 10 萬條數據的表數量爲 792 張，超過 100 萬條數據的表數量爲 156 張，超過 1000 萬條數據的表數量爲 58 張，以及超過 1 億條數據的表數量爲 5 張。
我們正在尋找一種數據 庫解決方案，以確保在數據庫合併後，寫入操作和在線DDL操作的穩定性和可靠性 。我們對比測試了 PolarDB、TiDB 和 OceanBase 等多個數據庫解決方案，最終決定採用 TiDB，其主要特點包括：
- 高度兼容 MySQL，大多數情況下無需修改代碼即可從 MySQL 輕鬆遷移至 TiDB，即使已經分庫分表的 MySQL 集羣亦可通過 TiDB 提供的遷移工具進行實時遷移。
- 水平彈性擴展，通過簡單地增加新節點即可實現 TiDB 的水平擴展，按需擴展吞吐或存儲，輕鬆應對高併發、海量數據場景。
- 分佈式事務，TiDB 100% 支持標準的 ACID 事務。
- 真正金融級高可用，相比於傳統主從（M-S）複製方案，基於 Raft 的多數派選舉協議可以提供金融級的 100% 數據強一致性保證，且在不丟失大多數副本的前提下，可以實現故障的自動恢復（auto-failover），無需人工介入。
新數據庫架構
新架構中，我們移除了 StarRocks 分析層，轉而利用 TiDB 的 TiFlash 組件來實現 OLAP 功能。數據交換任務現在通過 TiCDC 來執行。分析層與業務層的合併簡化了架構，所有業務操作現在都直接在寬表上執行，並由 TiFlash 加速。這一變化顯著降低了運維成本並提升了業務擴展性。
分析層改造後收益
在將 StarRocks 替換爲 TiFlash 後， 與按地市分庫的 S tarR oc ks 相比， 我們發現整體查詢效率並未顯著提高，經過優化，常用的查詢 已能夠達到預期的性能標準。引入 TiDB 後，主要帶來了以下收益：
引入 Yearning 自動化 SQL 審計平臺
在新架構中，我們落地了自動化 SQL 審計平臺 Yearning，該平臺具備以下功能：
- 自動化 SQL 語句審覈，可對 SQL 進行自動檢測並執行
- DDL/DML 語句執行後自動生成回滾語句
- 審覈/查詢審計功能
- 支持 LDAP 登錄/釘釘及郵件消息推送
- 支持自定義審覈工作流
- 支持細粒度權限分配
分析層遷移到 TiDB 後 ， 我們將原有的 14 套數據庫合併爲一 套 TiDB， 方便管理，讓及時的優化成爲了可能。
自帶監控的 TiDB Dashboard
我們結合 TiDB Dashboard 的監控結果實現了自動化的監控告警機制，捕獲慢 SQL，避免熱點的產生。
示例：
- pt-kill 應用針對捕獲正在運行中的 SELECT|ALTER 等 DML/DDL 消耗資源過多的查詢，過濾它們，然後殺死它們（可選擇不殺）且發郵件/微信報警給 DBA 和相關開發知悉，避免因慢 SQL 執行時間過長對數據庫造成一定程度的傷害。（ https://github.com/hcymysql/pt-kill ） 同時 殺死的慢 語句會在後臺日志文件中進行保留，等待後續的優化。
TiDB Dashboard 部分功能截圖 ：
刪庫、刪表恢復
在過去的架構下，如果 DBA 或業務人員不小心進行了危險操作，恢復起來非常困難，只能依託於備份恢復來實現。引入 TiDB 後能夠快速 flashback，實現刪庫刪表的恢復。
恢復刪除庫示例
- 恢復被 DROP 刪除的 test 數據庫：DROP DATABASE test;FLASHBACK DATABASE test;
- 恢復被 DROP 刪除的 test 數據庫並重命名爲 test1：DROP DATABASE test;FLASHBACK DATABASE test TO test1;
恢復刪除表示例
- 恢復被 DROP 刪除的表數據：DROP TABLE t;FLASHBACK TABLE t;
- 恢復被 TRUNCATE 的表數據，由於被 TRUNCATE 的表還存在，所以需要重命名被恢復的表，否則會報錯表 t 已存在。TRUNCATE TABLE t;FLASHBACK TABLE t TO t1;
備份/還原應用超乎預期
TiDB 提供了 BR 集羣快照備份功能，直接將日誌備份到 MinIO 中。目前某省婦幼一天兩次快照 0 時、12 時，由於備份受限於存儲，目前只能保留一天內的快照也未做日誌備份。（全量快照+實時日誌備份）可保證數據不丟失。BR 還原數據超乎預期，300G 數據還原用時 20 分鐘（v7.1.3），官方最新版本 v7.6 最新版本 BR 還原能力提升 10 倍。
一地兩中心的嚐鮮
考慮到婦幼數據的重要性，在政務雲實施搭建一地兩中心，通過 TiCDC 實現主庫集羣實時將數據寫入到從集羣，同時從集羣擔負報表業務以及研發測試庫環境，讓我們初步實現了一地兩中心的設想。
新架構效果說明
服務器資源合理利用
人力成本的釋放
原架構在數據層和處理層 DBA 人員根據發佈週期對數據庫進行 DDL 操作以及調整和調度。新架構省去了調度的維護工作同時引入 SQL 審計平臺可實現自動化 ddl。但是 DBA 同時需要更加關注 TiDB 的各項指標。
運維成本的降低
TiDB 部署不需要大數據組件的支撐，部署運維都很簡單。 TiDB 兼容 MyS QL 生態，業務使用可直接使用 MySQL JDBC 進行連接，不用再擔心 SQL 語法差異問題。
未來規劃
目前我們有兩套數據架構 MyS QL + StarRocks 和 TiDB， 這兩套架構各有優勢（也可以結合使用），未來我們將結合事業部需求，根據不同業務線需求去確定使用哪套架構。