銀行背景下分庫分表技術選型

業務持續增長帶來的單表數據量過大，必然影響到數據庫的讀寫性能，那到底要不要分庫分表呢？

【推薦】單錶行數超過 500 萬行或者單表容量超過 2GB，才推薦進行分庫分表。
說明：如果預計三年後的數據量根本達不到這個級別，請不要在創建表時就分庫分表。

對於銀行業務來說，500 萬這個量還是很容易觸達的。

分庫分表的類型

**水平分表：**把一個大表數據在同一個庫內拆分成多個表，這些表表結構一樣，數據沒有交集，如下圖：

**垂直分表：**按照字段的維度，把一個大表拆分成多個表，每個表的字段都不一樣，如下圖：

分庫分表中間件

1.TDDL

tddl 不支持下面的操作：

• join 語句

• between/and

• not 語句

• for update

• force index 語句

• 數據庫內部函數

• 多表查詢

下圖是 github 上 tddl 現狀，可以看到已經停止維護了。

2.kingshard

kingshard 由 go 語言開發，使用時需要安裝 go 語言環境和 server，目前快手在用。從 github 上看，近 1 年有維護，但是不多：

缺點：不支持各類 join 和多表查詢
優點：拆分表的數量可以跟拆分庫的數量不一樣，即分庫後可以建子表

3.sharding-sphere

前身 sharding-jdbc，目前比較熱的一款中間件，好多公司在用。github 上可以看到最近一個月內都有提交代碼：

sharding-sphere 使用 jar 包依賴的方式，不需要部署 server。

社區活躍，遇到問題容易得到支持，支持分佈式事務

4.Mycat

非常成熟的一款中間件，需要部署 server 做代理。網上吐槽 mycat 的商業味太濃，從 github 看，近期更新比較少。

5. 問題

使用分庫分表中間件會帶來一些問題：

• 不能完全兼容原生 sql

• 業務代碼改動非常大

• 部署 server 的中間件需要考慮高可用

• 實際開發中可能會遇到各種坑

分佈式數據庫

分佈式數據庫是近幾年興起的新型數據庫，主流的分佈式數據庫有 2 類，一類是 PGXC 風格的，另一個是 NewSQL 風格的。多數分庫分表對 mysql 的語法支持更好一些，對 oracle 語法不太兼容。

PGXC 風格的數據庫，是在傳統關係型數據庫分片集羣之上，增加了協調節點和全局事務管理器 (GTM) 來實現對分佈式事務的支持。下面這個圖是基於 mysql 單體數據庫改進的 PGXC 數據庫模型：

而 NewSQL 是由 NoSQL 鍵值數據庫發展而來，構建在 BigTable 上的分佈式數據庫，不僅具有 NoSQL 對海量數據的存儲管理能力，還保持了傳統數據庫支持 ACID 事務和 SQL 等特性。它主要有以下特性：

• 放棄了 PGXC 架構中單體數據庫的事務

• 在 BigTable 基礎上構建了事務支持

• 引入分片機制，主要採用 Range 動態分片技術，跟 HASH 分片相比，數據可以不用固定的在某一個分片上

• 可靠性方面，放棄傳統數據庫的主從複製，採用 Paxos、Raft 等共識算法來保證 HA

• 存儲引擎方面，使用 LSM-Tree 替換 B + 樹模型，寫入性能更高

下面這張思維導圖分享了主流分佈式數據庫，左邊的 5 款是主流的 PGXC 風格數據庫，右邊的 6 款是 NewSQL 數據庫。

使用分佈式數據庫的優勢：

• 解決了分佈式事務問題

• 實現了強一致要求

• 技術新潮流

• 解決數據庫國產化訴求

使用分佈式數據庫的挑戰：

• DBA 團隊運維能力

• 業務代碼的改動量

• 新技術可能帶來的坑

• sql 不兼容問題

oracle 分區表

如果當下使用的是 oracle 數據庫，解決數據量太大帶來的性能問題，oracle 的分區表是非常不錯的選擇。

oracle 分區表有以下幾種類型：
範圍分區：根據 id 或者時間進行範圍分表
列表分區：表中的某個字段有固定幾個值，使用這個值做分表
HASH 分區：使用 HASH 函數做分區，分區表數據比較均勻
組合分區：可以使用上面的 2 種做組合分區

使用 oracle 分區表的優勢：

• 沒有 sql 不兼容問題

• 業務代碼改動較小

• 不需要考慮分佈式事務

• DBA 團隊運維壓力小

使用 oracle 分區表的考慮：

• 技術偏保守

• 不能滿足國產化訴求

• 不利於長遠去 o 計劃

系統單元化改造

除了上面提到的分庫分表技術外，也可以使用系統單元化的方式來完成。這個做法有下面幾個方面需要考慮：

• 是否支持動態分庫分表

• 是否要考慮分佈式事務中間件

• 多個系統的分庫分表代碼抽象共用

系統單元化改造，對 DBA 的運維壓力小，但是對於開發團隊來說不光當下工作量巨大，以後去 o 或者分佈式技術的引入都會有巨大的改造量。

銀行使用現狀

工商銀行

目前主要使用 mysql 和分庫分表中間件 (DBLE)，聯合華爲研發 GaussDB 200 並且部分系統投產使用。

郵儲銀行

老系統依然採用 oracle，新系統逐步過渡到 PostgreSQL，沒有使用分庫分表中間件和分佈式數據庫。應對大數據量帶來的性能問題，郵儲銀行使用業務系統單元化方式進行改造。

中信銀行

聯合中興通訊研發了 PGXC 風格的分佈式數據庫 GoldenDB，並且部分系統已經投產使用。

交通銀行

聯合華東師範大學和西北工業大學，研發了 NewSQL 風格的數據庫 CBASE，目前已經應用到多個核心交易系統中。

下面的引用出自論文《分佈式數據庫在金融應用場景中的探索與實踐》

數據庫屬於系統底層核心組件，且分佈式數據庫技術存在大量的技術難點，此前金融領域也沒有相關案例，因此在應用與實踐過程中，交通銀行遵循 “穩定第一、謹慎試點、穩步推廣” 的原則，先後在金融行業查詢類業務、流程類業務和高併發類業務中逐步推廣應用，試點均取得了良好的效果，節省了大量的成本.

北京銀行

目前有幾套重要的實時交易類系統已經對接 TiDB，包括比較重要網聯繫統、銀聯無卡支付、金融互聯服務平臺等。

中國銀行

在 Zabbix 監控系統中使用了 TiDB。

光大銀行

在雲繳費系統中使用了分庫分表，而在現金理財業務中使用了 TiDB。

招商銀行

下面介紹來自 OceanBase 官網：

基於 OceanBase 的 "歷史收益系統" 已正式上線對外提供服務。通過使用 OceanBase 提供的分區表功能達成了業務無入侵的目標，同時滿足業務併發海量數據訪問的性能要求。此外，依託 OceanBase 優秀的存儲架構和壓縮能力在數據存儲成本節省方面相比原傳統數據庫收益顯著。目前業務仍在持續迭代，爲招商證券相關手機端用戶提供在線盈虧分析等特色增值服務。

總結

近幾年銀行業越來越重視技術的投入，各大行都成立了科技研發中心並且研發投入在持續加大。但銀行的技術依然比較傳統，數據庫使用 Oracle 和 DB2 居多。這不光是技術問題，更重要的是銀行業對穩定性的要求太高。

目前頭部幾家大銀行應對大數據量帶來的性能問題，手段不盡相同。大部分偏保守，有的銀行在一些交易系統、管理系統上引入了分佈式數據庫和分庫分表中間件。

從技術上看，分庫分表中間件需要從開發層面解決分佈式事務問題，分佈式數據庫纔是未來的主流趨勢。

賬務覈算這類的核心繫統，對穩定性和一致性要求幾近苛刻，大家在技術選型上都比較保守。至今還沒有一家銀行願意在這類系統引入分佈式數據庫。

對於使用 oracle 的銀行，如果不考慮將來去 o，oracle 分區表是最好的選擇，因爲支持原生 sql，業務代碼改動小，不用考慮分佈式事務。

有的銀行使用業務系統單元化的方式來解決海量數據造成的性能問題，這很好地避開分佈式帶來的技術挑戰，但是業務系統改造工作量巨大，而且對以後技術升級或國產化支持非常不利。

未來銀行業在技術上的持續投入必然帶來技術的更新換代，而在國產化訴求下，去 o 是必然趨勢，相信未來必然會有銀行在賬務覈算類的核心繫統中嘗試分佈式數據庫。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/VqNOpIe2DNYFihaa2Ma_JQ