一種分布式數據存儲方案設計與實現

摘要：傳統的基于關系型數據庫的分布式存儲主要通過引入中間件對數據進行水平或垂直拆分來實現，這類中間件主要適用查詢主鍵存在單調遞增或單調遞減的情況，針對查詢主鍵不符合該要求的，該文設計并實現了一種分布式數據存儲方案，基于數據庫號段模式生成單調遞增的分布式ID作為關系型數據庫的拆分主鍵，借助MongoDB存儲查詢鍵值和拆分主鍵的關聯信息。實驗結果表明，該方法可以有效實現海量數據的分布式存儲。

關鍵詞：關系型數據庫；分布式存儲；分布式ID；海量數據

中圖分類號：TP311" " " " 文獻標識碼：A

文章編號：1009-3044（2022）33-0068-03

1 引言

目前比較常用的分布式數據存儲[1]方案，主要是在關系型數據庫中間加一層數據庫分庫中間件，通過將查詢鍵值作為拆分字段，用一定的路由算法，將原始SQL進行解析后構建出新的SQL路由到指定的分節點，最后對結果集進行歸并。比較常用的中間件有dble[2]、Sharding-sphere[3]等。dble是基于MySQL的高可擴展性的分布式中間件，是基于開源項目MyCat[4]的，但取消了許多其他數據庫的支持，專注于MySQL，對兼容性、復雜查詢和分布式事務的行為進行了深入的改進和優化，修復了MyCat的一些bug。ShardingSphere是一套開源的分布式數據庫中間件解決方案組成的生態圈，它由Sharding-JDBC、Sharding-Proxy和Sharding-Sidecar這3款相互獨立的產品組成。他們均提供標準化的數據分片、分布式事務和數據庫治理功能，可適用于如Java同構、異構語言、容器、云原生等各種多樣化的應用場景。這些中間件都有一個特點，主要適用于電商交易、金融交易等查詢主鍵單調遞增或單調遞減的場景，選取這類主鍵作為拆分鍵，易于實現數據的均勻拆分。對于查詢主鍵不具有單調遞增或單調遞減特性，一般通過一致性hash算法[5]進行路由分庫，能做到數據的大致均勻拆分，但是當節點增加時，仍然需要重新遷移一部分數據以適應節點數量變化帶來的路由結果改變。

針對上述問題，設計了一種分布式數據存儲方案，基于高性能非關系型數據庫MongoDB [6]存儲查詢鍵值和拆分鍵值的索引信息，實現針對查詢鍵值為完全隨機無序字符串的數據存儲的均勻分布，有效降低海量數據[7]對單節點的壓力，提升數據的讀寫效率，同時當節點增加時無須動態遷移數據，實現節點輕松擴容。

2 相關技術

2.1 分布式ID生成技術

分布式ID在業務系統中很常用，如電商交易、金融交易等業務系統中的訂單號，這個ID往往就是數據庫中的唯一主鍵，通常需要滿足唯一性、有序性、可用性、安全性等特性：

唯一性：生成的ID全局唯一；

有序性：生成的ID按照某種規則有序，便于數據庫插入和排序；

可用性：在高并發情況下能正確生成ID；

安全性：不暴露系統和業務的信息。

常見的分布式ID生成技術主要有數據庫自增ID、UUID、REDIS[7]生成ID、SNOWFLAKE雪花算法等。

數據庫自增ID使用數據庫的ID自增策略，如MYSQL的AUTO_INCREMENT，該方案簡單，生成的ID有序，缺點是在單個數據庫或讀寫分離或一主多從的情況下，存在單點故障風險。

UUID通常根據平臺提供的生成API，按照開放軟件基金會（OSF）制定的標準計算，生成的ID性能非常好，全球唯一，產生重復的概率非常低。缺點是UUID無法保證趨勢遞增，并且往往是使用字符串存儲，查詢效率比較低、存儲空間比較大、傳輸數據量大。

REDIS生成ID是利用REDIS的原子操作INCR和INCRBY來實現，性能優于數據庫，ID有序，缺點是需要編碼和配置的工作量比較大，增加系統復雜度。

SNOWFLAKE雪花算法是Twitter開源的分布式ID生成算法，在生成ID中引入了時間戳，按照時間在單機上是遞增的，性能非常好，缺點是在分布式環境中，依賴于系統時間的一致性，可能會出現ID沖突。

2.2 分庫策略

在分庫策略的選擇上，比較常用的分庫策略有范圍分片、has取模分片、一致性hash分片等。每種分片策略都有其自身的優缺點。

范圍分片：拆分鍵值為自增ID，指定一個數據范圍來進行分庫，每一定數量條記錄分為一個庫，這種分片策略優點是擴容非常方便，只需增加新節點，創建數據庫和表即可，不需要對舊的數據進行分片遷移。缺點是可能存在IO瓶頸，當業務的大部分數據讀寫都在新節點的時候，會對新節點造成比較大的壓力。

hash取模分片：根據拆分鍵值的hash值mod一個特定的數值得到的結果即為對應的庫，這種分片策略優點是能保證數據比較均勻地分散在不同的庫中，減輕數據庫的IO壓力。缺點是擴容麻煩，每次擴容的時候都需要對所有數據按照新的路由規則重新計算分片進行遷移分配到不同的庫中。

一致性hash分片：一致性hash算法是將整個hash值空間映射成一個虛擬的圓環，整個hash空間的取值范圍為0～232-1，將拆分鍵值使用hash算法算出對應的hash值，然后根據hash值的位置沿圓環順時針查找，第一個遇到的節點就是所對應的庫。這種分片策略克服了hash取模分片的不足，當擴容的時候，只需要重定位環空間中的一小部分數據。

3 方案設計

一種分布式數據存儲方案基于數據庫發號算法實現生成分布式ID作為數據庫拆分鍵，利用MongoDB存儲查詢鍵值和拆分鍵值的索引信息，實現針對查詢鍵值為完全隨機無序字符串的數據在關系型數據庫存儲的均勻分布。

該方案有3個關鍵之處：一是生成全局分布式ID，二是利用MongoDB存儲與查詢索引信息，三是分庫實現。

3.1 分布式ID生成

設計一種分布式ID生成方案，簡單來說就是數據庫中保存了可用的ID號段，系統將可用的號段加載到內存中，之后生成的ID會直接從內存中產生，當內存中的ID用完時，更新數據庫可用ID號段，如此反復。為了解決數據庫單點問題，可以配置多節點，每個節點指定一個不重復的起始ID，按照指定的偏移梯度生成ID。

圖1為分布式ID生成架構圖，有3個數據庫節點發號，節點1起始ID設置1，節點2起始ID設置2，節點3起始ID設置3，每個節點按照3的梯度進行ID生成，那么節點1生成的ID為1、4、7、10、13……，節點2生成的ID為2、5、8、11、14……，節點3生成的ID為3、6、9、12、15……，這樣可以保證每個節點生成的ID都不重復，并且當有節點宕機的時候生成的ID仍然趨勢遞增。

3.2 索引關系存儲與查詢

由于業務中的查詢鍵值為完全隨機的字符串，不適合直接用來做分庫拆分鍵，因此設計首先生成分布式ID作為業務主鍵，同時作為分庫使用的拆分鍵值，利用MongoDB存儲該拆分鍵值和查詢鍵值的索引關系，如圖2所示，指定查詢鍵值作為_id字段，與拆分鍵值建立唯一對應關系存儲于MongoDB中。

關系型數據庫中存儲的業務數據如圖3所示，拆分鍵值作為業務數據表的主鍵，其他字段則存儲查詢鍵值和其他業務數據。

當存儲業務數據的時候，首先獲取分布式ID作為業務數據關系數據表的主鍵（拆分鍵值），同時建立該主鍵ID與業務數據查詢鍵值的索引關系表存儲于MongoDB中，當索引表在MongoDB中存儲成功后，再對該主鍵ID按照分庫算法，將業務數據路由到指定的關系型數據庫中進行存儲。當通過查詢鍵值查詢該條業務數據的時候，首先在MongoDB的索引表中查找出與該查詢鍵值對應的拆分鍵值，再對該拆分鍵值按照與插入時一致的分庫算法，將業務數據從路由到的關系型數據庫中查詢出來。同樣的，當需要根據查詢鍵值更新或刪除業務數據的時候，先根據該查詢鍵值在MongoDB中查詢得到對應的拆分鍵值，然后根據同樣的分庫算法路由到對應的關系型數據庫中，對對應的業務數據進行更新或刪除。

3.3 分庫實現

結合我們的業務特點，我們選擇范圍分片對我們的業務數據進行水平拆分。因為范圍分片擴容簡單，而且擴容的時候不需要對原有數據做任何遷移，只需要創建新的節點數據庫和數據表就可以，并且由于我們的業務數據和電商交易、金融交易的數據特點不同，電商交易、金融交易等業務大部分讀和寫都會訪問新數據，會造成新的數據節點的壓力過大，而我們的業務數據主要特點為：

1）數據體量大，單庫單表不做拆分的話，數據量能達到上億條，這對關系型數據庫的壓力非常大。

2）讀數據沒有熱點效應，所有數據訪問概率相同，對讀取數據性能要求較高。

3）寫數據的壓力不如電商交易等平臺，最大瞬時壓力單節點完全可以支撐。

綜合考量，范圍分片可以作為這種業務數據特點的首選，如圖4所示，拆分鍵值為分布式自增ID，每1000萬條記錄分為一個庫，那么主鍵為1到10000000對應的業務數據在節點1，主鍵為10000001到20000000對應的業務數據在節點2，依此類推。

4 總結

文中設計了一種分布式數據存儲方案，實現針對查詢鍵值為完全隨機無序字符串的業務數據在關系型數據庫的均勻拆分存儲，結果表明該方案能有效降低海量數據對單節點的壓力，提升數據的讀寫效率，當節點增加時無須動態遷移數據，實現節點輕松擴容。

參考文獻：

[1] 宋云奎，吳文鵬，趙磊，等.基于Redis的分布式數據存儲方法[J].計算機產品與流通，2020（8）：106.

[2] DBLE分布式中間件[EB/OL]. https：//github.com/actiontech/dble-docs-cn

[3] ShardingSphere概覽[EB/OL].https：//shardingsphere.apache.org/document/legacy/3.x/document/cn/ove-riew

[4] 陳宇收.基于Mycat的分布式數據存儲研究[J].中國新通信，2018，20（22）：63-64.

[5] 李寧.基于一致性Hash算法的分布式緩存數據冗余[J].軟件導刊，2016，15（1）：47-50.

[6] MongoDB[EB/OL]. https：//www.mongodb.com/docs/

[7] 王艷松，張琦，莊澤巖，等.面向海量數據的存儲技術發展分析[J].通信管理與技術，2021（5）：12-15.

【通聯編輯：梁書】